第8章：注重实效的项目

41、注重实效的团队

成为注重实效的个体有好处，但如果个体是在注重实效的团队中工作，这些好处就会成倍增长。把注重实效的技术应用于作为整体的团队，一旦你有了一组注重实效的开发者，让他们工作在能够发挥自身能力的环境中，他们很快就会发展并提炼他们自己的、有效的团队动力机制。

不要留破窗户

质量是一个团队问题，最勤勉的开发者在不在乎质量的团队里，会发现自己很难保持修正琐碎问题所需要的热情。如果团队主动鼓励不要花费时间在这样的修正上，问题就会进一步恶化。

团队作为一个整体，不应该容忍破窗户，团队必须为产品的质量负责，支持那些了解“不要留破窗户”哲学的开发者，并鼓励那些还不了解这种哲学的人。

质量只可能源于全体团队成员都作出自己的贡献，无法把保证产品质量的责任委派给“质量官员”。

煮青蛙

作为整体的团队甚至比“青蛙”更容易煮熟，大家认为，另外有人在处理某个问题，或是团队领导一定批准了用户要求作出的某项改动。即使是目的最明确的团队对项目中的重大改动可能也会很健忘。

确保每个人都主动地监视环境的变化，指定一个人，持续的检查范围的扩大，时间标度的缩减、新增特性、新环境–任何不在最初的约定中的东西。对新需求进行持续的度量。

交流

看上去沉默寡言的项目团队是最糟糕的团队。他们举行无章次的会议，会上没有人想说话，他们的文档混乱，没有两位相同外观的文档，每一份都使用不同的术语。

杰出的项目团队有着截然不同的个性，人们希望他们一同开会，因为他们知道自己将看到准备良好，会让每个人都感到愉快的演出。他们制作的文档新鲜、准确、一致。团队用一个声音说话，甚至还可能有幽默感。

不要重复你自己

重复会造成工作的浪费，并且可能会带来维护的噩梦。指定某个成员单人项目资料管理员，负责协调文档和代码仓库，其他成员在查找资料时，首先找这个人。当项目对一个资料管理员太大时，可以指定多人负责工作的各个方面。

正交性

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

这里的功能并不必然意味着最终用户的用例，数据库访问层是功能，帮助子系统也是功能。

按功能组织有助于使团队作为整体与变化的各种效应隔离开来。能够极大的减少各个开发者的工作之间的相互影响、缩短时间标度、提高质量、并减少缺陷数目。

自动化

确保一直和准确的一种很好的方式是使团队所做的每件事情自动化。指定一个或多个团队成员担任工具构建员，构造和部署使项目中的苦差事自动化的工具。

知道合适停止绘画

团队是由个体组成的，让每个成员都能以他们自己的方式闪亮，给他们足够的空间，以支持他们并确保项目的交互能够符合需求。然后，要抵制“足够好的软件”中的画家不断画下去的诱惑。

42、无处不在的自动化

无论是构建和发布流程，是书面的代码复查工作、还是其他任何在项目中反复出现的任务，都必须是自动的。人工流程不能保证一致性，也无法俺保证可重复性，特别是在不同的人对流程的哥哥方面有不同的解释时。

一切都要自动化

不要使用手工流程

人的可重复性并不像计算机那么好。我们也不应期望他们能那样。shell脚本或批处理能以相同的次序、反复执行同样的命令，他们能被置于源码控制之下，你因而也可以检查流程的修改历史。

使用cron ，我们可以自动安排备份，夜间构建、网站维护，以及其他任何可以无人照管的完成的事情。

项目编译

项目编译是一件应该可靠、可重复地进行的琐碎工作，我们通常通过makefile编译项目，可以增加挂钩，让其为我们生成代码，并自动运行回归测试。

构建自动化

典型情况下，项目构建包含以下几个步骤：

从仓库中迁出源码
从头开始构建项目
创建可分发映像
运行规定的测试

对于大多数项目，这一层面的构建是在每天夜间自动运行的。在典型情况下，与在构建的项目的某个具体部分时运行的测试相比，这样的夜间构建中运行的测试要更完整。

你想要作为产品发现的最终构建，可能具有与常规的夜间构建不同的需求，最终构建可能要求锁住仓库，或是标上发布号，要求设置不同的优化和调试模式。

自动化管理

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

让计算机去做重复、庸常的事情，它会做的比我们更好，我们有更重要、更困难的事情要做。

43、无情的测试

寻找bug有点像用网（单元测试）捕捉小鱼，用粗大的网（集成测试）捕捉吃人的鲨鱼。

早测试、常测试、自动测试

一旦我们有了代码，我们就想开始进行测试。使用自动测试的团队成功的机会要大得多。

bug被发现的越早，进行修补的成本越低。好的项目拥有的测试代码可能比产品代码还要多。

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

你写出了一段代码，并不意味着你可以告诉你的老板或客户，说它已经完成，代码从不会真正完成，在它通过所有可用的测试之前，你不能声称它已经可供使用。

测试什么？

单元测试
集成测试
验证和效验
资源耗尽、错误及恢复
性能测试
可用性测试

怎样测试

回归测试
测试数据
演练GUI系统
对测试进行测试
彻底测试

何时进行测试

大多数测试都应该自动完成，尽可能频繁的进行测试，并且总是在我们把代码嵌入源码仓库之前，有些源码控制系统可用自动完成这一工作。

有些测试不容易那么频繁的运行，可以每周或者每月一次。

把网收紧

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

44、全都是写

应把文档作为整个开发过程的完整组成部分加以接受。不进行重复劳动，不浪费时间，并且把文档放在手边，就放在代码当中。

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

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

代码中的注释

根据源码中的注释和声明产生格式化文档相当直接了当，但首先外面必须确保在代码中确实有注释。代码中应该有注释，但太多的注释可能和太少一样糟。

一般而言，注释应该讨论为何要做某事，他的目的和目标。代码已经说明了它是怎样完成的，再为此加上注释就是多余的，且违反DRY原则。

我们喜欢看到简单的模块级头注释、关于重要数据与类型声明的注释、以及给每个类和每个方法所加的简要头注释，用以描述函数的用法和任何不明了的事情。

不应该出现在源码中的注释内容：

文件中的代码导出的函数的列表
修订历史
该文件使用的其他文件的列表
文件名

可执行文档

如果你的文档是带有标记命令的纯文本，可以使用工具自动提取schema，并重新对其进行格式化。

使用像JavaDoc的工具，可以根据源码生成API级的文档。

打印还是编排

设法把文档制作成能够在web上在线发布的形式，用超链接整合在一起，使文档保持最小。

45、极大的期望

现实中，项目的成功是由它在多大程度上满足了用户的期望来衡量的，不符合用户期望的项目注定是失败的。

温和的超出用户的期望

交流期望

和用户一同工作，达成对开发过程和最终产品，以及他们尚未描述出来的期望的共同理解。

额外的一英里

给用户的东西要比他们期望的多一点，让用户高兴。

46、傲慢与偏见

在你的作品上签名

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

本文链接：http://tabalt.net/blog/tpp-pragmatic-projects/，转载请注明。