第八章：注重实效的项目

---

一、注重实效的团队

让我们针对团队，重述前面的部分章节：

不要破窗户

质量是一个团队问题。

煮青蛙

作为整体的团队甚至更容易被煮熟。

交流

团队作为实体需要同外界进行明晰的交流。

不要重复你自己

交流、不同的人指派不同的工作、即时聊天软件

正交性

围绕功能，而不是工作职务进行组织。

自动化

确保一致和准确的一种很好的方式是使团队所做的每件事情自动化。

知道何时停止绘画

团队是由个体组成的，让每个成员都能以他们自己的方式闪光。给他们足够的空间，以支持他们，并确保项目的交付能够符合需求。

二、无处不在的自动化

一切都要自动化

 不要使用手工流程

人的可重复性并不像计算机那么好。

常用的自动化脚本：shell脚本或批处理文件、cron

项目编译

项目编译时一件应该可靠、可重复进行的琐碎工作。我们通常使用makefile编译项目。

• 生成代码
• 回归测试

构建自动化

• 从仓库中签出源码
• 从头开始构建项目（从makefile开始）
• 创建可分发映像
• 运行规定的测试（make test）

最终构建

自动化管理

我们可以运行脚本，让它们基于源码和文档的内容，自动为我们完成各种流程。我们的目标是维持自动、无人照管、内容驱动的工作流。

• 网站生成：Web内容应该根据仓库中的信息自动生成，并且无需人的干预就发布出去。
• 批准流程：有些项目具有各种必须遵循的管理工作流，比如代码复查、需要审批等，我们可以使用自动化减轻书面工作负担。

鞋匠的孩子

鞋匠的孩子没鞋穿。

软件开发人员常常使用最糟糕的工具来完成工作。

但我们有制作更好的工具所需的原材料，我们有cron，有make等等，让计算机去做重复、庸常的事情——它会做的比我们更好。

三、无情的测试

早测试，常测试，自动测试

一旦我们有了代码，就要开始进行测试，我们使用单元测试来“抓小鱼”，用集成测试来“抓鲨鱼”。

bug被发现的越早，进行修补的成本就越低。“编一点，测一点”是SmallTalk世界里流行的一句话。

事实上，好的项目拥有的测试代码可能比产品代码还要多。编写这些测试所花的时间是值得的。

此外，知道你通过了测试将给你高度的自信：一段代码已经完成了。

要通过全部测试，编码才算完成

你写出了代码并不意味着已经完成，在通过所有测试之前，你不能声称它已经可供使用。

 测试什么

• 单元测试
• 集成测试
• 验证和校验
• 资源耗尽、错误及恢复
• 性能测试（压力测试、负载测试）
• 可用性测试（真实用户在真实环境下进行的）

怎样测试

• 回归测试——把当前测试的输出与先前的作对比
• 测试数据——一种是真实数据，一种是合成数据
• 演练GUI系统——往往需要专门的测试工具
• 对测试进行测试——故意引入bug，以证实测试能够抓取
• 彻底测试

何时测试

许多项目往往会把测试留到最后一分钟——最后期限马上就要来临时。我们需要比这更早就要开始测试吧，任何产品代码一旦存在，就需要进行测试。

有些测试可能需要频繁进行测试，通常是单元测试和集成测试，每一次在代码签入源码仓库之前都要测试一下。

有些测试可能不容易频繁进行测试，比如压力测试，这些测试就不那么频繁，比如每周或每月一次。

把网收紧

如果有bug漏过了现有测试网，需要增加新的测试，以在下一次抓住它：

一个bug只抓一次

四、全都是写

注重实效的程序员会把文档当做整个开发过程中的完整组成部分加以接受。不进行重复劳动，不浪费时间，并且把文档放在手边——如果可能，就放在代码当中，文档的撰写就可以变得更容易。

把英语当作又一种编程语言

为项目制作的文档基本上有两种：内部文档和外部文档。

内部文档包含源码注释、设计和测试文档等。外部文档是发布到外界的东西，比如用户手册。但不管目标受众是谁，也不管文档作者是谁，所有的文档都是代码的反映。

把文档建在里面，不要拴在外面

代码中的注释

一般而言，注释应该讨论为何要做某事、它的目的和目标。代码注释让你去把项目的那些难以描述、容易忘记，却又不能记载在别的任何地方的东西记载下来。

代码中应该有注释，但太多的注释和太少一样糟。

可执行文档

使用像JavaDoc和DOC++这样的工具我们可以根据源码生成API级的文档。

技术文档撰写者

应该和注重实效的程序员一样，接受同样的基本原则——特别是遵守DRY原则、正交性、模型——试图概念、以及自动化和脚本的使用。

标记语言

对于大型项目我们建议考察一些更为现代的文档标记方案。

现在许多技术作者使用DocBook来定义文档。DocBook是一种基于SGML的标记语言，它仔细标识文档中的每一个组成部分。通过DSSSL处理器，文档可绘制成多种不同格式。

文档和代码时同一底层模型的不同视图，不要让文档成为二等公民，被排除在项目主要工作流之外。对待文档要像对待代码一样用心。

五、极大的期望

在抽象的意义上，应用如果能正确实现其规范，就是成功的。遗憾的是这只是付抽象的帐。

在现实中，项目的成功是由它在多大程度上满足了用户的期望来衡量的。不符合用户期望的项目注定是失败的，不管交付的产品在绝对意义上有多好。

温和地超出用户的期望

交流期望

用户一开始就会带着他们对所需要的东西的想象来到你面前。那可能并不完整、不一致、或是在技术上不可能做到，但那是他们的，不能简单忽视它，随着你对他们的需要的理解的发展，你会发现他们的有些期望无法满足，或者过于保守，你的部分角色就是要就此进行交流。与你的用户一起工作，以使他们正确理解你将要交付的产品。并且要在整个开发过程中进行这样的交流。

有些重要的技术可以用于促进这一过程，其中“曳光弹”和“原型与便笺”是最为重要的技术。两者都让团队构造用户看得见的东西。

额外的一英里

仅仅完成用户期望还不够，要设法让你的用户惊讶，即给他们的东西要比他们期望的多一点。给系统增加某种面向用户的特性所需的一点额外努力将一次又一次带来商誉上的回报。

只是要记住，不要因为增加这些新特性而破坏系统。

六、傲慢与偏见

注重实效的程序眼不会逃避责任，相反我们乐于接受挑战，乐于使我们的专业知识广为人知。

在你的作品上签名

过去时代的手艺人为能在他们的作品上签名而自豪，你也应该如此。

匿名可能会为邋遢、错误、懒惰和糟糕的代码提供繁殖地。

你的签名应该被视为质量的保证，当人们在一段代码上看到你的名字时，应该期望它是可靠的、用心编写的、测试过的和有文档的，一个真正的专业作品，由真正的专业人员编写。

一个注重实效的程序员。