《软件工程实践者的思想(PDF格式)》第13章

记》。
我　们　做　项　目　的　时　候　，　如　果　也　不　留　下　历　史　记　录　
（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（快速应用开发）模型、螺旋模型和现在?