大道至简软件工程实践者的思想

大道至简——软件工程实践者的思想周爱民(Aimingoo)著序2004年11月初爱民(Aimingoo)第一次把他的书稿给我，我翻看了一下，第一反应讲的是感想。这不错，在技术界就是需要有真正实践经验的专家把他的思考和心得与我们分享。Aimingoo在Delphi领域颇有名气，其技术钻研的深度直达系统核心层，从其著作《Delphi源代码分析》可见一斑。不过接下来第二反应就是太薄了，能不能加厚啊。比如说这些感悟都是有其来源的，可以把实际案例啊，背景故事啊都加上。不然太薄了，出版社没有办法出版啊。——国家对于出版的书号是有严格控制的，所以书号是有成本的。一本讲技术高端的图书销量肯定是有限的，以现实情况而言，如果很薄定价就只能比较低，成本无法回收。而且内容只是心得，没有案例，读起来也很硬，对读者的要求也很高，销量可能就更少了。爱民听完我的意见，还是坚持这本书就是这样的风格。出厚书违背了他的本意，要不然怎么叫“大道至简”。书稿在2005年3月杀青后，我从7月开始在《程序员》上陆续选择其中的三章发表，看看读者的反馈。不过限于篇幅，删掉了一些内容，不能完整体现出作者系统思考的脉络，也比较遗憾。2005年11月爱民跟我讨论到即使没有出版社愿意出版印刷，也要把他的作品用电子版问世，并邀我作序。我十分感慨，在这个浮躁功利的社会，难得还有这样的朋友。现在，我又仔细从头到尾读了一遍。很多作者写书是为厚而厚，大部分内容都是水分，作者原创经验精华只有很少，甚至没有。而这本书是作者从事十年开发工作的总结，虽然不厚，却闪烁着独立思考的光芒。世界“虽变化万端，而理为一贯。”作者在软件开发一线浸淫近十年，回头思考何为开发的本源？这些理论、方法的本质为何？粗粗一看，这些道理稀松平常，专家教授无数著作早就谈过，还用作者来写吗？其实不然，理论都是从实践而来，但我们学习软件开发的时候，是先掌握这些专家总结的果实，而不是探求本源，所谓“知其然而不知其所以然”。这些道理看似都知道，但却没有真正体会上身，在实践中最重要的去应用这些道理，而不是方法。大多数人看书都希望学到一些招数、方法，能尽快在工作中用上，这是不错。但要想真正达到更高境界，就必须明白背后的道理。真正的专家是从根上解决问题的，所以大物理学家杨振宁在北京大学针对本科生讲物理学，讲得深入浅出，大受欢迎，就是因为杨先生可以从历史本源来剖析物理定律公式。只有招数，不明道理，碰到变化的情况，就束手无策了。而在软件开发中，每个团队、每个项目都不是尽然相同的。明白道理，才能知变通之道。这本小书不是一本教你项目管理，软件工程或者编程技巧的书籍，他是一本闪烁思考光芒的技术散文集，我衷心祝愿这本书的读者，能把这本书当作一位朋友的思考，一位朋友的总结，来参照自身，这样就会有收获，有想法了。我也和爱民建议，这本书的很多主题还可以展开，无论是批评，还是讨论，只要有兴趣的朋友，可以给爱民，我或者《程序员》杂志社写信，我们诚恳邀请各位来共同思考，共同把实践经验与大家分享，这样意义也就更大了。期望大家的参与，谢谢。蒋涛2005．11月[e-mail]注：关于书的序的讨论，参见附录之一。电子版发布前言我终于决定发布这本书的电子版了。完成这本书的时候，我已经在这个行业里做了十年了。这十年来，我对自己的经历做过两次回顾。第一次是关于技术的，这造就了那本《Delphi源代码分析》，是讨论开发的技术和方法细节的。第二次就催生了这本《大道至简》，讨论的则是工程、管理中的思想。我其实是很希望这本书能放在读者的书架案头，而不是放在电脑的某一个目录中。因为它应当是一本可以阅读和品味的书，而不是在电脑中备查的技术资料。然而，我在决定担任这家公司的软件架构师的同时，我就意识到，我没有足够的精力来运作这本书。——我的意思是如果要把他做成纸质的书的话，我没有足够的精力。出版商是要寻求利润的。——于此，我一早就知道。但我从来不知道：到底一本书簿一点或者厚一点，哪个会让出版商更有利润。我只想写一本“阐明软件工程的思想核心”的书。这本书要很容易就读明白，还要很容易就想通，还要很容易就知道：工程其实很简单，只是大家把它做复杂了。然而问题是：我把它写得太简单了，以至于只写了110页，就没有必要再写下去了。我当然可以把一本书写得很复杂，或者很厚。这很容易，就如做Coder一样：把代码写烂或者写乱都很容易，要想写得简洁却远非易事。代码写得太简洁，老板会认为你在偷懒；书写得太薄，出版社就不愿意出。我看来是忘掉了侯捷先生说过的“买书如买纸”，以书的厚薄来论价值的故事。忘掉了就忘掉吧。好的一面是现在书变成了电子版，大家终于可以读到它了。不好的呢？我想大概不要钱的东西很难得到珍视吧：如果下载这本书只是因为收集，而不是阅读，那会是让我感到比讨论“买书如买纸”这样的事更为难过的。好吧。希望你能象对待纸质书籍那样来阅读这本《大道至简》。放心，我并不介意你把它打印出来放在床头。补充声明：我保留在传统媒体(书籍、杂志)上刊载、出版本书的权利。但允许任何人在网络上非商业性地、自由地、不加修改地传播这本书的电子版本。周爱民2005年10月14日:[e-mail]目录1.编程的精义1.编程的精义·······················································112.会或者不会写程序·············································133.程序=算法+结构········································144.语言··································································165.在没有工程的时代·············································162.是懒人造就了方法1.是懒人造就了方法·············································182.一百万行代码是可以写在一个文件里的············203.你桌上的书是乱的吗·········································234.我的第一次思考：程序=算法+结构+方法··········253.团队缺乏的不只是管理1.三个人的团队····················································292.做项目=死亡游戏?·······································313.做ISO质量体系的教训·····································334.谁动摇了你的制度？·········································365.“那我们就开始开发吧”··································386.组织的学问：角色·············································397.跟随蚂蚁。但不要栽进蚂蚁洞里。···················428.“什么是增值税发票？”··································444.流于形式的沟通1.客户不会用C，难道就会用UML吗？··············482.项目文档真的可以用甲骨文来写·······················503.最简沟通···························································534.为不存在的角色留下沟通的渠道·······················575.流于形式的沟通················································605.失败的过程也是过程1.做过程不是做工程·············································632.做过场·······························································653.实现，才是目的················································654.过程不是死模型················································665.“刻鹄类鹜”与“画虎类狗”··························696.工程不是做的，是组织的··································716.从编程到工程1.语言只是工具····················································732.程序··································································753.方法··································································754.过程··································································765.工程··································································786.组织··································································807.BOSS·································································828.上帝之手···························································847.现实中的软件工程1.大公司手中的算盘·············································872.回到工程的关键点·············································923.思考项目成本的经理·········································944.审视AOP··························································975.审视MDA························································1008.是思考还是思想1.软件工程三个要素的价值·································1032.其实RUP是一个杂物箱···································1043.UML与甲骨文之间的异同·······························1054.经营者离开发者很远，反之亦然······················1065.矛盾：实现目标与保障质量·····························1076.枝节与细节······················································1087.灵活的软件工程···············································110第1章编程的精义“虽我之死，有子存焉；子又生孙，孙又生子；子又有子，子又有孙。子子孙孙，无穷匮也。而山不加增，何苦而不