软件测试管理之如何评价代码质量?

发表于:2021-10-11 09:08

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:卡修斯    来源:掘金

分享:
  代码质量的评价有很强的主观性
  最常用的评价标准有可维护性、可读性、、可扩展性、灵活性、简洁性、可复用性、可测试性。
  一、可维护性
  我们先来看看几个概念
  维护:是指修改bug、修改捞的代码、添加新的代码之类的工作;
  代码易维护:指不破坏原有代码设计、不引入新的 bug 的情况下,能够快速地修改或者添加代码;
  代码不易维护:指修改或者添加代码需要冒着极大的引入新 bug 的风险,并且需要花费很长的时间才能完成。
  我们可以从侧面上给出一个比较直观但又比较准确的感受。
  如果 bug 容易修复、修改、添加功能也能轻松完成,那我们就可以主观的认为代码对我们来说是易维护的。
  是否易维护本来就是针对维护的人来说的,不同水平的人对于同一份代码的维护能力也是不相同的,而且对系统的熟悉程度也占很大的主观因素。
  二、可读性
  如何评价一段代码的可读性呢?
  很难给出一个覆盖所有评价指标的列表,比如是否符合编码规范、命名是否达意、注释是否详尽、函数是否长短合适、模块是否清晰、是否符合高内聚低耦合等等。
  实际上,code review 是一个很好的检测代码可读性的手段。如果别人可以轻松读懂你写的代码,那说明你的代码可读性很好;如果同事读你的代码时,有很多疑问,那就说明你的代码可读性有待提高了。
  三、可扩展性
  在不修改或少量修改原有代码的情况下,通过扩展的方式添加新的功能代码。
  说直白点就是,代码预留了一些功能扩展点,你可以把新功能代码,直接插到扩展点上,而不需要一位添加一个功能而大东干戈,改动大量的原始代码。
  开闭原则
  添加一个新的功能,应该是通过在已有代码基础上扩展代码(新增模块、类、方法、属性等),而非修改已有代码(修改模块、类、方法、属性等)的方式来完成。
  关于定义,我们有两点要注意。第一点是,开闭原则并不是说完全杜绝修改,而是以最小的修改代码的代价来完成新功能的开发。第二点是,同样的代码改动,在粗代码粒度下,可能被认定为“修改”;在细代码粒度下,可能又被认定为“扩展”。
  四、灵活性
  灵活这个词的含义非常宽泛,很多场景下都可以使用功能。如果一段代码易扩展、易复用或者易用,都可以称字段代码写得比较灵活
  五、简洁性
  KISS 原则:“Keep It Simple, Stupid” 。尽量保持代码简单。
  KISS 原则是保持代码可读和可维护的重要手段。KISS 原则中的“简单”并不是以代码行数来考量的。代码行数越少并不代表代码越简单,我们还要考虑逻辑复杂度、实现难度、代码的可读性等。而且,本身就复杂的问题,用复杂的方法解决,并不违背 KISS 原则。除此之外,同样的代码,在某个业务场景下满足 KISS 原则,换一个应用场景可能就不满足了。
  KISS原则
  对于如何写出满足 KISS 原则的代码,有几条指导原则:
  · 不要使用同事可能不懂的技术来实现代码;
  · 不要重复造轮子,要善于使用已经有的工具类库;
  · 不要过度优化。
  六、可复用性
  可以简单地理解为,尽量减少重复代码的编写。
  代码可复用性和 DRY (Don't Repeat Yourself/不要重复自己)这条设计原则的关系挺紧密的。
  DRY原则
  三种代码重复的情况:实现逻辑重复、功能语义重复、代码执行重复。
  · 实现逻辑重复,但功能语义不重复的代码,并不违反 DRY 原则。
  · 实现逻辑不重复,但功能语义重复的代码,也算是违反 DRY 原则。
  · 除此之外,代码执行重复也算是违反 DRY 原则。
  提高代码可复用性的一些方法,有以下 7 点。
  · 减少代码耦合
  · 满足单一职责原则
  · 模块化
  · 业务与非业务逻辑分离
  · 通用代码下沉
  · 继承、多态、抽象、封装
  · 应用模板等设计模式
  七、可测试性
  代码可测试性的好坏,能从侧面上非常准确地反应代码质量的好坏。
  代码的可测试差,比较难写单元测试,那基本上就能说明代码设计得有问题。
  1. 什么是代码的可测试性?
  粗略地讲,所谓代码的可测试性,就是针对代码编写单元测试的难易程度。对于一段代码,如果很难为其编写单元测试,或者单元测试写起来很费劲,需要依靠单元测试框架中很高级的特性,那往往就意味着代码设计得不够合理,代码的可测试性不好。
  2. 编写可测试性代码的最有效手段
  依赖注入是编写可测试性代码的最有效手段。通过依赖注入,我们在编写单元测试的时候,可以通过mock(模拟)的方法解依赖外部服务,这也是我们在编写单元测试的过程中最有技术挑战的地方。
  3. 常见的 Anti-Patterns(反面模式)
  常见的测试不友好的代码有下面这 5 种:
  · 代码中包含未决行为逻辑(所谓的未决行为逻辑就是,代码的输出是随机或者说不确定的,比如,跟时间、随机数有关的代码。)
  · 滥用可变全局变量
  · 滥用静态方法
  · 使用复杂的继承关系
  · 高度耦合的代码

  本文内容不用于商业目的,如涉及知识产权问题,请权利人联系51Testing小编(021-64471599-8017),我们将立即处理
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号