本节书摘来自华章出版社《Effective Debugging：软件和系统调试的66个有效方法》一书中的第2章，第2.2节，作［希］迪欧米迪斯·斯宾奈里斯（Diomidis Spinellis），更多章节内容可以访问云栖社区“华章计算机”公众号查看
第10条：高效地重现程序中的问题
要想高效地调试程序问题，一个关键的因素就是要能够可靠且方便地重现它。这么说有三个理由。首先，如果我们总是能做到只按一个按钮就可以重现问题，那么自然能够专心地去寻找问题的原因，而不用再浪费时间去研究怎样才能把这个问题重现一遍。第二，如果我们可以方便地重现问题，那么也就能够同样方便地把问题描述出来，以寻求外人的帮助（参见第2条）。第三，修复错误之后，我们可以把重现问题所需的步骤执行一遍，如果程序这次没有出现故障，那就证明我们对其所做的修复是正确的。
创建短小的范例或测试用例（test case），以便重现问题，这对于提升调试的效率来说是很有帮助的。我们要遵守最小范例（minimal example）准则，这是一条黄金标准，它要求我们写出可以重现问题的最短范例。还有一条名为SSCCE的准则（参见第1条），可以称为铂金标准，它要求我们不仅要写出短小的（short）范例，而且还要把它写成自足（self-contained）且正确无误（correct，也就是可以编译、可以运行）的范例（example）。有了这种最小范例之后，我们就不用再花时间去研究那些可以忽略的代码分支了，而且我们所要创建及查看的日志文件与追踪信息，也不会变得过于冗长。此外，这种短小的范例，执行起来也要比那些较长的范例更为迅速，这其中一个重要原因在于调试模式所需的开销相当大。
为了缩短范例的长度，可以考虑自上而下与自下而上这两种办法（参见第4条），我们需要根据具体情况来决定应该采用哪种办法。如果代码中的依赖关系比较多，那么自下而上的方法或许会好一些，因为这样可以使我们在刚开始调试的时候，无需面对过多的依赖关系。如果不理解导致问题发生的真正原因，那就应该创建自上而下的测试用例，以帮助我们缩小可能包含错误的代码范围。
自下而上地进行调试时，要先对问题的原因给出一个假设，例如，我们认为是由调用某个API所引发的，然后，构建测试用例来演示这个问题。有一次笔者遇到一个用来处理输入文件的程序，这个程序的代码比较复杂，一共有2?7000行，而且运行得相当缓慢。在查看了程序所调用的系统操作之后，我猜想问题可能与调用tellg函数有关，在读取文件的时候，这个函数可以返回当前位置在文件流中的偏移量。笔者在运行了下面这个简短的代码片段之后，确认自己的假设是正确的（参见第58条），而且这个代码片段还有利于我对该问题的权宜解决方案（也就是使用包装类）进行测试。
自上而下地进行调试时，我们要从能够演示问题的场景中逐步移除各种元素，直到不能继续移除。对于这种类型的调试工作来说，二分搜索技术通常是很有帮助的。例如，我们要调试一个无法在浏览器里正常运作的HTML文件。首先，可以删去文件的head元素。如果问题依然存在，那就删掉body元素。删除之后，如果问题消失了，那么就恢复body元素，并将其中的一半内容删掉。反复执行此过程，直到我们确定了引发错误的元素。在这个过程中，我们要一直打开编辑器，并且要在进入了错误的路径之后，通过撤销功能返回到正确的路径之上，这样做会极大地提升调试效率。
有了短小的范例之后，我们很容易就能创建出一个自足的范例。这种自足的范例，不应该依赖于外部的程序库、头文件、CSS文件及Web服务等组件，以便使我们可以把它拿到其他地方运行，并将问题重现出来。如果测试用例确实需要使用某些外部元素，那么可以把那些元素与该用例捆绑起来。请注意，我们要使用可移植的形式来引用这些元素，而不要使用绝对的文件路径或固化的IP地址。例如，要使用../resources/file.css形式来引用css文件，而不能使用/home/susan/resources/file.css的形式，要使用http://localhost:8081/myService来表示Web服务，而不能使用http://193.92.66.100:8081/myService。我们可以把这种自足的范例拿到客户所在的地方进行便捷的测试，也可以把它放在另外一个平台中测试（例如，从Linux平台转移到Windows平台），还可以将其发布在问答论坛上面（参见第2条），或是将其发给厂商，以寻求进一步的帮助。
此外，我们还需要在可以制作副本的执行环境下进行调试。如果不把正在调试的代码与运行该代码的系统固定起来，那么你可能会在一个根本就没有bug的地方去白费工夫。例如，我们要调试一款软件的安装程序。每次安装该软件时，操作系统的配置都会遭到修改，这是我们要在调试过程中竭力避免的事情。在这种情况下，可以考虑创建虚拟机镜像，该镜像中是一个干净的系统，可以供我们安装这款软件。每次安装失败之后，我们只需要从头开始使用那个干净的镜像就可以了。此外，也可以通过操作系统级别的虚拟化工具或容器工具（如Docker）来达到类似的效果。如果能够装备一款系统配置管理工具，那就更好了，如可以考虑Ansible、CFEngine、Chef、Puppet或Salt等。这些工具可以根据我们所发出的高级指令来可靠地创建特定的系统配置，从而简化生产、测试以及开发环境的兼容性维护工作，并且使我们能够像管控软件那样来管控它们的演化情况。
除了上述几点，我们还应该能够对发生故障的软件版本进行可靠的重制。为此，首先应该把软件置于Git这样的配置管理工具之下。然后，在构建的过程中，选取一个与构建所用的源代码版本有关的标识符，并把它放在软件的代码里面。下面这条shell命令能够打印一条变量初始化语句，这条语句会采用与最近一次的Git提交相对应的缩略哈希码来初始化version变量，你可以把它添加到源代码中。
例如，上面那条命令可能会输出：
现在，我们可以给软件添加一种显示该字符串的方式，例如，可以通过命令行选项或About（关于）对话框来展示version变量的值。有了这个字符串，我们就可以用下面这样的命令来获取与发生故障的软件版本相对应的源代码：
如果你在用旧代码构建软件时想要精确地重现当时的境况，那么别忘了把影响最终发行成果的所有元素全都纳入版本控制系统之下，如编译器、系统程序库、第三方程序库以及构建软件时所用的规范文件（如Makefile或IDE的项目配置文件）。最后，如果你需要把工具及运行时环境所带来的各种变化因素全都去掉，那么可以参考本书第52条的建议。
要点
如果能够准确重现程序中的问题，那么我们的调试过程就会得以简化。
创建一个简短且自足的范例，以便重现程序中的问题。
设法创建一套可以制作副本的执行环境。
采用版本控制系统给特定的软件版本打上标记，以便根据此标记来获取与之对应的代码。
