小猪大虾_码农叮咚变
十多年HP，IBM等外企经验，熟悉质量体系，流程方法，项目管理等
欢迎关注大虾，从技术到技术管理，少走弯路

硬技能是咱技术人的基础，软技能才真正拉开人与人之间的差距
您正在阅读的是软技能入门《程序员必备软技能 – 质量篇》系列
各篇相对独立，也欢迎您从本系列的第一篇《质量之缘起》开始，系统化学习

概要

修改代码可不是简单的事情，往往修改一个地方，却把别的地方给改坏了。很多生产问题都是改出来的。大虾当然也有一套方法来解决这个问题。一起往下看，来提高自己的段位吧。

为什么要强调“正确”

大虾问同学们一个问题：写新的代码难，还是改已有的代码难。如果有回答写新的代码难，改代码简单，那么一定是还没吃够苦头。生产中发现的很多Bug都是修改代码改出来的。因为新写的代码，我们会进行相应的测试，即使有问题在自测或者其他测试阶段就被发现并修复了。但是对于修改代码，情况就复杂多了。软件产品的复杂度高，各个模块相互调用，关系错综复杂。碰到没有注释，或者风格差的代码，更是千头万绪无法理清，简直是要命。这样的代码可维护性，可扩展性都很差。常常因为一个很小的改动，就把其他模块搞坏了，真是牵一发而动全身啊。更要命的是往往我们不知道把其他模块改坏了，测试人员也很难突然去测试不相关的模块，除非进行回归测试才可能发现。我想很多同学都经历过这样的至暗时刻。本来想修复一个Bug，结果这个Bug确实是修复了，但是不知情的情况下，新引入了好几个Bug。管理人员也是非常头痛，时不时响起咆哮声：怎么又把好的地方改坏啦。

这类问题一部分来源于软件的复杂性，但更重要的是程序员工作不规范的问题。我们在修改代码前，一定要了解代码的来龙去脉，判断不会影响到其他模块，然后再动手。否则就是瞎改，害人害己啊。

这也是为什么大虾要特意强调“正确”的原因。实际上对代码的更改，绝大多数时间都是花在调查上的，剩下的主要就是测试了，真正改代码的时间是很少的。很可能经过半个小时，或者几个小时的调查，就改动了2，3行代码。

除了以上介绍的“改坏”，还有一类典型的问题就是：“改漏“（没改全）。比如：将系统中的所有出现XXX文本的地方替换成新文本。大家都觉得非常简单，用文本检索整个工程，然后进行替换，搞定，鼓掌。最后发现还是遗漏了，有些文本会存在数据库，或者配置文件中。因此，除了源代码外，还应调查数据库和配置文件等等。最后一定不要着急直接进行替换，一定要做好调查工作，确认不会影响到其他模块，再进行替换。

从以上文本替换的简单例子可以看出，即使对代码进行简单的修改也并不简单，那么我们有什么工具来辅助我们正确修改代码呢。大虾的答案是“影响范围调查”，在实际项目中应用的效果非常好。在项目中，大虾不仅反复强调影响范围调查的重要性，还把“影响范围调查”列到Checklist中，要求每个开发人员在修改代码前，必须进行影响范围调查。接下来我们将重点介绍这个工具。

影响范围调查

相信大多数同学们都有过这样的经历，我们按照业务要求修改了某个功能，并且通过了自测及测试人员的测试，但是在回归测试或者上线后，却发现别的模块出了问题。这是因为软件是非常复杂的产品，各个模块间相互调用，一个模块的修改可能会影响到其他的多个模块，如果不对相关模块彻底调查就贸然修改，就会导致其他相关模块出现问题。因此，修改代码前，务必要先进行影响范围调查，切记！切记！切记！

那么我们如何做影响范围调查呢。大虾将影响范围调查分为：纵向调查和横向调查。本节介绍纵向调查，横向调查将在下一节进行介绍。

所谓纵向调查就是采用回溯法梳理出完整的调用链。回溯很好理解，比如：我们调查到函数A需要修改，所以修改A前我们必须做影响范围调查。通过回溯发现A被B，C调用，B又被D，E调用等等，如下图所示，一直调查到前端，列出所有的调用链。如果A的修改，导致影响到的所有模块，都是符合业务需求的，那么我们就可以直接对A进行修改。如果对A的修改，导致部分模块不符合业务需求，可以考虑从A复制一份A’，然后保持A不变，仅对A’进行修改，在调整部分调用关系从A改为A’即可。这里仅仅举个例子，现实情况往往更为复杂，因此动手前务必调查清楚。

下图的模板整合了影响范围调查及Checklist的功能。

很多Bug的产生都是因为影响范围调查没有做或者做的不够而导致的。下面我们聊聊怎么贯彻强制执行这项规范。同学们一定已经想到了，没错就是Checklist。

我们可以在Checklist中加入这一项：是否做过影响范围调查。当开发成员都是负责任且懂得影响范围调查方法的情况，大虾觉得这种粒度已经足够了。当然我们可以选择使用更详细的规则，比如改为：后端是否使用回溯法调查出所有的controller层入口函数并确认是否有影响；前端是否调查出调用所有controller层入口函数的模块并确认是否有影响。当然我们也可以要求使用前面提到的调用链模板，强制要求记录下调查的过程，以保证确实执行了详细的调查。不同的粒度对应不同的人力成本。还是那句话：一切从项目的实际情况出发，使用“剪刀手”进行裁剪。

现在我们知道修改源代码之前，一定要进行影响范围调查。其实修改需求，设计等文档也需要进行影响范围调查，不然可能导致文档前后不一致，或者多个文档间不一致，甚至不能形成业务闭环也时有发生。另外，修改相应的测试用例，以及选择回归测试的范围，也离不开影响范围的调查。可以套用评审的经典台词：任何成果物都可以通过相应的评审来减少缺陷提高质量。任何成果物修改也都可以通过影响范围调查来减少缺陷提高质量。

最后，影响范围调查除了上面介绍的纵向调查，还有横向的调查。比如：之前举的文本替换的例子。接下来我们将详细介绍横向调查。

横展开

相信做过对日项目的同学一定听过“横展开”这个词。大虾也在搜索引擎上进行了搜索，这个词属于工厂品质管理的专业术语，是指若发现不良，则应对同样生产因素下或同批次的产品进行扩展查证，防止同样的不良品的批量潜伏。

同样在软件开发中，当发现缺陷时，务必要进行横展开调查。打个比方：测试人员测出一个按钮有重复提交的问题，当快速点击按钮，有多条相同数据落库。我们针对这个缺陷报告，一定要进行横展开，调查重复提交是否是所有按钮共通的问题，而不应该仅仅对应缺陷报告中那个按钮的问题，而不进行横向展开调查。再比如：客户反馈生产系统，未按照业务要求将“A部门”应全部替换成“B部门”，在提示文本中出现“A部门”这个词。这个时候我们不仅要对源代码进行全检索，也应该对数据库，配置文件等进行全检索调查。如果有其他遗漏的地方也要进行替换，而不是仅仅修改客户反馈的提示文本。另外，如果一个多前端（App，小程序，Web页面）的系统，发现App存在一个缺陷，那么我们也应排查其他前端是否也有相同的缺陷。其他例子很多，不在一一列举。

同学们可能会说我不清楚是否需要横展开怎么办？首先这个问题本身就有问题。我们应当对任何缺陷做横展开的假设，如果无法一眼判断不需要进行横展开，那么进行横展开调查总归没错的。

“横展开”需要根植到我们的潜意识中，当像领导汇报问题的对应情况时，记得一定要说：针对这个问题我们进行了横展开调查，还发现存在两处类似的问题，我们也一并修改完成了。这时领导一定会投来赞许的目光，心想这个小伙/小姑娘还挺靠谱的。当然“横展开”这个词还是有不少人没有听过，所以具体沟通时，需要根据沟通对象使用对方听得懂的词汇。比如可以改用：横向展开；展开调查等等。

最后，横展开同样在需求，设计，测试用例等文档的修改上发挥作用。因此，套用影响范围调查的台词：任何成果物修改都可以通过横展开来减少缺陷提高质量。

方案选择

经过艰苦卓绝的“影响范围调查”，同学们感觉终于可以松口气了，终于到了令人激动的改代码环节了，正准备撸起袖子开搞。且慢，同学们有没有发现往往会存在多种修改方案，具体怎么改还得从长计议。听到这里是不是感觉要裂开啦。

正所谓：条条大路通罗马，但是并不是每一条路都好走，我们应该选择一条合适的好走的路，而不要没有困难自己非要创造困难，难道觉得不经历九九八十一难到达罗马没有仪式感吗。

即使是最简单的修改也存在多种方案。不信的话，请看下图，原代码逻辑B调用A，针对新的业务需求我们需要增加C对A的调用，A中部分代码可以重用。我们有两种实现方案。方案一，增加函数A的入参用来区分来自不同的调用，并增加一个条件分支，并在不同分支里处理B，C各自的逻辑。方案二，拷贝函数A为A，函数C调用A，然后对A`函数进行修改，以符合C的逻辑。

具体哪种方案好呢。第一个方案：冗余代码少，但是显然对之前函数B的逻辑代码进行了修改，可能引入新的问题。第二个方案：对函数B没有任何影响，所有的影响控制在新写的代码中，但是冗余代码量较多，不利于后期维护。两种方案都有各自的道理，也都有各自的短板。如果仅从技术角度考虑，就哪种方案更好进行争论是没有结果的。往往咱们程序员自尊心都是比较强的，自己的方案落选等于被啪啪打脸。即使争得面红耳赤，甚至大打出手也在所不惜。大虾项目中就因为修改方案的选择，爆发过非常激烈的争吵，还好大家还算克制没有动手。

优秀的人拥有系统化的知识结构，可以从全局考虑，迅速作出决策，找到更适合项目的方案。而普通人的知识是碎片化的，没有很明确的思考方向，又或许根本没有深入思考过，就是认为自己的方案技术上没问题，凭什么不用，老子就是不服。大虾希望同学们都能多学习，多实践，多思考，多总结，形成自己的系统，做优秀的人。

那么我们应该如何选择方案呢。首先需要跳出技术的框框，从全局思考，找到更适合项目的方案。通常大虾会综合考虑时间的紧迫性，业务的实际情况，风险，以及可维护性，然后作出决策。

从时间的紧迫性及业务的实际情况角度，比如：生产环境出现问题，你还有时间考虑完美的方案吗？还考虑代码的可维护性吗？如果此业务的发生概率很低，或者这段时间不会再发生，如：季度报表等。我们是否只要人工修复数据，暂不修复代码逻辑。或者先使用临时方案，用最小的代价，在短时间内修复。以后有时间再考虑长久的方案。又比如：你已经奋战到凌晨，还有几个小时就要交差了，你还时间和心情考虑完美的方案吗？能不能先用个临时方案，以后再考虑最终方案呢。

从风险的角度，如果有一个方案，会影响到很多模块，甚至核心模块，即影响范围很大，那么最好还是选择其他方案。我们脑子里时刻要有一根弦：如果影响到这些核心模块，产生的后果，我们是否能够承担得起。另外，任何影响到的地方都需要重新测试，不同的方案影响范围不同，如：接口的改动，可能需要别的团队一起协助进行测试。因此，我们必须考虑方案的可测试，以及是否便于测试，即测试友好性。因此，同学们应该全面考虑影响范围，测试友好性等方面带来的风险，并始终把风险放在考虑的第一位。

最后，关于可维护性，我们在第一章的质量六要素中已经做了介绍。可维护性差意味着将来更容易出现问题，以及更高的维护成本。但是相比风险的话，可维护性的优先级就没那么高了。如果两个方案的风险都是可以接受的，那么再考虑可维护性吧。

后续工作

经过了影响范围调查，方案选择，终于到了激动人心的改代码环节了，同学们抑制不住心中的兴奋，但是对于大虾来说修改代码这块反而没有什么好说的，是不是给大家浇了一盆冷水啊，哈哈哈。我们重点要说的是如何做好后续的工作，来保障正确修复。后续的工作包含两个重要的环节：自测，以及测试人员进行测试。关于测试，后面有专门章节进行讲解。

很多同学都不太重视自测，认为有专门的测试人员，自己只要随便验一下就可以了。这种想法是非常错误的。不仅对别人不负责任，更是对自己不负责任，最终只会影响到自己的专业性，影响到领导对自己的评价。质量不仅是测试人员的事情，而是每一个成员的责任。另外，每个环节的职责范围不同，如果自测不到位，那么测试人员从功能角度测试，很多自测遗漏导致的Bug是很难被发现的。因此，自测的时候，务必测试到每一行改动过的代码，以及所有影响到的模块。

另外，虽然测试人员会从业务角度进行影响范围调查，但是测试人员无法从代码角度了解影响范围。因此，作为有职业素养的程序员应该主动将代码角度的影响范围告知测试人员。在全量测试不可能的情况下，测试人员才可以综合业务和代码的影响范围，选定合理的测试范围。当然更好的方法不是靠程序员的职业素养，而是由管理者制定好这个规则，并通过方法确保规则被执行。

大虾项目中就采用更多角色的视角来划定测试的范围。除了开发人员和测试外，还增加了产品经理。经过三个不同角色从不同角度划定范围，减少了遗漏，达成了更高的质量目标。

小结

修改代码可不是简单的事情，往往修改一个地方，却把别的地方给改坏了，而且很难被发现。针对“正确修复”，大虾提出了“影响范围调查”。影响范围调查分为：纵向调查和横向调查。纵向调查采用回溯法调查出所有的调用链，然后梳理出影响范围。纵向调查主要针对“改坏”，而横向调查主要针对“改漏”。生产上很大一部分Bug都是由于没有做影响范围调查或者做得不够而导致的。因此，代码修改前，我们都应该从纵向和横向两个维度，进行全面的影响范围调查。

调查完成后，我们需要确定修改方案。任何改动都会有多种方案，并且通常这些方案技术上都是可行的。没有最好的方案，只有更适合的方案。大虾希望同学们能跳出技术的框框，从全局的角度来思考选择方案。通常大虾会综合考虑时间的紧迫性，业务的实际情况，风险，以及可维护性，然后作出决策。关于可维护性大虾在这里做个补充：可维护性影响的是将来的质量，毕竟欠债总是要还滴。

方案选择完成后，别忘了后续工作。修改代码没什么好说的，重点要说的是后续的自测，以及测试人员进行测试。自测的时候，务必测试到每一行改动过的代码，以及所有影响到的模块。由于测试人员无法从代码角度了解影响范围。因此，作为有职业素养的程序员应该主动将代码角度的影响范围告知测试人员。测试人员才可以综合业务和代码的影响范围，选定合适的测试范围。当然更好的方法不是靠程序员的职业素养，而是由管理者制定好这个规则，并通过方法确保规则被执行。