做业务系统如何能成长为架构师

前段时间有个朋友找到我,问了个非常典型的问题。他说:『我现在在做偏业务开发方向的工作,在平时需要如何积累基础服务和系统架构方面的经验和知识。 』

很显然他意识到了两种系统的区别,而且正在试图转型。然而我知道,他也走进了一个让人难以反驳的认识误区,这就是,因为业务系统技术要求不高,所以开发人员在走向架构师的路上成长缓慢。

业务系统技术要求有多高

如果说从门槛来看,业务逻辑确实是最容易写的代码。产出好量化,功能又好测试。就算真的坏了,系统一般不会因此垮掉。只是,门槛低并不意味着容易做好。

有一种工作是API设计与实现,行话叫『包接口』,也是很多同学刚毕业的第一份工作。这事说起来简单,只要调用方跟被调用方协商一致即可,但是真正做的时候你会发现很多问题。

调用方首当其冲。如果命名混乱,找到想要的接口和参数就会变得很难。而如果你错误码定义得不够清晰,调通一个接口将会变成一个令人崩溃的事情。

被调用方也没有轻松到哪里去。如果没有遵循正交原则,那么你每个接口都可能涉及后端的很多资源调用和库的引用,导致服务不可避免得变大。一个资源的变化,都将有可能会影响到很多接口,这对回归测试和问题排查都将是一个灾难。

如果你在做一个平台,情况会变得更加严重。抽象不足的话,用户的每一个需求都会变成新的接口。而一旦发布出去,你就要保持其兼容性,也就是说,这辈子都是你的接口了。如果开始的时候没考虑到版本,那么恭喜你,从此要转行技术支持了。

这方面微信的开放平台接口,基本算是一个反例。返回数据JSON和XML混排,超出限制后无响应!?可惜的是,由于平台变大,作为调用方的开发者只能被欺(qiang)负(jian)。

现在所有的服务都在云化,其中的基础就是API化,这个事情也变得越来越重要。推荐在做这方面工作的看看 Principles of good RESTful API Design。 http://codeplanet.io/principles-good-restful-api-design/

做业务系统会遇到很多这样的工作,做出来简单,但做好却难。是什么让我们却止步于做出来,并因此想做些有挑战的事呢?

被逼的工作,被逼的学习

因为大多数人都需要工作,很多人在做着自己不那么喜欢的工作。或因为感情,或因为压力,必须做完现在的事情。不喜欢意味着不会朝思暮想,不会为伊消得人憔悴。再好的职业素养,也不会改变做完即可的态度。

如果你是被逼学习型,找一份自己更喜欢的工作,事不宜迟。这里有一点个人的建议是,如果要走技术路线,不要做外包。

我们不排除有些工作因为容易掌握,大多数人都只是做完即可,但更多的情况是,不是工作要求低,而是做的人放低了对自己的要求。就像本文前面的业务系统,虽说离架构设计很远,但是基本功都是一样的。

值得注意的是,在一个分工明确的团队里,并不是所有人要做所有事,但是好的团队里所有人会了解所有事。一个开发者如果不了解上层服务的需求,不了解下层服务的设计,很难做好服务的。

只有对其他组件建立足够的了解,才能设计出一致的服务,减少过度优化和不当依赖。知道什么时候该容忍错误,什么时候该放弃请求,才能在出问题的时候快速定位,才能一起做好服务。

这种了解,就来自于对架构设计的理解。

不要被你的思想局限

如果你喜欢自己现在的事情,那么要恭喜你,你很幸运。而你需要注意的是,不要被自己的思想局限。虽然没人会要求你像卖油翁一样,在能倒油的时候练习从铜钱内穿过,但你至少要知道,还是有很多可以做的。

就拿本文开头的例子,你以为只是设计一个API,但其实API到底层数据到映射和转换,已经涉及了架构设计的基础。你以为只是设计成RESTful,但其实还可以做成自动测试的框架,像Swagger,或者RAML,或者API Blueprint。你以为你只是在包接口,其实是放弃了对自己的要求而已。

人永远不知道自己不知道的东西,这也是我们需要持续学习的原因。

包接口也能变成包老师。

(转载本站文章请注明作者和出处 JavaRanger – javaranger.com ,请勿用于任何商业用途)

本文链接: http://www.javaranger.com/archives/2089 

发表评论

电子邮件地址不会被公开。 必填项已用*标注

您可以使用这些HTML标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>