程序员修炼之道（读书笔记）：3.基本工具

许多程序员都会犯下一个错误，采用单一的强力工具，比如特定的集成开发环境（IDE），而且再也离不开其舒适的界面。这实在是一个错误。我们要乐于超越IDE所施加的各种限制。要做到这一点，唯一的途径是保持基本工具集的“锋利”与就绪。工具将变成你的双手的延伸。

shell：

GUI的好处是WYSIWYG–所见即所得（what you see is what you get）。缺点是WYSIAYG–所见即全部所得（what you see is all you get）。GUI模型通常受限于他们的设计者想要提供的能力。如果你需要超越设计者提供的模型，你大概不会那么走运–而且很多时候，你确实需要超越这些模型。一些例子：

1.找出修改日期比你的makefile的修改日期更近的全部.c文件。

shell：find .-name ‘*.c’ -newer makefile -print
GUI:打开资源管理器，转到正确的目录，点击makefile，记下修改时间。然后调出“工具/查找”，在指定文件处输入*.c。选择“日期”选项卡，在第一个日期字段中输入记下的makefile的日期，然后点击“确定”。

2.在上周那些没有改动过的文件中，哪些使用了awt库。

shell：find .-name ‘*.java’ -mtime +7 -print |xargs grep ‘java.awt’
GUI:先找到上周没有改动过的文件（很费事儿），然后将各个文件装入编辑器，搜索字符串”java.awt”。把含有该字符串的文件的名字写下来。

可以改进的一些事儿：你是否在GUI中用手工做过一些事情？你是否将一些说明发给同事，其中涉及很多“点击这个按钮”，“选哪一项”之类的步骤？他们能自动化吗？

源码控制：

进步远非由变化组成，而是取决于好记性。不能记住过去的人，被判重复过去。

好的SCCS让你追踪变动，回答这样的问题：谁改动了这一行代码？在当前版本与上周的版本之间有什么区别？在这次发布的版本中我们改动了多少行代码？哪个文件改动最频繁？对于bug追踪，审计，性能及质量等目的，这种信息非常宝贵。

把整个项目置于源码控制系统的保护下具有一个很大的，隐蔽的好处：你可以进行自动的和可重复的产品构建。

调试：

对于调试，要接受的事实是：调试就是解决问题，要据此发起进攻。

最容易欺骗的人是自己。

如果你目睹bug或者见到bug报告时的第一反应是“那不可能”，你就完全错了。一个脑细胞都不要浪费在“那不可能”起头的思路上，因为很明显，那不仅可能，而且已经发生了。

开始修正bug的最佳途径就是让其可再现。毕竟，如果你不能再现它，你又怎么知道它已经被修正了呢？

橡皮鸭：找到问题的原因的一种简单，却非常有用的技术是向别人解释它。

bug有可能存在于OS，编译器，或者是第三方产品中–但这不应该是你的第一想法。

如果你“只改动了一样东西”，系统就停止了工作，那样东西很可能就需要对此负责–直接地或者间接地，不管那看起来有多牵强。

不要假定，要证明。

调试检查列表：

1.正在报告的问题是底层bug的直接结果，还是只是症状？
2.bug真的在编译器里？在OS里？或者是在你的代码里？
3.如果你向同事详细解释这个问题，你会说什么？
4.如果可疑代码通过了单元测试，测试是否足够完整？如果你用该数据运行单元测试，会发生什么？
5.造成这个bug的条件是否存在于系统中的其他任何地方？