全文共2282字，预计学习时长6分钟
图源：
Unsplash摄影：
Clem Onojeghuo
糟糕的代码会引发大问题。
当代码越来越乱，维护时间会无限延长。
而最坏的结果就是，这段代码再也无法维护，整个编程项目也救不活，彻底瘫痪了。
为避免出现这种状况，在编写代码时要注意质量问题，因此您应该在提升代码质量上多花时间。
从长远来看，高质量代码好处多多。
确保代码质量是每个人的义务，无论您是经理，测试员还是开发人员都义不容辞。
因为整个开发过程的目标始终是交付高质量、可运行的代码。
下面列出了提高代码质量的六种方法。
其中几种可以独立完成，而其他更多则需要团队合作。
图源：
https://hackernoon.com
/the-book-every-programmer-should-read-33b5ef2e532a
1. 四眼原则
四眼原则（Four-EyesPrinciple）易理解易操作，它规定代码审查至少需要两个人（包括代码编写者）进行。
当今最流行的一个方法是“pullrequest”。
Pull request能够让你告诉其他人你在GitHub的一个库内特定分支进行的改动。
一旦pull request被开源，您可以与合作伙伴讨论回顾可能的更改内容，并在更改合并到基础分支之前添加后续提交。
—GitHub
审查代码时应考虑几件事。
一是检查代码是否违反了代码规范。
该过程可以通过在管道中使用linter（程序开发中用来检查文体的辅助工具）来自动执行，但有时仍需手动操作。
二是检查代码的可维护性和故障处理，该过程无法自动完成。
最后应检查代码的完整性，旨在检查这段代码的开发预期特征是否已全部完成。
2. 持续集成
“但它在开发服务器上可以运行”。
甚至更糟：
“它在我的电脑上没有问题”。
想要避免这种性质的问题和争论，持续集成（continuousintegration, CI）可以发挥巨大作用。
持续集成是一种软件开发实践，团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。
—马丁·福勒
持续集成的意义在于，它可以迅速为开发人员提供大量反馈。
若您遵循两个简单规则，持续集成就能起作用：
1. 保持快速构建。
耗时一个小时的构建太令人沮丧了。
2. 即刻修复损坏的构建。
持续集成的总目标是，始终能够在已知的稳定基础上进行开发。
持续集成提高了代码质量，因为它可以使开发人员快速得到反馈。
若测试失败，构建也不会成功，同时这一结果会被告知开发者。
此外，在构建脚本中添加linter来检查编码规范也将是提高代码质量的一大方法。
3. 编码规范
列出编码规范很重要。
然而，在操作前，团队成员都应该在同一页面上。
这同大量讨论首选规范一样重要。
列出编码规范，您需要记录变量声明以及命名规范等。
此列表的规范可以按照需要无限制添加，且规范数目可变化。
如果团队愿意，可以随时将新规则添加到此列表中，也可以随时从列表中删除规范。
一旦编码规范已列出，请务必遵守这些规范。
正如前文所言，最可取的方法是在管道中使用linter自动检查编码规范。
如果管道中无该选项，请将linter安装到本地。
只需确保至少在每次提交之前定期使用linter即可。
这样一来，编码统一性增加，代码库的可读性和可维护性也大大提高了。
代码质量高了就可以反复使用，开发人员就不用花费大量时间来修复旧故障和完善代码，长期软件开发的速度也会加快，新人也更容易加入项目。
4. 重视测试
错误越少，代码的质量越高。
全面测试可以检测并纠正关键错误，代码便可以按预期运行。
要提高代码质量，制定清晰的测试策略至关重要。
单元测试是必须进行的，如果有时间进行其他测试，如集成测试或回归测试就更好了。
根据测试金字塔，软件项目中使用最多的是单元测试。
原因是单元测试效率高。
有很多工具可以用来创建单元测试和出具代码覆盖率报告。
图源：
https://blog.octo.com/en/the-test-pyramid-in-practice-5-5/
通过持续集成，可以自动运行测试套件和完成代码覆盖率报告。
若代码覆盖率未达要求，构建可能会失败。
5. 故障分析
代码故障可能是不可避免的，因此处理故障非常重要。
如果想提高开发水平，从故障中学习极为关键。
这就是需要进行故障分析的原因。
出现故障时，首先要分析它带来的影响。
例如：
该故障是低优先级还是高优先级？
若优先级较高，则应立即修复。
分析故障时，需要问自己一些问题：
什么地方出故障？
为什么此前我们没有（正确）测试？
还有什么其他地方出该故障？
最重要的是，我们如何防止再次出现该故障？
当然，您还可以使用工具来追踪故障。
市面上有很多故障追踪器，您可以选一个符合需求的来使用。
不反思学习才是真正的错误。
—亨利·福特
6. 开始度量
度量时可以使用几个指标来量化代码质量。
故障指标
故障数量及其严重程度是整体质量的重要指标。
例如，若要追踪故障，可以使用故障燃尽图。
故障燃尽图的工作原理类似于敏捷软件开发中的正常燃尽图。
唯一的区别是，故障燃尽图包含的是未修复的故障数量，而非用户故事工作量。
复杂度指标
复杂度通常用圈复杂度（cyclomaticcomplexity metric）来衡量。
它是对程序源代码中线性独立路径数量的定量度量。
圈复杂度与故障频率之间存在相关性：
大量研究调查了圈复杂度与在功能或方法中出现的故障频率之间的相关性。
一些研究发现，圈复杂度和故障之间存在正相关关系：
复杂度最高的功能和方法往往也包含最多的故障。
然而，圈复杂度和程序大小（通常以代码行衡量）之间的相关性已被证明了很多次。
— 维基百科
从理论上讲，减少代码的复杂度可以减少故障数目。
推荐阅读专题
留言 点赞 发个朋友圈
我们一起分享AI学习与发展的干货
编译组：郑雨晴、田雨
相关链接：
https://medium.com/better-programming/things-that-you-can-do-to-improve-code-quality-c746c30e7521
如需转载，请后台留言，遵守转载规范
推荐文章阅读
871
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
