旧文重发：行在道上，从局部到全局——与师者高焕堂、赵善中先生谈《大道至简》

本文载于《程序员》2009.10期

行在道上，从局部到全局

——与师者高焕堂、赵善中先生谈《大道至简》

 

五年前，因为偶然所得，我画下了一个名为“软件工程层状模型（EHM）”的图。随后，我在这个图的思维框架里面，回顾了自己数年以来的工程与软件开发实践，写下了一本《大道至简——软件工程实践者的思想》。从那时起，我一直徘徊在软件工程与技术研发之间。与大多数人不同的是，这种徘徊不是迷茫的，而是清醒的，至少有一个较为清醒的方向。

对于在早些时候一些人对提出的《大道至简》的异论，我的确愤怒过、争辩过。直到我把愤怒之心与争辩之行都彻底地放下，我才看到了那些游离在EHM模型内外的、工程内外的东西——很明显，一本《大道至简》讲不完整个的工程。那么，它到底讲了些什么？有什么疑问？以及，未来该往何处去探索？

这，就是我这五年来的问题。

一、《大道至简》点评版的起因与原则

对《大道至简》的反思始于其纸质出版（2007年3月）之前。2005年末，我开始担任架构师，随着对这一角色的深入，我也渐渐地发现：EHM图中没有架构角色。非但没有，而且架构这个角色还放不到EHM图中去。这成为我在相当长的时期里的困惑。

大概近两年后，我对架构这个角色有了一些领悟，我认识到：EHM只是工程的一个局部视角，而架构这个角色是站在这个视角上无法看到的。所以“EHM图中不包括架构”这个问题我在出版《大道至简》之前就已经知道，但我并没有予以讲述，是因为我自觉没有力量去把它讲清楚。所以无论朋友与读者们如何谈论这点，我是很少发言回应的。

2007年2月间，我第一次读《人月神话》，为这本书所揭示出来的工程历史（以及它与现实惊人的相似）而深深震撼。除了这种震撼，我还发现它与《大道至简》所讨论的没有本质上的不同。简而言之，这两本书是在相同的方向上行进着。这是我首次自我肯定了《大道至简》一书的内容及其组织的合理性。

在2008年离开盛大去北京的前后，我第一次明确了《大道至简》一书在整体上的不足——只有破坏，没有建树，即所谓只破不立。这直接导致读者在阅读时缺乏整体感。对于初学者与实践者来说，这本书有助于他们在种种“工程方法”面前披荆斩棘，但荆棘厘清的目的何在？前方是什么？或者该向何处去？……这些在《大道至简》中是没有答案的。

虽然五年来我不断地从内容与形式上对《大道至简》予以肯否，但是我从五年前所站的那个工程的侧面看去，问题仍然如故。今年的QCon大会期间，再与博文视点的周筠老师谈到这本书，就考虑是否要再出一版《大道至简》的“点评版”。随后此事有幸得到来自台湾的高焕堂、赵善中老师的扶助，得众大家与同行不吝笔墨、时间评点《大道至简》，遂成新版。

正如我约请诸位时所言，“不惟说好，不怕说坏”，我一直谦恭聆听——所谓“反者道之动”，与你所对立的，既是你的动能，也是你的动向。我想《大道至简》的此次点评，除去其中观点以外的价值，大概便是这样的一种动向了吧。

二、谈工程与架构，与高焕堂老师

高焕堂先生自成章法，在《大道至简》中讲又一种大道。他在原书每一章中所论所述的，脉络相当清晰，甚至均可独立成篇。先生笔下的人物，既可倏忽来去，时而秦时而鲁，又可穿越时空，如牛顿、达芬奇一般有新兴思想、学进步文化。数个工程角色，积百千年文明进程于一体，在高先生的趣谈中，又骨骼血肉都在，实在难能可贵。

高先生指出，不但是“懒人造就了方法”，而且也是“方法常常造就了懒人”。我们学得的方法越多，了解这些方法的初衷、主旨就越少，离工程的真相也就越远。所谓“学而不思则罔”，我们学了几十年，学的还少吗？消化了多少？有多少只是皮毛？走了一套ISO，又来一套CMMI，一套又一套的模型，一个企业能被折腾几回、又经得起几回折腾？为什么《大道至简》中不讲具体可行的方法——我不是不要大家学，怕的是学而不思！

高先生也提到了他 “以序容易”的架构思想。他说：“工匠创造了桌子，平坦方正，提供完美之序，让你容纳书籍之乱，正是迈向伟大哲思的第一步。”序与乱（易、变化）的对立与协调，在一张桌子的方寸之间，便可时时看到。但又有多少人能从这其中看到架构思想呢？

与此相同的，高先生说“面向对象”其实是一种信仰：“Object-Oriented就是相信软件宇宙的一切事物都是Object，无论面向或背向，只要你相信它是Object就是Object”。但是如同不能指望一个佛教徒去骂佛祖一样，我们不能指望一个有信仰的人去指责信仰本身。“以序容易”的实质是“序”的确立，而“序”一旦确立了，就势必有游离于“序”之外的；面向对象确立了，也就必然有游离于面向对象之外的。那些笃信面向对象的只是无视于这些“游离的存在”，囫囵吞枣地用更高的成本去掩饰掉了这些东西。所以，对于高先生的话，我的理解是：“序”的存在只是在一定程度上给出“变化”与“不变”的边界，而不是“将变化消弥于无形”——认识到这一点，是学而思的第一步。

高先生还说“设计、工程和管理三足鼎立，始能竞其功”。光看字面，工程自然是要包括管理与设计环节的。但依我见，先生所谓“工程”其实是“工程的实施”，而设计则是“架构与设计”。理解这几个核心概念尤为重要，因为对于本书来说重要的是——EHM模型无法包含架构。所以，本书只是对工程现状的一种反思：在仅有工程实施与管理的情况下，工程是怎样一种局面？而从高先生的视角看去，(他言下)“那样的工程”又是怎样的一种局面呢？高先生说：“项目经理偏向管理职，而架构师偏向领导职；当项目经理与架构师能相辅相成时，可能就是峰回路转之刻。”对此，他仍有前提：“明确的管理，若能换成弹性的领导(如电影的导演)，或许会峰回路转也说不定。”所以，高先生的意思在于，架构师弹性的领导可能会给工程领域带来新气象。

除了从架构师的角度来研究其本质，“灵活管理模式”也是高先生倡导的话题。在对“第十章是思考还是思想”的点评中，高先生用了一个完整的小故事来讲述了软、硬件工程管理中的差异。这种差异可以推广到建筑工程与软件工程的差异上去——确实，很多时候软件工程是以建筑工程为参考模型的。而高先生在结尾写到：“一致的分工模式，各自发展的灵活管理模式。”由此可见，对于管理，高先生仍然是不赞同照搬某种规范模式的。“灵活”，则表明仍然无序可循，正如同高先生所讲——我们仍然在寻求“灵活管理模式”背后的“序”的路上。

三、再谈工程与架构，与赵善中老师

赵善中先生直接将话题切入到“架构的实作对软件开发的影响”，矛头直刺EHM图的核心：“（应该）以‘软件架构’当核心，而不是以‘程序＝算法＋结构’来当核心”。

EHM不是一个用于实作的工程模型，它只是从某个角度来分清了工程的一些环节而已——如同“牛屎图”一样，EHM是一个思考模型。相较而言，EHM更易于发现问题，而“牛屎图”更适于理清思路。如果非要从中找出个“更核心”或“更重要”，那么在“牛屎图”中要以哪一个作为最底层的圈子也成了问题。所以不妨抛开“谁更核心”的问题，把赵先生的模型与EHM图，以及与“牛屎图”作为相互补益的图来看，就所得多多了。

一个软件产品，究竟是被“开发”出来的，还是被“架构”出来的，或者是被“管理”出来的？这是一个争执不休的问题。一般人，尤其是技术出身者会直接否定掉第三种答案——他们认为“一个软件产品是不可能被‘管理’出来的”，它只能是被开发出来，而管理不过是在这个过程中的官僚角色罢了。但是，什么是管理？管理真的就是今天命令你工作、明天要你汇报进度的那个人吗？是不是我们把一些个人的私怨——对某个拙劣的管理人员的不满或轻视——带到了我们讨论问题的语境之中？

开发、管理和架构三种角色，站在自身角度，都会认为自己应该主导软件产品产出。这种观点我向来持以理解，而又置疑的态度。更渐而渐的，对所有“某个单一角色主导了软件产品产出”这样的观点，我都是表示怀疑的。正如高焕堂先生所提到的，这更像是一个“三足鼎立”的局面——这种“鼎立”的局面是一个衡势，这意味着它的平衡是瞬态的，且总在平衡与不平衡之间。所以，我的疑问是：这种局面对于软件的研发、项目的过程来说，是适宜的吗？应成为常态吗？

从组织学（而非单纯含义的管理学）的角度上来说，鼎立是组织的一种形式，是管理的一个施为目标，而不是管理本身——鼎立是体，而管理是用。虽然我认为高先生所指出的“鼎立”的局面可能是将来的方向，但如何去组织这样一个组织，管理它，并在这一局面上产出软件产品，是更进一步的学问。

在《大道至简》一书中，我基本否定了对软件开发过程的管理：“开发团队并不需要管理。或者说，在你没有弄清楚状态之前，不要去管它。”同样的，我也否定了传统的软件产品的“产出”观念：“工程不是做的，是组织的”。既然我们不能“管理”一个团队，又不能去“做”工程，那么我们该怎么办呢？在我跳出上述的三个角色之任一以后，我得到的答案是：组织。

更进一步地说，管理角色的任命、项目团队的结构等，都是在“形成组织”——这一过程中的产出和阶段性的决策。对于（泛义的）软件项目来说，没有一成不变的组织，也没有一成不变的模式。更进一步地说，在（具体的）某个软件项目中，组织的行为也处在变化之中。

我推崇高先生的“以序容易”的架构思想，而这也意味着我上面的言论会有一个推论：必然以及必须要存在一个“无序”到“有序”的过程——即，我们最终仍然会得到一些“组织模型”（以及管理、过程等模型），以规划和指导实施类同性质的项目。我不否认这一状态和阶段性结果的必然存在，但我怀疑现在是否已经存在——例如某些工程界吹嘘的“模型”，是否就是终极的银弹。

所以，回到赵善中先生的话题，在“工程实施”的语境下，究竟（现在）有没有确定的模型呢？我不置肯否，惟只置疑。架构是工程中的推手吗？是推动的原力吗？我从架构这一角色的位置——我的意思是权威性上看得到希望，我也从这个角色所必备的能力涵养上看得到希望，但是推及到组织及具体的项目，架构角色真的有这样的能量吗？谁赋予了他调适组织形态、降低组织内耗的责任？如果他没有这样的责任，那么组织如何生存？如果组织不存在了，岂不是仍然回到了皮之不存，毛将焉附的问题上了？

四、从局部看来，向全局看去

在这本书的点评里，高焕堂老师与赵善中老师不约而同地提出“要修改EHM模型”。我得先承认“修改后的新模型”的价值：我尝试在新模式的视角上做了些思考，并有新知新得。然而修改前后的模型，都如同EHM图本身所表现出来的：只是工程的局部。

EHM图看到了工程的一侧，同样，修改后的新模型也只看得到一侧。无论如何，我们所谈论的也无过于“一侧”而已。清楚地意识到“《大道至简》不过是盲人摸象的结果”，正是在我离开盛大的前后、在架构师这个角色上有了一些微末的实践所得以后。而这种“全局观”，正是架构师所必备的基本素质。

只有看得到全局，才看得到局部。眼界困于局部的人，和摸象的盲人没有多大分别。而架构师这一角色的实践给我带来的，正是在架构以外的体验和质疑：如果工程的本质不在架构，不在管理，也不在那些营营碌碌的开发者身上呢？

我看到的一种可能的答案，就是“组织”。它远远地在EHM图的最外层——那个层面约束了工程、实施的形式，并适时调整着这种形式；那个层面看得到工程的目标方向，也适时地调整着这种目标方向——真正决定着工程生死的，在工程之外。

当然，工程本体的病患是有的，例如说“牛屎图”中的工具与方法不匹配了，或者质量模型中的时间与质量冲突了等。这些病患并不会因组织的调适而消亡，但是组织的调适能给出治疗这些病患所需的时间、空间和基础。因为所有的病患其实都是长在组织这个“体”之内外的，组织环侧与开放自身，毛病就显露出来了——这如同人的屁股上长了疮体，总是要抬抬屁股才能抺得上药的。

从这一点来看，“从局部看来，向全局看去”，既是我这五年来工程实践的所为，也是我将来必行的方向。就软件开发而言，跳出具体角色的限制，看到“一个组织”和“工程的实施”的全局，也许正是破局的机要？

五、欲辩已忘言

所谓“书不尽言，言不尽意”，我们通过文字看到的，仅仅是一个人所言讲的一部分；而他所言讲的，又仅仅是他的思想的一个部分。

所以高焕堂、赵善中两位老师在对拙作的点评中所讲述的，不过是他们思想之一隅；我们由此所能见的，也不过是两位师者学识之一斑。我依了这斑斑点点、去评述与争辩，便如同盲者抚大象而所言的“如箕如石、如杵如臼”。所以这篇文章，是明知不可为，而强为之。但之所以强为之，是因为不辩不见——连辩的过程都没有了，我们又用什么来视见大象的本体呢？

知识的价值在于传播，论辩的至境在于不言。如同《大道至简》一书说过的：“思想已经领悟，文字的、纸质的东西还有什么价值吗？”对于我与几位师者、友人所论的，如果你已经听了，那么就忘掉我们所说所辩的；如果你还没有听，或在这短短的文章里还没有听明白，那么就等等这本“点评版”的出版吧。