*续 第八章 注重实效的项目
1. 无处不在的自动化
文明通过增加我们不假思索就能完成的重要操作的数目而取得进步。
无论是构建和发布流程、是书面的代码复查工作、还是其他任何在项目中反复出现的任务，都必须是自动的。人工流程不能保证一致性，也无法保证可重复性，特别是在不同的人对流程的各个方面有不同解释时。使用shell脚本、批处理文件来处理流程，它们能以相同的次序反复执行同样的指令，还能被置于源码控制之下，定时调度工具也很有帮助。
2. 全都是写
a) 要把文档当做整个开发过程的完整组成部分加以接受。文档和代码可以紧密结合起来，作为同一模型的两个视图对待。
b) 内部文档包括源码注释、设计与测试文档等；外部文档是发布到外界的任何东西，比如用户手册。但不管受众是谁、撰写者是谁，文档都应该是代码的反映。
c) 代码中的注释
注释应该讨论为何要做某事、它的目标等。代码已经说明了它是怎样完成的，所以再为此加注释是多余的，而且也违反了DRY原则。
注释中也适合记录工程上的权衡、为何要做某些决策、放弃了哪些替代方案等等。
变量名应该精心选择，并且有意义。匈牙利命名法（包括了变量类型信息）在面向对象的系统中并不合适。
比无意义的名称更糟糕的是误导人的名称。
代码应该有代码作者、版权信息等内容，这些可以让编辑器自动生成。
d) 任何形式的文档都只是快照，可能刚刚发布出来就会过时，最好能采用自动化的方法及时更新。
文档和代码是同一底层模型的不同视图，视图是唯一应该不同的东西。不要让文档变成二等公民，被排除在项目主要工作流之外，对待文档要像对待代码一样用心。
3. 极大的期望
在现实中，项目的成功是由它在多大程度上满足了用户的期望来衡量的。不符合用户期望的项目注定是失败的，不管交付的产品在绝对意义上有多好。要温和地超出用户的期望。要做到这一点建议做如下工作：
a) 交流期望。
用户在一开始会有一些关于自己所需要的东西的想象，它们可能不完整、不一致或在技术上不可能做到，但那时他们的，他们也在其中投入了一些感情，不能简单地忽视。
交流的目的是达成对开发过程和最终产品、以及他们尚未描述出来的期望的共同理解。如果团队能与外界畅通地交流，这个过程几乎是自动的。曳光弹、原型可以促进这一过程。
b) 额外一英里。
在与用户紧密协作的过程中，用户会及时了解项目的进展，那么当项目交付时就不会有多少让人吃惊的事情了。这是一件糟糕的事情，要设法让你的用户惊讶（高兴），给他们的东西要比他们期望的多一点，比如友好的帮助系统、快捷键、自动化安装等等，通过这些让用户看到：开发团队想要开发出了不起的系统。但不要因为增加的新特性而破坏系统。
4. 傲慢与偏见
a) 在你的作品上签名。
b) 过去的手艺人为能在他们自己的作品上签名而自豪，你也应该如此，我们在负责一项设计，或是一段代码，我们是在做可以引以为傲的工作。
c) 但不要因为所有权而产生“地盘”意识：怀有偏见，只欣赏自己的代码，排斥自己的同事。我们不应该怀着猜忌心理阻止别人查看自己的代码，同样应该带着尊重对待别人的代码。
d) 匿名可能会为邋遢、错误、懒惰和糟糕的代码提供繁殖地。
e) 我们想要看到对所有权的自豪：“这是我编写的，我对自己的工作负责”，你的签名应该被视为质量的保证，当人们在一段代码上看到你的名字时，应该期望它是可靠的，用心编写的、测试过的和有文档的，一个真正的专业作品，由真正专业人员编写——一个注重实效的程序员。