当你在修复现有代码中的bug时，很容易养成一种习惯，那就是找到代码中的"错误"，然后调整代码来避免错误。但如果问题的根本原因是设计错误，或者是算法的问题，那么只是在代码中再增加一个标志或goto语句是错误的做法。你不仅把根本原因留了下来，而且现在你还让下一个要弄明白的软件工程师更难理解代码。
训练自己问"如果我是最初的编码员，我会如何解决这个问题？"然后看看"一张干净的纸"的方法和实际摆在你面前的方法的区别。但要实事求是。我当然不是建议你应该因为你和作者的方法不同而重新实现一个函数。把这一步作为一个思想实验。你有一个测试用例，失败了。笔者漏掉了这个案例。是什么导致她错过了这个案例？如果作者知道这个案例，她的方法会有什么不同？这些类型的问题在挖掘基本能用，但仍有一些bug的代码时是非常宝贵的。
在我们的案例中，我意识到我们可以通过改变子步骤的执行顺序来修复算法，而不是在内部函数中添加另一个参数，在主程序的3个不同的入口点添加另一个必须正确初始化的自动变量，并在一个关键点添加代码来测试这个新变量。一旦我们这样做了，对额外变量和特殊情况的需求就消失了。最终的代码其实比原来的代码更容易理解，更不用说第一次尝试修复了。这让我有信心，我们的方向是正确的。重现问题的测试用例证明，无论是原来的（过于复杂的）修复，还是修改后的（简化的）修复，都能解决这个问题。现在我们只需要确定我们没有破坏其他东西。
由于这个修复是面向现场发布的（即已经在客户处安装的），我们还将运行三种类型的强化回归测试。其中两类将检查是否继续遵守POSIX标准（错误修复在实现POSIX函数的代码中），第三类测试是一般系统级回归测试。
先修正算法。算法正确后，再处理代码。