为什么做好技术评估那么难

  • 技术评估,影响范围评估

在过去的一年里,甚至往前追溯更长的时间里,每次在分析上线的故障,bug 的原因后,总有这么一条是常常出现的,那就是没有正确评估影响范围。

在一次做全站 https 化的时候,出现多次因为公共参数和业务参数覆盖引起的 bug。这样的问题本不应该在这个项目中出现,只因为我“顺手”把公共参数相关的代码整理了一下,结果在一些接口上就出现了错误。听上去比较奇葩,一定程度上可以看出,当前项目中很多接口当初在定义和使用的时候还是很不规范的,比如定义的业务参数和公共参数重复,但是意义又不一样。抛开这些比较奇葩的代码,主要原因还是我对公共参数相关的代码进行了修改,才引起的 bug。

主要原因是修改的范围比项目预定的目标要大。比如那个项目,预期的目标只是 http 升级为 https,公共参数相关的内容并没有在范围内,而且提供给测试的影响范围又不包含公共参数的修改,更没有评估到会影响到个别接口。所以 bug 的主要原因是修改的范围扩大,评估的范围缩小了。

坚持修改范围最小化

在以后的项目中,要多次提醒自己,把修改的影响范围尽量的缩小,能不改的尽量不改,能不动的尽量不动。项目中存在很多设计、实现不合理的地方,可以单独立项去整理,重新设计,组织重构,但千万不要在项目中,顺便修改了。一旦顺便修改了,影响的范围就开始出现盲区。

尽可能全面评估影响范围

通常会受限于测试对全面回归的压力,有意无意的缩小了影响范围的评估。申请测试资源难度比较大,也没有直接的测试资源对接,导致在给出影响范围的时候,所以之前都尽量不出现全面回归,或者大范围回归之类的评估。测试资源的事情,应该通过沟通来解决,而不要通过缩小影响范围来解决。

登记修改范围

有时候修改的内容是无意识的扩大的,除了要告诉自己尽量减小修改范围外,还需要有另外一个保护措施,在修改完代码后,客观登记修改范围。其实我们在提交代码的时候,就应该描述修改范围,但是由于注释写得比较简略,基本上不可能描述清楚修改的内容,再加上平时提交代码也比较随意,使得这些注释不可能帮到什么忙。所以在项目提测的时候,要刻意的要求自己编写一个清单文档,描述一下自己修改了哪些内容,都会有哪些影响。

相关文章

- EOF -

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动。
转载请注明:文章转载自 Binkery 技术博客 [https://binkery.com]
本文标题: 为什么做好技术评估那么难
本文地址: https://binkery.com/archives/2020.01.02-技术评估.html

赞助商
网站统计
  • 网站运行:3318 天
  • 文章总数:738 篇
  • 网站统计