与架构师同行(序)

我认识周爱民多年，本书是他的第五部作品，也是"周爱民风格"最浓烈的一部。作者把"冥想"式的写作发挥到了新的高度，任何一个小小的、普通人熟视无睹的问题、现象、矛盾，都能引起作者滔滔江水连绵不绝的思考，追根溯源的论辩和富有禅机的跳跃的联想。这是周爱民思维的特点所在，他能够长时间连续不断地思考一个问题，越挖越深，既不知疲倦，也不向现实妥协。这是一种独特的思维品质，是如我一样普通人所难以企及的，也是这个时代所稀缺的。这种独特的思维品质，既是这本书价值的源泉，也成为对读者，以及我这个受托作序的非技术人来说较大的挑战。所以在这篇序言里，我不敢说能把握这本书的思想实质，但会坦率地谈谈我对书中所涉及的一些问题的个人看法。

首先是关于这本书的主题和内容。这本书当然是在谈软件开发的问题，但涉及的方面又不仅仅是开发，甚至可以说，作者主要不是在谈开发，而是在谈组织。而且他不是在谈某一种具体的组织，不是代码的组织、构件的组织、架构的组织，甚至也不是工程的组织和人的组织，他是在整体上来思考"组织"这件事情的一般原则，然后用其所思所得来"格"代码、"格"架构、"格"工程、"格"人的组织。从书中，读者可以跟着他的思路去体会他是如何"格物致知"，然后又反过来"致知格物"。

为什么要把组织问题放在中心位置去探讨？因为良好的组织是解决软件规模问题的希望。而随着软件行业的逐渐成熟，组织和架构已经取代编码而成为软件开发的核心问题。

十几年来软件开发行业发生了一个重大的变化，那就是软件开发已经渐渐演变成了一个以配置为主、编程为辅的过程。这个观点最早是20世纪90年代中期由著名的C++网络编程框架ACE的创造者Doug Schmidt教授提出来的。当时一系列重要的基础性的标准，如C语言、TCP/IP协议、POSIX标准已经奠定，Schmidt教授意识到，一旦一小部分人开发出足够多的、高质量的、可配置的核心软件，其他人就没有必要重复发明轮子，而是可以站在他们的肩膀上，通过配置和扩展来完成任务。尽管配置的过程本身还是通过编码的方式来完成的，但本质上这些代码只是在定制核心软件的运作方式，它们的技术难度比编写高质量核心软件至少要低一个数量级。

这个观点被历史证明是非常具有远见的，特别是随着Java等跨平台语言的风行、开源运动的兴起和Web的成功，绝大多数不同种类的应用都在共享相同的基本特征，这样也就出现了一大批门类齐全、质量过硬的核心知识资产，它们以基础软件、中间件、框架、程序库和开源代码的方式存在，可以被以各种方式复用。在这些资产之上，程序员社群形成了有效的、开放的知识分享机制，从而使得一般性的软件开发变得相对容易，而将软件开发这件事情的挑战上移到架构层面，或者更具体地说，如何有效地分配职责、组织资源、建立资源节点之间的关系和契约，已经成为大规模软件开发的根本问题。

这就是本书的发力点。作者正是站在架构师的高度上来看待软件开发，甚至更大的意义上，看待以软件开发能力为核心的企业在产品战略、人力配置和文化方面的组织问题。作者在过去几年里，先后在两家超大规模互联网企业中做架构师，他在其中的矛盾、迷惘、挣扎和成就是这本书的思想源泉，而他对于架构师角色的实践和领悟，也是这本书的价值所在。作者认为，软件开发发展到今天这个阶段，架构问题是真正的方向性问题，架构之争是真正的路线斗争，架构错误是致命的、不可挽回的错误。只要架构适用，其他的错误都是局部性的、可以控制的。一旦架构发生方向性错误，无论是人的架构，还是软件的架构，其代价可能就是一个项目甚至一个企业组织的生命。因此，这本书通篇都在讲架构问题，讲组织问题，讲规模问题。读这本书的时候，如果能够始终记住这一点，那么理解起来会容易一些。

看上去这本书的四个篇章，彼此相对独立，谁也不挨着谁。但实际上，贯穿全书的主轴，就是从宏观的组织关系上和微观的角色职责上，在不同的领域里反复谈组织架构问题。在这个过程中，作者也提出了一些鲜明而有趣的想法，比如让架构师成为开发团队中的核心角色，甚至把人员和项目管理这样传统强势的角色也仅仅视为架构师的支撑角色。作者的核心观点，说到底很朴素，无论是在人员组织还是技术架构上，作者提倡各就各位、各司其责、不增不减、不垢不净的风格，尽量简化由于异动而导致的非本质复杂度。这些观点，至少成一家之言，值得思考。

当然，用这种"中心思想"、"段落大意"式的语文课方式来归纳这本书，是非常不合适的，因为这本书的写作风格确实是非常独特。以周爱民的水平和资历，他大可以像很多流行书作者一样，居高临下，弄出几条十几条原则，以一种非常具有"架构感"的组织方式来组织这本书的内容本身。但是如果架构问题能够以这种方式讲清楚的话，那它早就不是问题了。如作者所说，架构本身是"以序容易"，是为了约束系统自由度，从而使架构之外的决策空间更小、更容易，那么架构本身的设计，则成为重点和难点。如何成为好的架构师，如何教授和交流架构设计的经验和思想，迄今仍然不能说找到了办法。作者采取的方式，就是老老实实把自己的思维过程和喃喃自语都很原生态地记录下来，从而形成一本"心语"之作。因此，如果读者也能够"心心相印"，潜下心来仔细品读这本书，那么就相当于跟作者一起进行了一段旅行对话，或者，一起在思维的教武场里杀个几进几出。或许这种如切如磋、如琢如磨、反复捶打、反复锻造的风格，倒确实能够帮助有心的读者获得一些架构设计的经验。

因此，无论从内容上，还是从行文风格上，这本书都是非常独特的，也有其独特的价值。作者的作品，一向是长销之作，其价值也往往需要一段时间才能被真正认识，我不敢说自己能够在短暂的阅读当中充分理解这本书，但是我相信其中所蕴藏的价值和诚意。

当然，无论对于书的观点、内容还是展现形式，我也有自己的看法，其中也有不同意见。

比如在行文上，我认为作者对于读者设置了比较高的理解门槛，要求读者必须跟着他的文字和思绪流动。如果读者以当下流行的速读式阅读、跳跃式阅读甚至微博式阅读的方式来读这本书，我敢说不但不可能把握其中的精华，甚至连一些基本概念可能都会搞错。

再比如在内容的铺述方面，上至人员组织架构，下至程序设计语言中一些架构性的设计，在一本300多页的书里跨越如此巨大的领域，我相信是前无古人。尽管作者确实始终以一主线贯穿，但是能够洞解其中滋味的读者，恐怕也是少之又少。好在读一本书，也并不是要求全部理解，懂一点，学一点，常读常新，也是一种不错的体验。

至于作者的思想，我能够置喙之处不多。勉强要说一点，可能就是一个搭配问题。从组织、人员、文化到技术、编码，既然每个层面上都有自己的架构问题，都有若干不同的架构选择，那么可能不同层次之间架构选择的搭配问题，或许也应该是这本书应该触及的。一个团队的人员组织架构，必须与其行业领域和产品项目类型彼此搭配，也必须与其选择的技术框架和架构彼此搭配，也必须与其软件过程的管理方法彼此搭配。抽象地在每一个层面上去谈什么是好、什么是坏，是没有意义的。CMMI的模型是个好的过程架构，但是谷歌和Facebook决不会采纳，因为这个架构与其他领域的既定架构不兼容。什么样的组织架构与什么样的技术架构搭配是合适的，这本身是一个非常有趣和有意义的问题，可惜这本书落墨不多，不得不说是一个可以改进的地方。

总的来说，这是一本需要认真读的书，也是一本值得认真读的书。它的价值需要读者与作者在思维互动中逐渐体现。如果你是这样的读者，我会愿意向你推荐这本书。而如果你并不喜欢深彻的冥想式的阅读和思考，那么你很难从这本书中获得太多。

孟岩

……