刻舟求剑的文档.PDF

第1 章 Chapter 1 刻舟求剑的文档 “什么是软件？”20 世纪90 年代初的一个冬日，在北京东南部的一所大学里，一位年近 花甲的老师，给我们这些计算机系的学生讲软件工程这门课时，问了这个问题。对于当时几 乎没有机会接触计算机的我来说，软件就是学校计算机房里那些DEC 小型机上令人费解的 命令，和286 个人计算机里那些好玩的“吃豆子”和“赛车”游戏。“软件不仅仅是程序， 还包括描述程序的文档。软件就是程序加文档。”老师对软件的定义，深深地刻在我的脑子 里，其程度之深，以至于在之后的很长一段时间里，总令我觉得文档对于软件的影响力，似 乎要超过程序。 这一点在我大学毕业后20 年的软件开发相关工作的实践中，不断地得到印证。各种各 样的文档——需求文档、概要设计文档、详细设计文档、测试文档等，在我先后经历的多个 软件开发项目中，始终占据着重要的地位。“毕竟，只要文档在，就不怕开发人员的频繁更 换。”一位软件开发经理这样对我说。除了要写Word 或Excel 的文档，程序员们还被要求在 源代码中写尽量详尽的注释。在软件开发经理眼中，撰写文档和编写注释的能力，是衡量程 序员是否称职的一项重要标准。 “为保证客观性，软件开发完成后，应该由不同的人员来对其进行测试。”老师的这句话 也时时萦绕在我的耳边。这句话的影响力是如此巨大，以至于前些年我做程序员时，我和周 围的程序员们都一致认为测试就是测试工程师的事情。在10 多年中，我经历的每一个项目， 都无一例外地有一个独立于开发团队的测试团队，开发团队将代码开发完成后，简单地在自 己机器上运行一下，然后就将代码提交给测试团队去测试了。 十几年来，不管是开发新功能还是修复bug ，我一直在努力地撰写文档，编写和修改代 2 码及注释，然后交给测试人员去测试，再去修改测试人员提出的bug ，这一切看起来都像教 科书上描述的那样地完美和正确。但是最后我却难过地发现，用这种方法开发出来的软件， 无一例外逐渐沦为烂代码。在烂代码的沼泽里，即使有文档，也读不懂代码；即使bug 很小， 也不敢修改代码。我甚至怀疑，这种方法或许会助长烂代码的滋生。这些文档就好像“刻舟 求剑”故事中那个刻在船身上的记号。让我们先用这种传统的测试后行 （test last ）的开发方 2 法，做一个编程操练 吧，来看看其中会有什么问题。1 对于本书中所有的编程操练，我都将邀请您——我的亲爱的读者——来与我一起结对编程。 3 “啊？和我结对编程？我还从来没试过哩！”读者可能会说。 结对编程其实一点都不神秘，如果把编程比作打网络游戏，结对编程就好比两个人结伴去 打魔兽，除了可以相互学习切磋之外，还能相互有个照应。一起来看看本书的第一个编程操练。 这个操练是我于2013 年9 月为在“北京设计模式学习组”的第9 次活动中操练Observer 设计模式而编写的。灵感来自于我在酒店下榻时，在大堂里看到的墙壁上悬挂的那些显示世 界上各个主要城市的时间的时钟。我在想，如果所有这些时钟都走时不准，酒店大堂服务员 一个个地分别调时间太麻烦，而这位服务员的智能手机上肯定用的是该酒店所在地的当地时 间，要是能够在调准服务员手机时间的同时，将酒店大堂墙壁上所有城市的时钟根据时差相 应地自动调准，那该多方便。 假如在北京一家酒店的大堂里有5 个时钟，分别显示北京、伦敦、莫斯科、悉尼和纽 约的时间。其中，伦敦与UTC （Coordinated Universal Time ，协调世界时）时间 一致，北京 比UTC 时间早8 小时，莫斯科比UTC 时间早4 小时，悉尼比UTC 时间早10 小时，纽约比 UTC 时间晚5 小时 。若所有这些城市的时钟都多少有些走时不准，需要调整时间时，大堂 服务员只需调准自己手机上的北京时间，那么墙壁上那5 个城市的时间就能相应地自动调整 4 准确。酒店世界时钟和服务员的手机时钟如