第八章 注重实效的项目

随着你的项目开动，我们需要从个体的哲学和编码问题转向讨论更大的、项目级的问题。我们将不深入项目管理的具体细节，而是要讨论能使项目成功或失败的几个关键区域。

1. 注重实效的团队

书中前面的内容都是帮助个体成为更好的程序员，这些方法在对团队来说仍然有效。

a) 不要留破窗户。质量是一个团队的问题。最勤勉的开发者如果被派到不在乎质量的团队里，也会发现自己很难保持修正琐碎问题所需的热情。团队作为一个整体，不应该容忍破窗户——那些小小的、无人修正的不完美。

b) 煮青蛙。在项目开发高涨的热度里，很难再用一只眼睛注意周围的环境，所以作为整体的团队甚至更容易被煮熟。即使是目的最明确的团队对项目中的重大改动可能也会很健忘。团队每个人都应该主动监视环境的变化，也可以指定专人负责检查范围的扩大、时间标度的缩减、新增特性、新环境之类任何不在最初约定中的东西。

c) 交流。对外界而言，沉闷寡言、文档混乱的团队是糟糕的团队。而杰出的团队有着截然不同的个性，他们制作的文档准确、一致，团队用一个声音说话，甚至还可能有幽默感。可以使用一个营销的诀窍，来帮助团队作为整体与外界交流：创立品牌。在启动项目时，给它取一个不寻常的名字，这会给团队一个用于建设的身份标识。

d) DRY。交流有助于消除团队间的重复，此外可以安排项目成员分工担任项目不同部分的资料管理员（比如数据库schema、日期处理等）。

e) 正交性。要围绕功能、而不是工作职务组织小团队，这些小团队分别负责最终系统的特定方面的功能，每个团队都按照他们约定的承诺，对项目中的其他团队负有责任。这种分组方式能够极大地减少各个开发者的工作之间的相互影响。但是这种方法只有在项目拥有负责的开发者、以及强有力的项目管理时才会有效。

f) 自动化。自动化可以确保团队所做的每件事情一致、准确。编辑器为代码自动布局、夜间自动构建测试，这些都是很好地方式。自动化是每个项目团队的必要组成部分。

g) 知道何时停止绘画。团队由个体组成，要给他们足够的能够闪亮的空间，以支持他们，同时要把握足够好的软件，抵抗不断画下去的诱惑，确保项目的交付能够符合需求。

2. 无情的测试

a) 早测试、常测试，自动测试。寻找bug有点像是用网捕鱼。我们用纤小的网（单元测试）捕捉小鱼，用粗大的网（集成测试）来捕捉大鱼。有时鱼会设法逃跑，所以为了抓住在我们项目池塘里游动的、越来越狡猾的缺陷，要补上我们发现的任何漏洞。

与手动执行的测试计划相比，随每次构建运行的测试要有效的多。

Bug发现得越早，进行修补的成本就越低。要“编一点，测一点”，在编写产品代码的同时编写测试代码。

只有通过全部测试，编码才算完成。好的项目拥有的测试代码可能比产品代码还要多。但编写这些测试代码所花的时间是值得的。长远来看，它最后会便宜得多，而你有希望制作出接近零缺陷的产品。此外，通过了所有测试将给你高度的自信：一段代码已经“完成”了。

项目范围测试的三个方面：测试什么、怎样测试、何时测试

b) 测试什么

单元测试，这是所有其它形式测试的基础。所有模块都必须通过单元测试，才能继续前进。

集成测试，用来验证项目的主要子系统能否工作，并很好地协同。是单元测试的一种扩展，测试整个子系统是否遵守其合约。

验证和校验。就算没有bug，但回答的问题本身是错误的，这样的系统也不会有用。需要校验回答一个重要的问题是：这是用户需要的吗？要注意用户的访问模式与开发者所用测试数据的不同。

资源耗尽、错误及恢复。虽然在理想的条件下软件会正常运行，但在现实运行环境下，还有内存、磁盘空间、CPU带宽、网络带宽、屏幕分辨率等种种限制。

性能测试、压力测试或负载测试有时也很有必要，要测试软件能够满足现实条件下的性能需求，如预期的用户数、连接数、每秒事务数、可伸缩性。有时需要用专门模拟现实环境进行测试。

可用性测试。可用性测试是由真正的用户、在真实的环境条件下进行的。软件最好能像是手的延伸一样顺手。可用性测试也要尽早进行，以保证有时间更正，否则没能满足可用性标准就像是除零错误，是重大bug。

c) 怎样测试

回归测试，把当前测试的输出与先前或已知的值进行对比，以确定今天对bug的修复没有破坏昨天可以工作的代码。性能、合约、有效性能等都可以进行回归测试。

测试数据。数据分为两种，现实世界的数据和合成的数据。

现实世界的数据代表典型的用户数据，有助于揭示出需求分析中的缺陷和误解。

合成数据在需要大量数据、需要测试边界条件、展示特定统计属性时很有用。

演练GUI系统。对于涉及到GUI的部分，你的设计应该足够地解耦，以使你无需使用GUI就能对应用逻辑进行测试。从这一点来看，Winform那种界面与代码的组合方式是不好的。

彻底测试。衡量测试的覆盖率不能单单只从代码行的覆盖情况，尤其是对于循环、迭代之类的代码。重要的是程序可能具有的状态数。而且即使具有良好的代码覆盖，测试数据、遍历代码的次序对结果也有重大影响。

d) 何时进行测试。任何产品代码一旦存在，就需要进行测试。大多数测试应该自动完成，并尽可能地频繁测试，

e) 一个bug只抓一次。bug一旦被发现，就应该是最后一次被发现，应该对自动化测试进行修改，从此每次都检查那个特定的bug，不存在例外，不要觉得它不会再次发生。