码农第二定律-缺陷总是会有的【二】

缺陷总是会有的：

重用应对策略：

        1. 定好规则

                项目组需要提前上衣好相关处理规则，如缺陷的分类，问题的沟通规则等。以方便大家在项目过程中有法可依。目前组织级已有缺陷定级的规则，各产品可以根据自身的特点，在组织级的规则基础上，对某些可能有分歧的说法给出本产品的具体说明，完善本产品的缺陷定级规则，清晰的定义和规则，可以减少分歧带来的时间浪费。

        2. 提前发现问题

                问题发现的越早，解决的成本越低

                通过考察开发阶段的缺陷占比，可以引导项目组尽可能提前发现问题。做好项目中的评审和代码检视，都是提前发现问题的方式。通过先开发一个样本，或者精益开发中的MVP概念，采用小版本迭代等等，都可以加快反馈循环，从而提前发现一些方案设计，开发习惯等系统性的问题

        3. 彻底解决

                一方便是针对的那个问题的深度挖掘，并不只是针对缺陷中描述的场景，还需要深入分析，搞清楚关联影响，从业务流程，系统流程等多方面，考虑当前缺陷的影响范围。比如有没有和其他模块间的调用，比如业务流程的上下游，都需要确认是否受此缺陷的影响，在修改的时候需要一并考虑

                另一方面是对该问题的广度挖掘，在项目和产品中有没有和这个问题类似的其他场景，模块，是否会有类似的问题？如果有的话应该一并解决。

                另外，一旦发现问题，都需要尽快解决，问题的出现会导致测试被阻塞，从而影响后续的测试计划执行。

                只有尽快解决当前问题，退出回归验证及后续测试的执行，才能验证后续过程是否还有其他问题，同事也才能确认当前的解决方案在全流程来看是否是合适的，之前出现过在第一步出现的问题解决后，测到第三部的时候发现第一步的解决方案是有问题的，需要重新考虑，重新修改。

        4. 任何缺陷都需要有应对方案

                应对方案不一定是修改代码

                应对方案也不一定要完全解决或避免问题

                不要觉得某些场景是百年一遇的极端异常就不去考虑，考虑的点只有一个，就是‘是否会对生产运行造成影响’，有影响的，即使是百年一遇，也需要给出解决方案，这个方案可能是什么都不做，出现后就接受这个影响（当然需要项目组一致认可），也可能是出现问题后人工处理等等，总之一定要有应对方案

        5. 采用配置或手工处理入口

                由于无论怎么测试，怎么集思广益，都无法保证项目上线后的不出问题。毕竟缺陷总是会有的。所以很多时候需要再系统实现上做一些考虑。比如对于某些风险较高的场景，可以考虑使用配置或开关的形式，以防万一出现问题时，可以很方便的进行功能切换。也可以提前做好一些手工异常处理入口，在出现问题的时候，可以通过手工重试等。

        6. 做好缺陷记录和总结

                出现缺陷是正常的，但是总是重复出现同样类型的缺陷是有问题的。做好缺陷的记录和总结，提供一些工具和流程进行辅助（比如检查项扫描），都可以减少重复缺陷的情况

注：摘自多年前的领导分享，其言辞充满睿智和启发，深刻地触及了我对工作和生活的理解，再次感谢。