旧文重发:行在道上,从局部到全局——与师者高焕堂、赵善中先生谈《大道至简》
2010-02-01 02:55 乱世文章 阅读(164) 评论(0) 编辑 收藏 举报
本文载于《程序员》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图的最外层——那个层面约束了工程、实施的形式,并适时调整着这种形式;那个层面看得到工程的目标方向,也适时地调整着这种目标方向——真正决定着工程生死的,在工程之外。
当然,工程本体的病患是有的,例如说“牛屎图”中的工具与方法不匹配了,或者质量模型中的时间与质量冲突了等。这些病患并不会因组织的调适而消亡,但是组织的调适能给出治疗这些病患所需的时间、空间和基础。因为所有的病患其实都是长在组织这个“体”之内外的,组织环侧与开放自身,毛病就显露出来了——这如同人的屁股上长了疮体,总是要抬抬屁股才能抺得上药的。
从这一点来看,“从局部看来,向全局看去”,既是我这五年来工程实践的所为,也是我将来必行的方向。就软件开发而言,跳出具体角色的限制,看到“一个组织”和“工程的实施”的全局,也许正是破局的机要?
五、欲辩已忘言
所谓“书不尽言,言不尽意”,我们通过文字看到的,仅仅是一个人所言讲的一部分;而他所言讲的,又仅仅是他的思想的一个部分。
所以高焕堂、赵善中两位老师在对拙作的点评中所讲述的,不过是他们思想之一隅;我们由此所能见的,也不过是两位师者学识之一斑。我依了这斑斑点点、去评述与争辩,便如同盲者抚大象而所言的“如箕如石、如杵如臼”。所以这篇文章,是明知不可为,而强为之。但之所以强为之,是因为不辩不见——连辩的过程都没有了,我们又用什么来视见大象的本体呢?
知识的价值在于传播,论辩的至境在于不言。如同《大道至简》一书说过的:“思想已经领悟,文字的、纸质的东西还有什么价值吗?”对于我与几位师者、友人所论的,如果你已经听了,那么就忘掉我们所说所辩的;如果你还没有听,或在这短短的文章里还没有听明白,那么就等等这本“点评版”的出版吧。