按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
记》。
我 们 做 项 目 的 时 候 ， 如 果 也 不 留 下 历 史 记 录
（History） ，那么以后别人来看这个项目，也会是两眼一抹
黑，要么就象司马迁一样“存而不论”，项目便就此中止；
…54
…………………………………………………………Page 59……………………………………………………………
『大道至简』
要么就象“夏商周断代工程”一样，花大量的人力物力来
攻关。
维护旧项目比做新项目更难，许多人深有同感。然而
这些“有同感”的人又何曾想过，自己在做“新项目”的
时候，要为“项目维护”这种还不存在的角色，留下一个
沟道、对话的渠道呢？
我把项目的 History 作为跟这种“不存在的角色”沟
通的一种方式。History 的丰富和准确为项目的后继开发、
维护提供了可能。
历史记录（History） 与注释（ment）不是一回事。代
码中的注释是为阅读代码而留备的，而 History 是为整个
项目而记录的。一些参考的记录内容有：
） 需求阶段：与谁联系，联系方式、过程、结果以
及由此引发的需求或变更；
） 设计阶段：如何进行设计、最初的构架、各个阶
段的框架变化、因需求变更导致项目结构上的变
化（有助于了解构架的可扩充性） ；
） 开发阶段：每一种技术选型的过程、每一种开发
技巧的细节和相关文档、摘引的每一段代码、算
法、开发包、组件库的出处和评测；程序单元的
测试框架；每一个设计和构架变更所导致的影
响；
） 测试阶段：还记得测试用例和测试报告吗？那是
最好的 history 之一。
…55
…………………………………………………………Page 60……………………………………………………………
第 4 章 流于形式的沟通
当然，另一件最重要的事，是记得在每一笔记录后写
下时间和你的名字。你的每一笔记录都是打算留给一些根
本不了解这个项目的人看的，之所以要记下你的名字，是
便于那些人能够再找到你并溯源到问题的源头。——当
然，这得赶在你和古人一样“与天地共存”之前。
我们知道，大多数的工具都有历史记录的功能。在开
发工具和测试工具中尤为突出。此外，版本管理工具也留
①
下了每个阶段的印迹。然而，我不建议过于信任它们 ，
如果不明确要求项目组员写下详细的History ，那么他们可
能在每一次版本签入时都只写下两个字的备注：“完成”。
5。 流于形式的沟通
在很多的时候，我所听到的沟通，都是一种形式。例
如与客户吃饭或者打回访电话。
其实沟通是具有目的性的，如果在没有明确目的的情
况下与客户沟通，那将是浪费客户和自己的时间。这种目
的，可以是了解项目的讯息、挖掘潜在的项目……最末了，
才是交流感情。
然而大多数的情况下，它仅仅被看着交流感情。这便
① 大多数的软件公司已经意识到版本管理的重要性。然而项目各
个阶段的文档、代码及其它输入输出都是具有版本问题的。单一
的版本管理软件并不能胜任这些。因此我仍旧采用相对原始的、
编写History 这样的方法，来弥补ClearCase 、SourceSafe 、CVS等这
些软件的不足。
…56
…………………………………………………………Page 61……………………………………………………………
『大道至简』
成了形式。且往往是客户所讨厌的一种形式。
沟通问题不仅仅存在与客户交流之中。还存在于与项
目的各个角色之间。项目的分析报告为设计人员所看不
懂，设计人员的方案为开发人员所看不懂，而开发的结果
以为测试人员所看不通。等等都是沟通问题。
UML 的确是解决沟通问题的最佳手段之一。然而如
果项目一开始就不能用它，那么强求的结果必然是痛苦
的。——要让 UML 在一个没有经过相关培训的团队及其
各个角色之间用起来，几乎是不可能的事。即使用得起来，
也存在经验问题。千万不要指望仅仅一个项目，就能让你
的组员深刻的理解 UML 的思想。
也不要指望在每个项目中都能用它，如果你的客户能
理解并支持使用 UML ，那以这个项目就会有一个良好的
UML 使用环境。否则，开发环节中资料的不一致性，将
会使得项目难以收场。
使用与不使用 UML ，其根本的问题在于沟通方式的
选择。只要是行之有效的、能在各个项目角色间通用的，
就是好的沟通方式。
在每一次回顾项目时都应该注意：流于形式的沟通，
可能是使得你的项目被不断推翻和不断延迟的最直接原
因。
…57
…………………………………………………………Page 62……………………………………………………………
第 4 章 流于形式的沟通
…58
…………………………………………………………Page 63……………………………………………………………
第5章 失败的过程也是过程
“虚有其表耳。”
——《明皇实录》
1。 做过程不是做工程
软件工程这个概念被提出的时候大概是在上个世纪
60 年代末。它作为成熟的概念的标志是软件工程的瀑布
模型的提出。瀑布模型将软件开发的过程分成需求、分析、
设计、开发和测试等 5 个主要阶段，其主要环节关系表现
为如下的这样一种形态：
计划计划
定定 可行性研究可行性研究
义义
需求分析需求分析
系统设计系统设计
程序设计程序设计
实实
现现 编码与模块测试编码与模块测试
组合与系统测试组合与系统测试
维维 运行运行&&维护维护
护护
在瀑布模型之后，很多人开始研究过程模型的问题。
很多从实际工程中提炼出来的过程模型都是值得称道的，
…59
…………………………………………………………Page 64……………………………………………………………
第 5 章 失败的过程也是过程
例如 RAD（快速应用开发）模型、螺旋模型和现在常被提及
的 RUP 模型。
模型就是“样子”。人家拿出一个东西来说：这是模
型。其言下之意就是要你按照这个样子来做。然而正如下
在这张图所展示的：
按照模型的这个“样子”，做完过程的每一个阶段，
并不等于做工程。或者说，工程并不是这样就可以做成功
的。
换而言之，无论是用 RAD 模型还是 RUP 模型来做工
程，即使是亦步亦趋，也做不好工程。
如果工程可以那样做成的话，只需要有瀑布模型就足
够了。因此做过程并不是做工程的精义。
也不是目的。
…60
…………………………………………………………Page 65……………………………………………………………
『大道至简』
2。 做过场
为什么会存在这样的问题呢？
四川有句地方话叫“做过场”，也有说成“走过场”
的。“过场”是舞台术语，意思是角色从舞台一端出场，
再走到另一端进场的一个过程。过场角色一般没有唱腔或
道白，即便是有，也是没有什么实质内容的。
前面那张图就是一个过场。尽管那是一张用来描述
“沟通问题”的经典图例，然而你应该注意到，每一个角
色都把自己的环节当成一个“过场”。如同演戏一样，从
A 做到 Z ，就一切都完成了。当然，按照 RUP 的思想，
是要从 A 到 Z 一遍又一遍地做下去的。然而，如果每一
遍（或者用 RUP 的那个术语“迭代”）都只是“过场”的话，
项目将是一场无休止的演出而已。
最终呢？观众受不了了，就交钱走人；演员受不了了，
就下台散伙。戏目和项目的结局，竟如此地相似。
3。 实现，才是目的
很多人把问题的本质给忘掉了。从最开始，从我们编
程开始，我们的目的就是实现一个东西。无论这个东西是
小到一个称手的工具，还是一个大到千万的工程，我们的
…61
…………………………………………………………Page 66……………………………………………………………
第 5 章 失败的过程也是过程
目标，都是要“实现”它。
工程只是一种实现的途径。最