Working effective with legacy code读书笔记:根据反馈工作

 

这一章节的题目是Working With Feedback，暂时没有想到合适的翻译，姑且叫做“根据反馈工作”

我们可以以两种方式进行改变，作者称之为“ Edit and Pray”和“ Cover and Modify”。

Edit and Pray的工作方式是：首先计划要修改的内容，然后阅读和分析要修改的部分，确保理解了要修改的代码，然后进行修改。修改完成后，启动程序来验证修改生效了，然后在程序中“四处乱逛”来检查其他的部分没有被破坏。

Cover and Modify的工作思想是：当我们修改代码的时候，会有一个“安全网”来保证我们的修改是正确的。这里 Cover的意思是使用测试来覆盖代码。当我们的代码有足够的测试的时候，我们能够很快的知道我们的修改是正确的还是错误的。

在传统的方式下，测试是在开发之后编写和执行的。开发人员编写代码，然后交给测试人员测试。然后开发人员得到反馈，并根据反馈修改代码。通常这个过程会比较长（就算是开发人员和测试人员在同一个办公室工作，也是以天来计算吧。甚至是一周或更长）。

另外一种测试就是我们常说的回归测试。当我们做了修改之后，我们要保证其他的功能没有被破坏，于是要把以前确认过的正确的功能重新测试一遍，这个叫做回归测试。那么我们改变了代码之后，为什么不立刻进行回归测试来验证我们的代码没有破坏其他的功能呢？原因是在传统的方法中，回归测试都是在 Interface这个层面上进行的，并且是由测试人员执行的。因此，第一我们不可能每做一点修改，就要求测试人员为我们运行回归测试。通常的情况下是测试组有自己的计划，可能是每天运行一次回归测试。第二，当测试组按照自己的计划运行了回归测试之后，因为在两次回归测试之间，开发组可能做了多个改变，因此即使回归测试发现了问题，也不能准确的说出这个问题是由哪个改变引起的。

如果我们有完善的单元测试，我们就可以做一点修改，然后运行单元测试来确保所有的测试都可以通过，几分钟之后我们就可以得到反馈。这样有助于我们改变代码并定位错误。