在过去的一年里，甚至往前追溯更长的时间里，每次在分析上线的故障，bug 的原因后，总有这么一条是常常出现的，那就是没有正确评估影响范围。
在一次做全站 https 化的时候，出现多次因为公共参数和业务参数覆盖引起的 bug。这样的问题本不应该在这个项目中出现，只因为我“顺手”把公共参数相关的代码整理了一下，结果在一些接口上就出现了错误。听上去比较奇葩，一定程度上可以看出，当前项目中很多接口当初在定义和使用的时候还是很不规范的，比如定义的业务参数和公共参数重复，但是意义又不一样。抛开这些比较奇葩的代码，主要原因还是我对公共参数相关的代码进行了修改，才引起的 bug。
主要原因是修改的范围比项目预定的目标要大。比如那个项目，预期的目标只是 http 升级为 https，公共参数相关的内容并没有在范围内，而且提供给测试的影响范围又不包含公共参数的修改，更没有评估到会影响到个别接口。所以 bug 的主要原因是修改的范围扩大，评估的范围缩小了。
在以后的项目中，要多次提醒自己，把修改的影响范围尽量的缩小，能不改的尽量不改，能不动的尽量不动。项目中存在很多设计、实现不合理的地方，可以单独立项去整理，重新设计，组织重构，但千万不要在项目中，顺便修改了。一旦顺便修改了，影响的范围就开始出现盲区。
通常会受限于测试对全面回归的压力，有意无意的缩小了影响范围的评估。申请测试资源难度比较大，也没有直接的测试资源对接，导致在给出影响范围的时候，所以之前都尽量不出现全面回归，或者大范围回归之类的评估。测试资源的事情，应该通过沟通来解决，而不要通过缩小影响范围来解决。
有时候修改的内容是无意识的扩大的，除了要告诉自己尽量减小修改范围外，还需要有另外一个保护措施，在修改完代码后，客观登记修改范围。其实我们在提交代码的时候，就应该描述修改范围，但是由于注释写得比较简略，基本上不可能描述清楚修改的内容，再加上平时提交代码也比较随意，使得这些注释不可能帮到什么忙。所以在项目提测的时候，要刻意的要求自己编写一个清单文档，描述一下自己修改了哪些内容，都会有哪些影响。
- EOF -
本站文章除注明转载外，均为本站原创或编译。欢迎任何形式的转载，但请务必注明出处，尊重他人劳动。
转载请注明：文章转载自 Binkery 技术博客 [https://binkery.com]
本文标题： 为什么做好技术评估那么难
本文地址： https://binkery.com/archives/2020.01.02-技术评估.html