停止产生新的质量问题
无论手头的软件过去是如何编写的, 您都应当立即停止向该软件引入新的质量问题.
第 1 步: 安装 Sonarlin
作为开发人员, 请在您最常用的 IDE(如 Eclipse)中安装 Sonarlin(请参见 https://www.sonarlint.org/). 您会惊奇地发现: 当自己在编写代码时, 它会识别出代码中的质量问题, 并给出详细的说明, 进而提供修复的正确方法.
就我个人而言, 我在过去的一年中一直使用着 Sonarlin, 它持续给我指出代码中的各种未被意识到的错误, 让我成长为一名更好的软件开发者.
第 2 步: 在 SonarQube 中建立 Quality Gates
如果您有一个开发团队, 我建议您通过制定一套质量控制策略, 来给每一次提交建立一种检查源代码中质量问题的自动化方法, 以防止任何问题被合并到主线上. 通常, 您可以在 SonarQube(请参见 https://www.sonarqube.org/)中配置 Quality Gates(请参见 https://docs.sonarqube.org/display/SONAR/Quality+Gates), 为不同类型的质量问题设置一个或多个阈值. 例如: 您可以在不引入任何新的关键或重大问题的前提下, 成功提交新的源代码.
时间都去哪儿了?
作为一个开发人员, 您很可能会将大部分的时间花费在阅读代码, 并理清代码的意图上. 在尝试修复 bug 或实现新功能的过程中, 您是否会反复读到相同的代码? 您肯定会认为应当通过重构, 以提高代码的可读性. 但是, 当您面对一个由数千个文件 (例如 Java 的类) 所组成的软件应用时, 又该如何下手进行代码重构呢?
通常情况下, 纵然应用程序由数千个文件所组成, 我们的软件开发活动一般也就集中在有限的某个文件集中. 例如: 对于我所维护的企业级应用程序而言, 虽然它有着一万多个源代码文件, 但是我的开发活动往往只集中在其中的十多个文件上, 它们在每一次提交中都会发生变化.
第 3 步: 只重构频繁变更的文件
通过在自己的代码库里识别那些变更最为频繁的文件, 您会了解到开发人员都将时间不知不觉地花费到了何处. 如果您正在使用 Git 作为自己的版本控制系统, 那么就可以执行以下的命令:
Git log --format=format: --name-only | egrep -v '^$' | sort | uniq -c | sort -r > commits_per_file.txt
该命令将针对您的代码库进行文件列表的排序打印, 其中变更最为频繁的文件 (即具有最高提交次数的) 会被排在最前列, 如下所示:
- Commits File
- 230 gr/kolaxis/Utils.java
- 220 gr/kolaxis/UserManager.java
- 210 gr/kolaxis/UserTemplate.java
根据实际的数据(本例来自版本控制系统), 您可以协同自己的开发团队, 针对哪些需要进行重构的文件做出明智的决定.
只有对代码库中变更最为频繁的文件予以重构, 才能增加它们的易读性, 也就更容易被每一位开发人员所理解. 同时, 有了针对性的代码重构, 开发人员阅读代码的时间花销也会大幅降低, 整个开发团队的生产力同样会得到相应的提升.
第 4 步: 将测试集中在频繁变更的代码上
请不要浪费时间测试那些长时间未曾被修改的成熟代码. 相反, 您应当将重点放在测试频繁变更代码的质量保证环节. 为什么这样说呢? 原因如下:
由于频繁变化, 它们包含了更多的软件缺陷与安全风险, 因此更需要打上各种补丁.
它们一般提供的是用户常用的功能, 因此对于其效果的改进需求会与日俱增.
虽然我们可以通过调整测试套件, 只测试那些频繁变更的代码, 从而节省宝贵的交付时间. 但是开发人员也需要经常扪心自问: 这些频繁变更的代码覆盖率到底是多少?
第 5 步: 不要触摸旧的代码!
当您打开一个长时间未进行更改的源文件时, 不管它有多 "难看", 您都要抵住对它进行重构的诱惑. 旧的源代码已经经受了一段时间的考验, 已经在生产环境中无故障地运行了许久. 因此, 我们没有必要再花费开发的宝贵时间与精力, 对已被证明为正确的成熟代码进行改动, 除非您有非常充分的理由.
我个人认为: 对于旧代码的任意修复, 往往会引入一些意想不到的新 bug. 因此,"存在便是合理", 我们暂且对它们进行搁置. 当然, 凡事也并非绝对, 此处的例外是 "死代码(dead code)". 即: 过去曾经为了开发某个特性而提交过的, 但是从未真正使用过的代码. 因此, 如果您确信某段代码确实没有被调用过, 那么就请删掉它吧! 通过删除 "死代码", 每一位开发人员都会更加容易地去浏览现有的代码库, 同时也能减少软件应用的总体构建时间, 进而节省开发团队宝贵的交付时间.
谁动了我的代码?
对于某个软件应用, 您知道有多少开发人员正工作在给定的组件上吗? 根据微软的研究:"小部分代码贡献者 (minor contributor) 的数量, 与发布前后的失败率, 有着较强的正相关性." 也就是说, 如果有许多开发人员只是偶尔对源代码做出了贡献(增加小段新的程序), 而且每段代码都只有少量的提交(例如低于整体提交的 5%), 那么该组件就很可能会对整体质量造成影响.
相反, 如果某一个开发者对组件执行了大部分的提交工作(甚至可以称他们为组件的所有者), 那么该组件的失败可能性会比较低, 而预计的质量则会比较高.
第 6 步: 关注小部分代码的贡献者
如下图所示, 通过对软件应用中的所有组件逐一识别出小部分代码的贡献者, 进而着重测试他们的代码质量, 以减少软件应用中的 bug.
因此, 主要代码贡献者需要定期审查小部分代码贡献者提交上来的程序; 而小部分代码贡献者则需要在进行程序修改之前, 主动咨询主要代码贡献者.
来源: http://www.tuicool.com/articles/ENvmIvu