敏捷项目中的代码质量管理

Posted 2021-05-02 麒麟敏捷社区

 

代码质量是什么？

在软件项目中提到质量，我们第一反应往往是“有多少BUG”，“性能如何”等这样的问题，而这些是软件项目的产品质量，并不是本文接下来所提到的代码质量。代码质量是软件项目的内部质量，它不会直接反馈给用户，但会间接地影响产品质量，它主要包括以下几个方面：

1、编码规范：是否遵守了编码规范，遵循了最佳实践。

2、潜在的BUG：可能在最坏情况下出现的问题代码，以及存在的安全漏洞的代码。

3、文档和注释：过少（缺少必要信息）、过多（没有信息量）、过时的文档或者注释。

4、重复代码：违反了DRY原则（Don’t Repeat Yourself）。

5、复杂度：代码结构太复杂（如圈复杂度高），难以理解、测试和维护。

6、测试覆盖率：编写单元测试，特别是针对复杂代码的测试覆盖是否足够。

7、设计与架构：是否高内聚、低耦合、依赖最少。

 

代码质量的重要性

敏捷开发模式是目前业内最主流的开发模式。敏捷开发模式要求团队循环往复地在较短的迭代周期内交付增量产出。虽然每个迭代的周期不长，但项目的整体周期较长，代码质量是团队在敏捷迭代中高效交付有价值增量的保证。因为，在一堆难以维护的低质量代码上进行开发新功能和修改已有功能所消耗的代价非常大，如下图，若不重视代码质量，团队的产出效率会不断地下降，最终导致项目的失败。

 

代码质量为何会降低？

在物理学中有一个非常重要的定律—熵增定律。它描述在一个封闭的系统中，熵总是会不断的增大的，即任何系统若没有外力做功，一定会从有序的状态向无序的状态变化。

这个定律可以类比到软件项目中，代码质量是系统的有序程度，烂代码的增加就是系统无序性上升的体现，在没有外力影响下，即没有花费代价去控制管理，烂代码只会越来越多。

 

我们常常会碰到这种情况，当业务压力大时，大家往往都会妥协为了节省时间而没有去讲究代码质量，因而产生低质量的代码。后续迭代的开发效率受到低质量代码的影响而下降，导致业务压力更大，形成了恶性循环。

为了应对业务压力，最常见的做法就是增加人力，但是只是单纯的增加人力则会导致因大家编码能力和风格不一致、沟通成本上升等原因导致代码质量下降，依然没有跳出恶性循环，从本质上解决开发效率下降问题。

 

代码质量如何管理？

代码质量的管理是一个系统性的工作，既要管理代码产生的源头，也需要在持续集成的过程中通过自动化工具的方式控制和审核增量的代码。本文接下来将主要描述如何建立统一的编码规范和Code Review体系来控制代码生产源头。

• 建立统一的编码规范

建立统一的编码规范最主要的目的是增强代码的可读性。因为在团队协作的开发中，编写让机器能够读懂的代码很容易，而要编写让人能够很容易就读懂的代码并不容易。如果别人甚至是过了几周后的你自己都无法理解你之前写的代码，又如何维护这部分代码或在此基础上编写新的功能呢？因此，一个团队使用统一的编码规范是保障代码质量的基础。虽然不同团队的编码规范要求不尽相同，但它通常都包括以下三部分：

1、风格规范：函数、变量与类的命名，缩进、换行、空格、大小写等风格统一，整体提高代码阅读起来的舒适度。这其中比较重要的就是命名规范。虽然代码可以通过注释来表达代码的意思，但是代码应当尽可能地自表达。命名对于开发者来说仿佛一个绕不开的哲学问题，高质量的代码一定具备高质量的命名。

开发过程中要避免如下常见的命名问题：

①拼音命名 : youyu; ②超长命名 : theInputtedKeyCharaterOfHardKeyBoard;

③命名和行为不一致 : 常见在方法命名中如update方法做了insert操作; 

④无意义命名：temp、result接收返回值。

下面是几点常用的代码命名的艺术：

注意词性：属性一般用名词命名；方法一般要是动词或动名词；适当的使用介词和连词（by-根据条件、for-前面的动作为了后面的目的、and-并且、or-或）

适当的进行词语缩写：如information->info , length->len , manager->mgr,message->msg,object->obj

方法的命名：动词+名词的基本原则；考虑返回类型（返回列表时名词复数形式、返回布尔类型时最好用is/can/need/has/contains）

  

2、实践规范：这部分规范通常是前人根据无数经验教训总结出来的经验，能够规避一些常见的隐患，或针对特定问题的最佳实践。主要包括：

①不要过度的设计和过早的优化。项目考虑性能、便利性、成本和交付时间等因素时，要根据实际情况有所侧重，没有最佳方案只有最适合的方案，另外过早的优化往往是不确定的投入，不一定能产生价值，总之要确保投入能够获得最大的价值。

②注重代码的内聚性，高内聚是指一个软件模块是由相关性很强的代码组成，只负责一项任务，也就是常说的单一责任原则。开发过程中时刻保持这一原则，适当的对类和方法进行重构，提升类和方法的内聚性。

 

3、业务规范：与业务逻辑具体相关的特殊要求，如具体实体类对象的名称和具体业务逻辑的处理方式等。例如一些对性能有严格要求的项目中，在任何一段逻辑处理过程都需要对处理时长进行控制。

• Code Review体系

团队的编码规范约定通常是以文档的形式供团队成员学习，但并不能保证团队成员开发的代码一定符合规范。而Code Review体系则是编码规范有效实施的重要保证。通过Code Review,大家可以对相互监督落实编码规范，同时可以发现潜在的问题，相互交流学习，提升团队整体的开发能力，和大家的团队意识。

每个团队的Code Review机制由团队成员共同制定，不同的团队不尽相同。但其中有几个关键点适用于大多数的团队：

1、每次提交Code Review的代码量在思路完整的情况下越少越好。

2、每次参与Code Review的人数至少要有2人（不包含提交者），但不宜过多，避免盲目通过的情况。

3、通常情况下，每次的Code Review不应该直接通过，平均需要修改至少一次代码。

 

通过Code Review体系，可以在团队中建立起集体认知：

1、代码是团队共有的知识财富，而不是个人的私有地。

2、所有人对所有的代码最终质量负责，而不是某个人对某些代码负责。

3、完成功能只是开始，代码需要持续改进以符合团队的编码规范标准。

 

CodeReview体现的是团队对于代码质量的追求，对于团队内部协作的重视。

〖★ 总 结 ★〗     

代码质量是软件项目内部质量，是软件项目可持续发展的重要保证。应对业务压力时，不应单纯地增加人力来提高产出而忽视了控制代码质量，项目的开发效率仍然会收到低质量代码的影响不断下降。

『通过建立统一的编码规范和Code Review体系能从代码产生的源头上控制代码质量。而代码质量不仅要在源头上进行控制，也需要在持续集成的过程中通过自动化的工具对其进行审核。』使用自动化的代码质量审核工具不仅可以节省大量的人工成本，还可以提升效率，发现一些人工不容易发现的潜在问题。

代码质量自动化审核相关的内容我们将在下一篇文章中进行详述，敬请关注。