程序员修炼之道（通俗版）——第八章

《程序员修炼之道》这本书中的内容挺不错，里面包含了很多精华，但一些句子很拗口，所以我就根据国人的阅读习惯，在不改变原意的情况下对词句稍加修改，标题中的“通俗版”就是这么来的。

1、我们喜欢按照功能划分的团队。把你的人划分成小团队，分别负责系统特定方面的功能。让各团队按照各人的能力，在内部自行组织。每个团队都按照他们约定的承诺，对项目中的其他团队负有责任。承诺的确切内容随项目而变化，团队间的人员分配也是如此。
这样按功能组织有什么好处？使用我们用于组织代码的相同技术，去用像合约、解耦、正交性这样的技术组织我们的各种资源，有助于使团队作为整体与变化的各种效应隔离开来。如果用户突然决定变更数据库供应商，应该只有数据库团队受影响。如果市场部突然决定使用现成工具来实现日程安排功能，只有日程小组会受影响。适当地加以运用，这种分组方式能够极大地减少各个开发者之间的相互影响。缩短时间标度、提高质量、并减少缺陷的数目。这种途径还能带来更愿意付出的开发者，每个团队都知道他们要对特定的功能负责，所以他们更会觉得自己是他们的工作成果的主人。

2、人的重复性并不像计算机那么好。shell脚本或批处理文件能以相同的次序、反复执行同样的命令。它们能被置于源码控制之下，你因而也可以检查流程的修改历史（“昨天还能工作……”）
Linux中一个特别受欢迎的自动化工具是cron（或Windows NT上的“at”）。它允许我们安排无人照管的任务周期性地运行——通常是在午夜。例如下面的crrontab文件指定，每天午夜过后5分钟运行项目的nightly命令，每个工作日的凌晨3:15进行备份，每月第一天的午夜运行expense_reports

3、在“重复的危害”中，我们提倡生成代码，以根据公共来源派生知识。我们可以利用make的依赖分析机制，让这一过程变得更容易。给makefile增加规则，根据其他来源自动生成文件，是一件相当简单的事情。例如，我们想要根据一个XML文件生成一个Java文件，并编译所得结果。
.SUFFIXES: .Java .class .xml
.xml .java:
perl convert .pl $< >$@
.Java .class
$(JAVAC) $(JAVAC_FLAGS) $<

敲入make test.class，make就会自动查找名为test.xml的文件，通过运行Perl脚本构建一个.java文件，然后编译该文件，产生test.class。
这看起来不错，有机会得试一下。

4、如果程序员能够把他们的所有时间投入实际编程，那不是很好吗？遗憾的是，难得有这样的情况。有E-mail要回复，有书面工作要完成，有文档要发布到Web上，等等。你可以创建一个shell脚本来完成一些烦人的工作，但你仍然要记得在需要时运行这个脚本。
因为记忆是随着你的年龄增长而丧失的第二种东西，我们不想过分依赖它。我们可以运行脚本，让他们基于源码和文档的内容，自动为我们完成各种流程。我们的目标是维持自动、无人照管、内容驱动的工作流。

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

6、寻找bug有点像是用网捕鱼。我们用纤小的网（单元测试）捕捉小鱼，用粗大的网（集成测试）捕捉吃人的鲨鱼。有时鱼会设法逃跑，所以为了抓住在我们的项目里游动地、越来越狡猾的缺陷，要补上我们发现的任何漏洞。
许多团队都会为他们的项目精心制定测试计划，但实际上，使用自动测试的团队更容易成功。

7、编码完成的标志不是你已经写完了这段代码，而是你写完的这段代码已经通过了全部测试。

8、回归测试把当前测试的输出与先前的（或已知的）值进行对比。我们可以确定我们今天对bug的修正没有破坏昨天可以工作的代码。这是一个重要的安全网，它能减少令人不快的意外。
我们到目前为止提到过的所有测试都可以作为回归测试运行，确保我们在开发新代码时没有损失任何领地。我们可以运行回归测试，对性能、合约、有效性等进行校验。

9、一旦测试人员找到了某个bug，这应该是测试人员最后一次发现这个bug。应该对自动化测试进行修改，从此每次都检查那个特定的bug，没有例外，不管多琐碎，也不管开发者怎样抱怨说：“哦，那绝不会再发生了。”
因为它会再次发生，而我们完全没必要花时间去追踪自动化测试本可以为我们找到的bug。我们必须把时间花在编写代码——以及新的bug——上。

10、一般而言，注释应该讨论为何要做某事、它的目的和目标。代码已经说明了它是怎样完成的，所以再为此加上注释是多余的——而且违反了DRY原则。
注释可以让你把项目的那些难以描述、容易忘记，却又不能记载到其他地方的东西记载下来：工程上的权衡、为何要做出某些决策、放弃了哪些替代方案，等等。

11、在源文件里应该出现的最重要的信息之一是作者的姓名——不一定是最后编辑文件的人，可以是文件的所有者。使责任和义务与源码联系起来，能够奇迹般地使人保持诚实。

12、以一种类似的方式使用像JavaDoc和DOC++这样的工具，我们可以根据源码生成API级的文档。模型是源码：模型的一种视图可以编译；其他视图可用于打印或在Web上查看。我们的目标是总在模型上工作——不管模型是代码自身还是某种其他文档，并且让所有视图自动更新。突然间，文档没那么糟糕了。
这听起来很不错，值得我们玩一下。

13、在抽象意义上，应用如果能正确实现其规范，就是成功的。遗憾的是，这种事只活在梦里。
在现实中，项目的成功是由它在多大程度上满足了用户的期望来衡量的。不符合用户预期的项目注定是失败的，不管你认为交付的产品有多好。