想要做好代码质量，如何破局？

作者：苗现方

想要做好代码质量，我们不得不提什么是代码质量？本文中讨论的代码质量一般是指代码的风格、重复率和复杂度等，代码是技术团队的价值产物，是宝贵的财富，同样代码质量的好坏可以直接体现出团队的重视程度和技术管理水平。

代码质量的下降是内在原因，通常会恶性循环，主要表现出以下两个特性：

感染性：坏代码总能在部门渲染着只要业务交付达成，代码质量不重要的负面气氛，严重减低了研发人员的技术热情，破坏工作氛围，导致更多的坏代码出现。

心理暗示性：在坏代码基础上继续生产坏代码的"罪过"减轻。

为什么会产生这样的结果，这里我与你举个生活中的栗子，我在上个周日收拾房间，发现一个房间衣柜中的衣服很乱，花了很长时间才叠放好，过两天晚上下班回家，我发现客厅沙发上也很乱，衣服、电脑、背包、零食几乎日常的小物件都会有，两件事情合在一起想，这确实是一个很有趣的思考，为什么会是这样的？在一个相对封闭的空间中，任其无意识地随着时间的发展，房间和沙发也一定很乱，注意，这里我说的是无意识，也就是我并没有刻意放，或者去刻意整理。带着这个思考的结果，我又观察了大家的工位、园区内景观，一段时间内一定会出现乱象，不过通过一顿治理之后很快恢复到有秩序，好，大家可以猜到这是什么定律，就是熵增定律，不了解的可以自行网络科普，那么在质量域中依然存在这样的定律，不然熵增定律也不会被古今中外的物理学家所推崇备至，它的定义是：在一个孤立系统里，如果没有外力做功，其总混乱度（即熵）会不断增大。

代码质量在软件项目是一种有序的状态，自然总是向着无序发展的，要想保持这种有序，需要主动投入资源，就像整理房间，花草修剪一样。

回到我们的多数开发工作中，我们面临的现状是这样的：

1、业务交付压力大，需求优先上线，业务逻辑实现优先级最高，没时间没精力关注代码质量，甚至终极目标就是需求上线，导致坏代码产生，开发效率逐步下降，随着后续版本的迭代，业务交付压力越来越大。

2、出现了1的情况后，我们意识到压力越来越大，为了应付这种交付压力，常见的手段就是增加人力，但是一味的增加人数，沟通成本及风格的一致性无法得到保障，这将进一步产生更多的坏代码。

针对以上2个现状，我们该怎么着手解决。

我的建议方案是多渠道，系统性解决问题，首先控制人力的大量投入，主动发起对代码质量进行管控，其次持续提升技术升级。但是，从减轻业务交付压力的结果来看，人们往往倾向于增加人力来快速解决问题，技术升级需要靠长期的投入才能有所收获，所以，我们需要在质量方面增加强有力的管控。

如果做好代码质量管控？

代码质量管控首先应解决两个问题，库存坏代码和增量坏代码。

想解决这两个问题，我们要对现有的系统、人员、工具、流程整合形成一套体系化的方案。


对代码质量管控，通过在部门内工程实践，我认为需要经历以下这四个过程，部门内建立代码规范制度（EOS）、检查代码问题的自动化工具（bamboo平台）、代码质量检查与代码流动过程绑定（质量门禁）、部门视角下，集中管理代码规范和质量状况的透明（代码质量评测系统）。

过程一：代码质量的基础是规范，包括代码风格的规范、长期一线代码实践规范、与业务需求相关的特殊规范，例如风控文案、异常托底文案等。

过程二：实现自动化的检查能力是在规范基础之上，通过自动化工具进行检查，包括对代码重复率、圈复杂度、单测case通过率、静态规则扫描等。

过程三：实现质量检查与代码流动过程绑定，在编辑-构建-提交-发布各个时段部署检查能力保障上线代码必须经过机器和人工的多环节检查。

过程四：团队规模逐步扩大，各业务线项目快速发展，实现规范管理统一、项目要求一致、各项目质量状况透明、对比，建立统一的评测体系。

为了让你有一个很直观的认识，我在下面画了一个张图，希望可以帮助快速理解。


总结：

在日常开发工作中，大家都会想到通过增加人手来缓解项目交付的压力，这是可以理解，但是从整体角度看，人员的增加会产生越来越多的坏代码，使整体的效率下降，这又进而加剧了后续项目交付的压力，在这种压力下，又通过增加人手缓解......让代码质量变的越来越差，这也是房间为什么会越来越乱，是熵增定律在软件质量域的生动体现。

为了抑制这种恶性循环，我们意识到了通过有效的手段和资源投入进行各项工程实践，逐步完善代码质量的管控体系，积累很多方法和工具。

目前，我也在积极探索对统一代码质量评测体系的实践，希望逐步建立一套中心化的代码质量评测系统，在这个系统中让工匠精神、专家文化借住平台进一步传播、让系统的质量更加透明。