架构是一个很“大”的词。在我的印象中，很多国内公司所谓的“架构师”往往自己都很难对架构这个词下一个准确的定义，如果一定要说什么是“架构”的话，又会有一些学院派套弄出几个生涩的书面词汇弄得越发晦涩，让人觉得那是老外们高精尖的花样。
实际上我在工作中，老外们（题外话，我们CTO是个五十多岁的瑞典老头）没并没有过多的使用“架构”（architecture）这个词，更多的只是叫做“结构”（structure）而已。在大多数时候，我们的项目采取的都是小迭代周期，进行反复、频繁的重构（refactor），由此看来，架构其实并不是一个很“大”的东西，而是一种“具体而微”的花样。
举个例子来说：
面对一个项目，国内的团队往往会上上下下前前后后分析明白之后，由经验丰富的“架构师”或者“项目经理”之类的人，对难度、开发周期等因素进行考量，然后选用一个合适的形式（比如B/S或者C/S）进行建模设计，然后弄出一个由若干project组成的Solution。继而由各种层次的高级、中级、初级程序员们来进行实现。而这个设计过程一旦完成，通常项目的结构就不太可能做任何修改了。（传统的瀑布模型及其衍生就是这样的）
同样的任务如果在我们现在这个外籍团队面前，将会是怎样处理呢？
老外会按程序逻辑的重要程度和功能依赖性，把项目切割成适合于一两周的小块（我们团队是做敏捷开发的），这一块就是一个基本的迭代周期的工作任务。我们不用关心全局，不用关心整体，只要心安理得的在这个周期之内写出一个符合要求的小块就行了。至于剩下的任务——那是另一个迭代周期该去关心的事情。
由此看来，很多人就会问了，这样的开发，不就没有架构了吗？
看起来确实如此，不过敏捷开发中有一个基本概念就是“能正常运行的代码是最大的财富，是最重要的东西”。当下一个周期（甚至是下下下下个周期）中发现之前的代码需要进行结构上的调整以达到某种目的的时候，只要进行重构就行了。简单来说，把某几个现有方法组织成一个类，或者把某几个现有的类抽象出一个接口，这种“常规动作”并不需要消耗太多的时间，而且难度并不高。相反的，由于每次进行结构上的“重构”都有明确无误的目的，所以基本不可能产生“过度设计”或者完全走偏方向的问题。而假如运气够好，经过了N个迭代周期还没发现任何必要进行结构上的调整，则说明“平铺直述的结构也不失为一种优良的架构”。
所以，小结一下：老外的“架构”其实是一种过程，而国内的“架构”往往指的是一种目标。国人往往会“为了架构而架构”（这种项目代码我真见过不少，比如客户要求你用某种架构）或者“为了学习而架构”（这种也很多）、“为了耍酷而架构”（有些公司愿意炫耀技术），架构是一种目标、一种结果，达到“架构优美”了，就似乎意味着成功。而老外的脑子比较单纯，架构是为了完成任务，能完成任务（并且利于维护）的架构就是好架构。那是一个不断自我完善的过程。
这样也就不难理解，为什么各种外国架构书籍看起来都那么晦涩难懂了：一个自下而上，在重构中实现架构；一个自顶而下，用推出架构来让程序员实现，这完全是两条不同的路线，自然是风马牛不相及的。
当然，是不是老外所有的项目开发都不重视“架构”呢，只要“重构”呢？
那也不尽然！
我现在所处的团队是规划中四个团队中的一个。这四个团队中，一个负责核心业务逻辑（我所处的这个team），一个负责业务相关数据的来源，一个负责前端界面，最后一个位于欧洲的团队负责支付平台（它包装了欧/亚各国网银、支付宝等支付接口在内的支付系统的封装调用）。这种显然不能称之为“结构”了。这种架构，和我们最大区别在于，我们的“架构”通常为了实现功能，而老外的“架构”则侧重扩展能力，也就是俗称的“可伸缩性”。
总结一下，在架构设计领域，洋人是有绝对发言权的。软件的价值在于实现用户价值，而不在于技术架构。比如有些人钻研技术，就希望掌握一套合适的手法/套路甚至是代码生成器，然后将这个当做“架构”、当做万灵丹处处推行——但是别忘了，二十年前那本近乎于开发圣典的《人月神话》早就告诉我们了——没有银弹！（什么。你还不知道这是什么意思？那赶紧回去补习一下哟！）
架构不仅仅是分层结构，也不是某种一成不变的套路或者代码生成器。从代码重构做起，戒骄戒躁，掌握“架构”这个个“大”东西并不困难！
顺便一提，架构的背后，其实是岗位的精细分工和工程化管理手段的应用。在下面的篇幅中，我会继续补充，今天就写到这里了
2012-05-10 23:38:33