你修改代码方式是“编辑并祈祷”还是“覆盖并修改”？

经常有人会问我，软件出了问题，修改了代码，怎么做验证？

当然是回归测试啦！——我通常都会给出同样的回答。

可是，实际上很多获取了GJB5000资质的组织，软件修改之后，还只是软件工程师编译通过之后就直接提交去应用，根本不进行回归测试，甚至也不做更改测试。

这种修改代码的方式，被称之为“编辑并祈祷”——软件工程师按照自己对问题的理解找到代码中错误位置，修改、编译之后就祈祷通过联试或相关的实验。

可是，这种听天由命的方式并不都是很“灵”。这样修改的软件提交上去，问题可能根本没有解决，或者解决了当前问题，却又出现新的问题。

阿成负责的软件在系统联试的过程中发现某个功能出现了问题，由于系统马上面临出厂参加某项目的竞标，他迅速对问题进行了分析，找到原因后出库了同一版本的软件，修改、编译通过后，再次提交系统，顺利通过联试。可是在外场竞标过程中，软件的另一个功能又出现了问题，而这个问题之前已经出现并且做了修改，所以再次出现，是因为上次修改的版本没有受控，他出库并且修改了这次问题的版本还有着上个缺陷，而且他这次修改问题后没有进行回归测试，只在联试过程中验证了本次问题是否得到更改。

这个故事说明，科学来不得弄虚作假，靠祈祷而不是回归测试来验证修改的正确性是行不通的。

正确的修改代码方式是“覆盖并修改”。这里说的“覆盖”是用测试覆盖验证修改部分是正确的，同时修改也没有引入新的Bug。

换句话说，就是要做好回归测试。

也许有人会说，联试/实验任务那么紧张，我没有时间进行测试？

那么，如果不进行测试，软件在后续的联试/实验中出现问题，你就有时间解决问题吗？在联试/实验前花费测试人员和开发人员一点时间验证正确地进行了修改所需要的时间多还是在联试/实验过程中出来问题，暂时中止联试/实验，等待软件修复所需要的时间多？

明明可以第一次就把事情做对，为什么非得要事后补救？

喊出“质量免费”的克劳士比估计已经气晕了！

如果组织能够实现自动化测试，那么回归测试的成本会大大降低，组织也就不用担心“覆盖并修改”的修改代码方式花费的时间太长。

你的修改代码方式是“编辑并祈祷”还是“覆盖并修改”？

这正是：

代码修改需验证，光靠祈祷可不中

验证测试要回归，更改测试还不行

参考书目：修改代码的艺术，作者：（美）费瑟（Michael C.Feathers）著，出版社：机械工业出版社