软件工程实践者的思想(PDF格式)-第4部分
按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
能完整地阅读和理解这段文字是很正常的。部分读者甚至可以跳
过这段引文，直接阅读后面的结论。而有兴趣的读者，可以在我
的网站上读到它的全文（http：//doany/） 。
…21
…………………………………………………………Page 26……………………………………………………………
第 2 章 是懒人造就了方法
Soul：现在的程序是按照冯。诺伊曼的第一种方案做的，本来就是顺序的，
而不是同步的。CPU怎么说都是一条指令一条指令执行的。
我 ：面向过程是对“流程”、“结构”和“编程方法”的高度概括。而
面向对象本身只解决了“结构”和“编程方法”的问题，而并没有
对“流程”加以改造。
Soul：确实如此。确实如此。
我 ：对流程进一步概括的，是“事件驱动”程序模型。而这个模型不是
OO提出的，而是Windows的消息系统内置的。所以，现在很多人迷
惑于“对象”和“事件”，试图通过OO来解决一切的想法原本就是
很可笑的。
Soul：我先停下来，和你讨论这个问题，顺便补充到书里去。
我 ：如果要了解事件驱动的本质，就应该追溯到Windows内核。这样就
涉及到线程、进程和窗体消息系统这些与OO无关的内容。所以，整
个RAD的编程模型是OO与OS一起构建的。现在很多的开发人员只知
其OO的外表，而看不到OS的内核，所以也就总是难以提高。
Soul：OO里面我觉得事件的概念是很牵强的，因为真正的对象之间是相互
作用；就好像作用力和反作用力；不会有个“顺序”的延时。
我 ：应该留意到，整个的“事件”模型都是以“记录”和“消息”的方
式来传递的。也就是说，事件模型停留在“面向过程”编程时代使
用的“数据结构”的层面上。因此，也就不难明白，使用／不使用
OO都能写Windows程序。
我 ：因为流程还是在“面向过程”时代。
Soul：所以所谓的面向对象的事件还是“顺序”的。所以我们经常要考虑
一个事件发生后对其他过程的影响，所以面向对象现在而言是牵强
的。
我 ：如果你深入OS来看SEH，来看Messages，就知道这些东西原本就不
是为了“面向对象”而准备的。面向对象封装了这些，却无法改造
它们的流程和内核。因为OO的抽象层面并不是这个。
我 ：事件的连续性并不是某种编程方法或者程序逻辑结构所决定的。正
如你前面所说的，那是CPU决定的事。
Soul：比如条件选择，其实也可以用一种对象来实现，而事实没有。这个
是因为cpu的特性和面向对象太麻烦。
我 ：可能，将CPU做成面向对象的可能还是比较难于想象和理解。所以
MS才启动 Framework。我不认为在面向对象方法上有什么
…22
…………………………………………………………Page 27……………………………………………………………
『大道至简』
超越，也不认为它的FCL库会有什么奇特的地方。——除了它们足
够庞大。但是我认为，如果有一天OS也是用 Framework来编写
的，OS一级的消息系统、异常机制、线程机制等等都是的，都
是面向对象的。那么，在这个基础上，将“事件驱动”并入OO层面
的模型，才有可能。
Soul：所以我发觉面向对象的思维第一不可能彻底，第二只能用在总体分
析层上。在很多时候，实质上我们只是把一个顺序的流程折叠成对
象。
我 ：倒也不是不可能彻底。有绝对OO的模型，这样的模型我见过。哈
哈～～但说实在的，我觉得小应用用“绝对OO”的方式来编写，有
失“应用”的本意。我们做东西只是要“用”，而不是研究它用的
是什么模型。所以，“Hello World”也用OO方式实现，原本就只
是出现在教科书中的Sample罢了。哈哈。
Soul：还有不可能用彻底的面向对象方法来表达世界。 因为这个世界不
是面向对象的。 是关系网络图，面向对象只是树，只能片面的表
达世界。所以很多时候面向对象去解决问题会非常痛苦。所以编程
退到数据结构更合理，哈哈。
我 ：如果内存是“层状存取”的，那么我们的“数据结构”就可以基于
多层来形成“多层数据结构”体系。如果内存是“树状存取”的，
那么我们当然可以用“树”的方式来存取。——可惜我们只有顺序
存取的内存。
我 ：程序＝数据＋算法
——这个是面向过程时代的事。
程序＝数据＋算法＋方法
——在OO时代，我们看到了事件驱动和模型驱动，所以出现了“方
法”问题。
Soul：我的经验是：总体结构…》面向对象，关系…》数据结构，实现…》算法
Soul：看来我们对面向对象的认识还是比较一致的。
我第一次提到我对程序的理解是“程序=数据＋算法＋
方法”，便是在这一次与 Soul 的交谈之中。在这次的交谈
…23
…………………………………………………………Page 28……………………………………………………………
第 2 章 是懒人造就了方法
中的思考仍有些不成熟的地方，例如我完全忽略了在面向
过程时代的“方法”问题。实际上面向过程开发也是有相
关的“方法”的。
所谓“面向过程开发”，其实是对“结构化程序设计”
在代码阶段的一个习惯性的说法。而我忽略了这个阶段的
“方法”的根本原因，是即使没有任何“方法”的存在，
只需要有了“单元（Unit） ”和“模块（Module） ”的概念，
在面向过程时代，一样可以做出任意大型的程序。在那个
时代，“方法”问题并不会象鼻子一样凸显在每一个程序
员的面前。
面向过程开发中，“过程（procedure） ”是 CPU 提供的，
“单元（unit） ”则是编译器提供的（机制） 。程序员不需要（至
少是不必须）再造就什么“方法”，就可以进行愚公式的开
发工作了。
如果不出现面向对象的话，这样伟大的工程可能还要
再干一百年……
而与“面向对象”是否出现完全无关的一个东西，却
因为“过程”和“单元”的出现而出现了。这就是“工程
（engineering ）”。
…24
…………………………………………………………Page 29……………………………………………………………
第3章 团队缺乏的不只是管理
“言人三为众，虽难尽继，取其功尤高者一人继之，
於名为众矣。”
——《汉书·高惠高后文功臣表序》颜师古注
1。 三个人的团队
①
《汉书》中说“言人三为众 ”，是指三个人就算得上
是“众”了。这里的“众”应该理解成一个群体，亦或者
说是一个团队。
团队是至少以三个人为规模的。这有其合理性。为什
么呢？首先一个人算不得团队，那是个体。两个人则互相
支撑，古文中“从”字是二人互立，就是这个意思。然而
二人互立并不算团队，因为没有监督。三个人便可以构成
团队，这样便有了团队的一些基本特性：主从、监督和责
任。
一个人的开发行为可以成功，这取决于个人努力。大
家熟知的 KV100 、KV200 反病毒软件，最早就是王江民
先生一个人做出来的。二人小组如果能相互支撑，那也是
① 片面地理解成“三人为众”是不对的。“三”在这里是虚词，指
的是很多人的意思。然而，古人以“三”来泛指很多人或者群体，
则是很值得玩味的事。
…25
…………………………………………………………Page 30……………………………………………………………
第 3 章 团队缺乏的不只是管理
可以获得成功的，同样作为反病毒软件的 AV95 在 95 到
97 年成功占据反病毒软件市场之一隅，就是周辉和刘杰
先生两个人的作品。
然而到了三个人的时候呢，就得选个领导了。颜师古
为《汉书 ·高惠高后文功臣表序》作注时，引用了孟康的
话，说“取其功尤高者一人继之，於名为众”，简意就是
功高者代替群体受功。古人的受功当然包括封侯晋爵，因
此这便仿然成了惯例而推广开来，功劳大的、能力强的便
成了团队中的领导角色。
殊不知彼时彼事，目的并非要选领导，而是要表彰功
绩。项目结束会议上，总经理说：“M 项目完成得很好，
小 S 的进步尤其之大，他独立完成了全部核心代码的编
写，因此月奖加三倍”。奖不可谓不丰，然而这并不代表
在下一个项目该让小 S 来做项目经理。
同样，三板斧定了瓦岗寨的程咬金，功不可谓不高，
技不可谓不强。但程咬金不是将帅之才。
做管理起码需要能承担责任，这是最基本的素质。
《史记·循吏列传》记载了李离伏剑的故事。春秋时
晋国最高司法长官李离，因为“过听杀人”，断狱失误，
把一个不该处死的人错判了死刑。随后“自拘于廷，请死
于君”，晋文公欲以其下属有过为由免他的罪，而李离说：
“臣居官为长，不与吏让位；受禄为多，不与下分利。
今过听杀人，傅其罪下吏，非所闻也。”
随后拔剑自杀了。
…26
…………………………………………………………Page 31……………………………………………………………
『大道至简』
同样的道理，你的项目经理职位又没有让给别人做，
你拿的经理级工资又没有分给别人，那项目失败了，你为
什么要把责任推到别人头上呢？
三人团队中的那个领导，不是要程咬金一样的牛人，
而是要李离一样的死士。项目完成不了，切脑袋的事倒不
必做，递交辞呈的那点勇气总是要有的。
2。 做项目 = 死亡游戏 ？
如果项目做不成就要掉脑袋，那就象好比是枕着铡刀
在做程序；如果项目失败就要交辞呈，那可能就从来不会
有项目经理。
为什么这么说呢？
…27
…………………………………………………………Page 32……………………………………………………………
第 3 章 团队缺乏的不只是管理
从管理角度来看，项目失败与否与项目经理的经验直
接相关。我曾经听过一个来自澳大利亚的讲师说软件工
程。她说到项目的成功是两个方面的评估：
） 项目完成质量
） 项目完成时间
由于项目的时间是在项目前期对项目工期的设定，因
此我问这个讲师：什么方法能保证预期的工期是正确的，
或者说是可以完成的。
讲师的回答很有意思：经验丰富的工程师能尽可能接
…28
…………………………………………………………Page 33……………………………………………………………
『大道至简』
近地预估工期，但没有办法保障（预估的）工期是绝对合理
①
的 。
那么进一步的推论是，由于没有绝对合理的工期，所
以项目的完成时间可能总是被进度变更所修正，所以项目
也就总是不能“成功”。
——看来外来的和尚（ 包括尼姑） 也未必能比本地的
更会念经。在这一点上，来自澳大利亚的讲师，与来自北
极的爱斯基摩人（如果他们也念经的话） 如出一辙。
项目工期的问题不能解决，就不能保证项目成功。只
有经验更加丰富，才能更尽可能地逼近“合理的工期”。
因此在此之前，项目经理面临的就是失败。这个失败可能
不是项目经理本身能力所决定，或者也不是团队成员的工
作所决定，而是在一开始，那份给客户的项目协议就签错
了。
项目经理是需要时间来成熟的。他
