测试经验丨代码质量定性评估

之前有和认识的同行聊过他们全链路压测的一些技术实现方案，自己也看了很多相关的资料，这篇博客，说说自己对全链路压测的理解 提到“质量”二字时，我们的第一反应往往是“有多少BUG？”“性能好不好？“这样的问题。我们对软件产品或服务的质量定义看其能不能满足用户的需求，包括功能、性能和体验等维度的指标，我们可以通过各种类型的检测手段来给出其质量高低的度量。但是，如果直接拿出一段源代码放在我们面前，问这段代码的质量好坏时，我们又该如何作答呢？ 有人说：“好的代码就像好的笑话一样，它不需要解释（Good code is like a good joke: It needs no explanation）”。有编码经验的人对代码都有一定的“鉴赏力”，能凭感觉给出代码好坏的主观评价，看到所谓的“意大利面条式代码”都会感到不舒服，但是这样凭感觉的方式太个性化、太随意了，有没有一种公认的标准来鉴定代码质量呢？ Martin Fowler在其著作《重构：改善即有代码的设计》中生动形象的使用“代码坏味道（Bad Code Smells）”来比喻低质量的代码设计和实现所显现的“症状”。书中罗列了22种代码坏味道以及对应的重构手法。 参照这些资料，现在我们可以用可测性，可读性，可理解性，容变性等代码可维护性维度的质量属性来衡量代码质量。代码质量指的是代码内在的非功能性的质量，用户不能直接体验到这种质量的好坏，代码质量不好，最直接的“受害者”是开发者或组织自身，因为代码质量好坏直接决定了软件的可维护性成本的高低，例如重复代码会造成维护成本的成倍增加；不规范的代码、不良注释和复杂度过高的代码会增加阅读和理解代码的难度，复杂度过高也会极大增加测试覆盖的难度，耗费过多人力，而缺少测试覆盖的代码会使得定位问题和修复问题的难度加大；结构不良、低内聚高耦合的代码则会使得哪怕是微小的需求变更或功能扩展都无从下手，修改的代价很可能超过了重写的代价。 至此，我们得到了一些定性的办法来衡量代码的质量，我们可以借助一些代码扫描工具来暴露代码的质量问题，也有了相应的重构方法和技巧来应对这些问题。但是，我们还是难以回答某段代码有多好或多差，两段代码相比哪个更好这样的问题，因为我们仍然没有完全解决代码质量的量化问题：同样都是代码质量问题，重复代码和过多注释的危害肯定是不一样的；同样都是方法太复杂，圈复杂度为10的方法和圈复杂度为20的方法相比，危害和修改难度也差别很大。所以我们不能直接用问题的数量来衡量质量，需要找到更精细合理的量化度量方法。