外籍团队工作有感:1、关于架构

  架构是一个很“大”的词。在我的印象中,很多国内公司所谓的“架构师”往往自己都很难对架构这个词下一个准确的定义,如果一定要说什么是“架构”的话,又会有一些学院派套弄出几个生涩的书面词汇弄得越发晦涩,让人觉得那是老外们高精尖的花样。

  实际上我在工作中,老外们(题外话,我们CTO是个五十多岁的瑞典老头)没并没有过多的使用“架构”(architecture)这个词,更多的只是叫做“结构”(structure)而已。在大多数时候,我们的项目采取的都是小迭代周期,进行反复、频繁的重构(refactor),由此看来,架构其实并不是一个很“大”的东西,而是一种“具体而微”的花样。

  举个例子来说:

  面对一个项目,国内的团队往往会上上下下前前后后分析明白之后,由经验丰富的“架构师”或者“项目经理”之类的人,对难度、开发周期等因素进行考量,然后选用一个合适的形式(比如B/S或者C/S)进行建模设计,然后弄出一个由若干project组成的Solution。继而由各种层次的高级、中级、初级程序员们来进行实现。而这个设计过程一旦完成,通常项目的结构就不太可能做任何修改了。(传统的瀑布模型及其衍生就是这样的)

  同样的任务如果在我们现在这个外籍团队面前,将会是怎样处理呢?

  老外会按程序逻辑的重要程度和功能依赖性,把项目切割成适合于一两周的小块(我们团队是做敏捷开发的),这一块就是一个基本的迭代周期的工作任务。我们不用关心全局,不用关心整体,只要心安理得的在这个周期之内写出一个符合要求的小块就行了。至于剩下的任务——那是另一个迭代周期该去关心的事情。

  由此看来,很多人就会问了,这样的开发,不就没有架构了吗?

  看起来确实如此,不过敏捷开发中有一个基本概念就是“能正常运行的代码是最大的财富,是最重要的东西”。当下一个周期(甚至是下下下下个周期)中发现之前的代码需要进行结构上的调整以达到某种目的的时候,只要进行重构就行了。简单来说,把某几个现有方法组织成一个类,或者把某几个现有的类抽象出一个接口,这种“常规动作”并不需要消耗太多的时间,而且难度并不高。相反的,由于每次进行结构上的“重构”都有明确无误的目的,所以基本不可能产生“过度设计”或者完全走偏方向的问题。而假如运气够好,经过了N个迭代周期还没发现任何必要进行结构上的调整,则说明“平铺直述的结构也不失为一种优良的架构”。

  所以,小结一下:老外的“架构”其实是一种过程,而国内的“架构”往往指的是一种目标。国人往往会“为了架构而架构”(这种项目代码我真见过不少,比如客户要求你用某种架构)或者“为了学习而架构”(这种也很多)、“为了耍酷而架构”(有些公司愿意炫耀技术),架构是一种目标、一种结果,达到“架构优美”了,就似乎意味着成功。而老外的脑子比较单纯,架构是为了完成任务,能完成任务(并且利于维护)的架构就是好架构。那是一个不断自我完善的过程。

  这样也就不难理解,为什么各种外国架构书籍看起来都那么晦涩难懂了:一个自下而上,在重构中实现架构;一个自顶而下,用推出架构来让程序员实现,这完全是两条不同的路线,自然是风马牛不相及的。

  当然,是不是老外所有的项目开发都不重视“架构”呢,只要“重构”呢?

  那也不尽然!

  我现在所处的团队是规划中四个团队中的一个。这四个团队中,一个负责核心业务逻辑(我所处的这个team),一个负责业务相关数据的来源,一个负责前端界面,最后一个位于欧洲的团队负责支付平台(它包装了欧/亚各国网银、支付宝等支付接口在内的支付系统的封装调用)。这种显然不能称之为“结构”了。这种架构,和我们最大区别在于,我们的“架构”通常为了实现功能,而老外的“架构”则侧重扩展能力,也就是俗称的“可伸缩性”。

  总结一下,在架构设计领域,洋人是有绝对发言权的。软件的价值在于实现用户价值,而不在于技术架构。比如有些人钻研技术,就希望掌握一套合适的手法/套路甚至是代码生成器,然后将这个当做“架构”、当做万灵丹处处推行——但是别忘了,二十年前那本近乎于开发圣典的《人月神话》早就告诉我们了——没有银弹!(什么。你还不知道这是什么意思?那赶紧回去补习一下哟!)

  架构不仅仅是分层结构,也不是某种一成不变的套路或者代码生成器。从代码重构做起,戒骄戒躁,掌握“架构”这个个“大”东西并不困难!

  顺便一提,架构的背后,其实是岗位的精细分工和工程化管理手段的应用。在下面的篇幅中,我会继续补充,今天就写到这里了

  2012-05-10 23:38:33 

posted @ 2012-05-13 20:49  Michael YU  阅读(918)  评论(2编辑  收藏  举报