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