第14条：考虑对软件进行更新
接下来，笔者要说几个很多人都意想不到的bug来源。并非所有错误都是由于你自己所写的代码而造成的，用来处理这些代码的编译器或解释器、你所使用的程序库、你所依赖的数据库和应用程序服务器，以及上述工具所在的操作系统，也有可能要对程序中的bug负有责任。笔者编写本书时，Linux的源代码里面包含2700多条带有XXX字样的注释，该标记通常意味着可疑的内容，这其中有一些肯定是bug。
于是，有些bug就可以通过更新软件来解决。如果你要发布的打包应用程序里面出现了隐晦的bug，那么使用新版的编译器或程序库或许能够帮助你修复这个bug。如果你要发布基于软件的服务，那么对中间件、数据库及操作系统进行更新也是很有好处的。至少应该尝试用最新的版本来构建、链接或运行程序代码，以尽量消除因第三方组件而引入bug的概率。然而，有时采用稍微保守一些的升级策略也是很有道理的，这就是说，尽管我们知道旧版软件不太完美，但是基于某些原因，我们还是决定继续使用这些软件。有很多中间件本身编写得就有错误，或是向后兼容性不太好，因此，有经验的用户通常会较为谨慎地进行升级，他们会升级到能够解决其问题，而且发布时间第二早的那个bug修复版本上面（如6.4.3版）。此外，新版软件也会引入新的bug与兼容性问题，因此在升级的时候至少要给自己留一条退路，也就是要拟定一套明智的后退计划，如果升级失败，或是升级到的版本无法解决你所面对的bug，那么可以根据该方案退回原有的版本。我们可以在沙盒中更新第三方的代码，例如，可以对虚拟机进行复制，在复制出来的镜像里面进行更新，如果更新后的效果不好，那么直接把这份镜像丢掉就行了，这是一种可靠且较为简便的办法。尽管更新软件对解决bug确实有一定的帮助，但无论如何都不要对此抱有过高的期望。
除非你能够证明外部代码确实有错，否则最好是先假设它们正确无误。有些bug看上去好像是由第三方代码所引发的，然而在大多数情况下，其实是由于你自己的问题而造成的。30年的调试历程中，笔者在自己的代码里面修复了数以千计的bug，与之相对，由于某款流行的商业编译器生成了错误的代码而导致的bug只出现了一次，由于程序库而导致的bug只出现了几次，由于操作系统的功能不稳定而导致的bug只出现了一次，由于描述系统调用的文档有错而导致的bug只出现了几次，由于工具和其他系统软件而导致的bug也只出现了几十次。因此，对软件进行更新的最大意义，就在于给我们提供一个新的起点，令我们可以下定决心来好好清理自己的代码。
要点
- 在更新之后的环境里面重新尝试你所编写的代码，看看这次会不会出错。
- 不要对更新软件所带来的效果抱有过高的期望。
- 要考虑因第三方组件而引发bug的可能性。