程序员修炼之道---从小工到专家（第8章）

注重实效的项目

41，注重实效的团队

好团队让你加速成长。

不要留破窗户：

团队必须要为产品的质量负责。

煮青蛙：

确保每个人都主动地监视环境的变化。

交流：

团队中的开发者必须相互交谈。

对外界而言，看上去沉闷寡言的项目团队事最糟糕的团队。

创立项目的品牌可以帮助团队作为整体与外界交流。

不要重复你自己：

指定某个成员担任专项管理员。

正交性：

不要把项目的各项活动－－分析、设计、编码、测试－－孤立开来。

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

按照功能划分团队。不要两个不同的子团队做同一个程序模块或类。

按照功能组织，用像合约、解藕、正交性这样的技术组织我们的各种资源，有助于使团队作为整体与变化的各种效应隔离开来。

创立一组自行其是的团队并放任自流，是一种灾难性的处方。项目至少需要两个头－－一个主管技术，另一个主管行政。

自动化：

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

知道何时停止绘画：

让每个成员都能以他们自己的方式闪亮。足够好的软件。

42，无处不在的自动化

我们想要确保项目的一致性和可重复性。

一切都要自动化：

不要使用手工流程。

让代码帮你，shell，cron命令（周期性的运行），晚上可以跑测试，备份，构建，维护等。

项目编译：

它应该是可靠的，可重复的。makefile。

我们想要一条命令就完成签出、构建、测试和发布。

生成代码：

在make的时候加入生成代码的过程。以根据公公来源派生知识。生成头文件、源文件或者是文档。

回归测试：

让makefile为你运行回归测试，或针对单个模块。

递归make

构建自动化：

签出代码、构建（版本号，日期）、创建可分发镜像、运行规定的测试。

定期运行测试，有助于保证修改的正确性。

最终构建：

make final，要一次完成所有参数设置。要进行所有的测试。

自动化管理：

运行脚本，让它们机遇源码和文档的内容来帮助你完成各种流程。email，书面工作，发布文档到web上。

目标是维持自动、无人照管、内容驱动的工作流。

网站生成：

用源码、文档、构建结果、回归测试、性能统计、编码度量等做成网页信息，发布到网站。DRY，信息已经存在，将视图放到浏览器。

批准流程：

也可以在网页上完成，将信息写入源码，然后在网页上check后，修改文本中的状态。代码检查。

鞋匠的孩子：

软件开发人员常常会使用最糟糕的工具来完成工作，鞋匠的孩子没鞋穿。

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

43，无情的测试

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

编一点，测一点。

编写测试代码的时间是值得的。

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

测试什么：

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

单元测试：

针对某个模块进行演练的代码。

集成测试：

集成测试说明组成项目的主要子系统能工作，并且能够很好地协同。

先单元测试，再集成。否则就是制造bug。

验证和校验：

它满足系统的功能需求吗？这是用户想要的吗？

用户的访问模式。

资源耗尽、错误及恢复：

内存空间、磁盘空间、CPU带宽、挂钟时间、磁盘带宽、网络带宽、调色板、视频分辨率。

根据环境的限制，进行相应的调整。检查内存分配失败，检查硬盘空间。

失败的时候如何失败，设法保存状态，防止工作丢失。

性能测试：

性能测试、压力测试和负载测试。

可用性测试：

由真正的用户、在真实的环境条件下进行的。

软件对于用户而言、就像是手的延伸吗？

没能满足可用性标准就像是除零错误，是个大bug。

怎样测试：

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

回归测试：

把当前测试的输出与已知的值进行对比。可以确定今天对bug的修正没有破坏昨天可以工作的代码。

测试数据：

现实世界的数据和合成的数据。

以下情形需要使用合成数据

     需要大量的数据。需要强调边界条件的数据。需要能展现出特定的统计属性的数据。

演练GUI系统：

提高解藕性，达到无需使用GUI就可以测试的代码。采用脚本测试，耦合度太高了。

对测试进行测试：

通过蓄意破坏测试你的代码。这样可以确保测试时有效的。有时候会方便你理解代码。

彻底测试：

覆盖分析，可以查看你的代码执行与否。统计工具有用的。

测试状态覆盖，而不是代码覆盖。

何时进行测试：

大多数测试应自动完成。有计划的测试，周期性的。

把网收紧：

一个bug只抓一次。

发现bug以后，及时增加测试，及时查看有无同类事情发生，所谓展开。

44，全都是写

把文档和代码结合起来。

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

内部文档：注释，设计与测试文档。

外部文档，用户手册。

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

代码中的注释：

注释应该讨论为何做某事、它的目的和目标。

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

变量命名

参数是否也需要一起注释。

不要把一些冗余的信息放到注释里，如修订历史，文件名。

注释中有些内容可以让编辑器自动为你插入。

可执行文档：

保留一份知识，其他都是可以生成的视图。

技术文档撰写者：

也要遵守同样的原则。

打印还是编排：

把资料放在web上，随时修改，放上日期戳。可以用markup系统。

标记语言：

使用标记语言来写文档，及时更新。可以多处安放。

45，极大的期望

项目的成功是由它在多大程度上满足了用户的期望来衡量的。

温和地超出用户的期望。

交流期望：

与你的用户一同工作，以使他们正确地理解你将要交付的产品。

曳光弹和原型与便笺可以让团队构造用户能看见的东西。两者都是与用户交流你对他们绣球的理解的理想途径。并且两者都让你和用户习惯于相互交流。

额外的一英里：

要设法让你的用户惊讶。不是惊吓，是让他们高兴。

给他们的东西要比他们期望的多一点。

比如：气球式帮助或工具提示帮助，快捷键，作为用户手册的补充材料的快速参考指南，彩色化，日志文件分析器，自动化安装，用于检查系统完整性的工具，运行系统的多个版本、以进行培训的能力，为他们的机构定制的splash屏幕（启动时的初始画面）

不要因为增加新特性而破坏系统。

46，傲慢与偏见

不要逃避责任。

在你的作品上签名。

不要怀着猜忌心阻止要查看你的代码的人。出于同样的原因，你应该带着尊重对待他人的代码。

不要匿名。

这是我编写的，我对自己的工作负责。

一个注重实效的程序员。