#15.4 make：自动化编译

#15.4.3 通用生成目标

关于通用生成目标应该表示什么，以及它们该如何命名已经有了一组良好的约定。遵从这些会让自己的 makefile 更容易理解和使用：

  • all： 生成工程中所有可以执行者。通常全部产品并没有明确的定义;往往指工程中高阶的目标文件(并且，并非偶然地，常常有文档说明会包括哪些)。它通常应该是 makcfile 的第一个生成目标，因此它往往是开发者不带参数键入 make 就执行的那一个

  • test： 运行程序的自动测试套件，典型地，包括一组单元测试(Unit Test)来查找递归 bug，或是其它在开发过程中偏离预期行为的误差。“test”目标也可以由软件的最终用户来确保安装程序能够正常工作。

  • clean：删除 make a11 时产生的所有文件(例如二进制可执行文件和目标文件)。make clean 应该将软件的编译过程重置到良好的初始状态。

#15.5 版本控制系统

#15.5.1 为什么需要版本控制

如果改变了代码却发现并不可行，如何恢复到一个已知的良好版本?如果回归是困难的或不可靠的，改变代码就太过冒险(有可能会崩掉整个项目，或者为自己凭空增加许多小时的痛苦工作)

几乎同样重要的是变化追踪。知道代码已经发生了改变，但知道为什么吗？稍后再看它们却很容易就忘记了改变的原因。如果项目存在合作者，又如何知道在自己不注意时合作者改变了什么，另外，每个修改该由谁负责?

常常令人惊奇地发现，即使没有合作者，问问自己从上一个已知的良好版本后改变了什么也非常有用。这也常常会揭露不必要的改变，例如被遗忘的调试码，我现在在检入 (check in)变化前，一般就会做这项工作。
—— Henry Spencer

#15.6 运行期调试

只要拥有超过一星期编程经验的人都会知道，让程序符合正确的语法是调试中相对容易的部分。困难的是在这之后，需要了解为什么语法正确的程序并不如期望的那样运行。

#15.7 性能分析

作为通用法则程序 90%的执行时间都耗费在 10%的代码上。性能分析软件（Profilers）可以帮助确定那 10%抑制程序速度的区域。这可以让程序跑得更快。

但在 Unix 传统中，profiler 有个更为重要的功能。它能够让人不去优化其余 90%的代码。这很棒，并不仅仅由于这样节省了工作。其实不去优化余下 90% 代码真正有价值的效应是降低了整体复杂度，减少了 bug。

做好设计，首先考虑什么是正确的，然后再调整效率。

#15.8 使用 Emacs 整合工具

#15.8.4 Emacs 和 Profiling

别蛮干—这会浪费时间和生产力。如果发现在低层次的机械开发部分花费了太多时间的话，先站住。应该运用 Unix 折学。使用工具自动化或半自动化地完成任务。

然后，作为对所有继承的回报，将自己的解决方案作为开源软件放置在互联网上帮助把程序员同行们从蛮千中解放出来。