第20条：开始调试之前与调试完毕之后都要把程序清理干净
如果你要调试的软件有10个地方可能出错，那么这些错误就会有上千种（2的10次方）表现形式，如果有20个地方可能出错，那么表现形式就会高达一百多万种（2的20次方）。因此，在调试的时候，应该优先关注当前区域中最容易解决的那些问题。例如：
- 能够借助工具而找到的问题（参见第51条）。
- 程序在运行时所产生的警告（例如，可恢复的断言失败）。
- 读起来比较费解，而且与你要调试的bug有所关联的那些代码（参见第48条）。
- 标有XXX、FIXME及TODO字样，或是注释中写有“它应该会……”（should）、“我想它会……”（think）以及“它必定……”（must）等托词的可疑代码。
- 其他一些已知但是却容易忽略的小bug。
如果连一个相对无错的环境都没有搭建好，就匆忙地去调试那些棘手的问题，那么很可能要遭受惨痛的失败。
有人也可以举出理由来反对这种做法。首先，这种做法与“东西没坏就别修”（If it ain’t broke, don’t fix it）的理念不相符。其次，由于我们可能只是用比较新的写法，修改了系统代码中的某一部分，因此，整个代码的风格或许会显得有些失调。面对这些理由，你需要做出自己的判断。如果你认为清理代码肯定能帮助自己调试某个难以捕获的bug，那就应该承担这种风险；反之，若是代码本身就很脆弱，而且你也明明知道自己能够直接找到这个bug，那就没有必要去冒险清理代码了。
找到并修复程序错误之后，不要急着去做其他事情，因为你还有两项任务没有完成。第一，要在代码中寻找类似的错误，并将其修复（参见第21条）。第二，要把寻找问题时所做的那些修改整理好（参见第40条）。有时我们为了凸现错误效果，可能会临时改动一些代码，这些改动现在应该予以还原。如果你是在版本控制系统里面，单独用一个分支来进行调试的（参见第26条），那么还原起来应该很方便。此外，我们在修改过程中所添加的一些代码，以后有可能还要用到，因此要把这些代码清理干净并提交上去，例如，断言、log语句以及新的调试命令等。
要点
- 在开始调试重大的bug之前，先要确保代码能够达到一定的整洁程度。
- 调试完毕之后，要把调试过程中对代码所做的临时改动还原回去，并且要把那些有用的代码提交到代码库。
时间： 2024-09-30 16:10:17