代码质量与安全 | 边写边清洁，毫不费力就能提高代码质量
第一次分析遗留项目——这里指的是任何超过两个月的项目——结果会让人感到非常压抑。可能会有成千上万个代码异味、数百个bug、高度重复的代码，以及0%的代码覆盖率（取决于项目的年限和技术）。对于这样的结果，通常会引发恐惧、悲伤甚至绝望的情绪。然后问题就来了——我从哪里开始？选择哪些问题进行修复？是先修复错误、漏洞、测试覆盖率，还是应该从所有的障碍开始逐步解决？
人们往往迅速地开启解决问题模式，以至于很难让他们明白这一切其实不是必需的。
把过去的问题抛在脑后
“编程的第一条规则：如果它能运行，就别碰它。”
如果你没这么做过，至少也笑过这句话。而这个笑话是有一定道理的。只是为了解决技术债务就深入研究旧代码，会带来功能退化的风险。而且现实情况是，很少有开发人员有足够的资源（时间、预算、业务的重新测试等）来处理“正常工作”的代码中的问题。所以，让我们暂时把旧代码放在一边（等下会继续谈论它），专注在新代码上。作为开发人员，你要对新代码负责。每一次键入都属于你，你可以确保它符合你自己的高标准。作为开发人员，你负责新代码，更具体地说，你负责新代码的质量。
个人责任，而不是英雄主义
就是说，与其在多年未触及的代码中寻找问题，不如集中精力来确保正常业务过程中接触的代码（处理功能请求和修复用户报告的错误）是干净的。代码中的旧问题无论如何都会被修复，不会添加新问题，重复的部分会被清理，如果不存在重复，你可以编写测试。就是这样。你要做的就是你想做的事：确保今天写的代码是高质量的。
专注于业务人员希望您接触的代码，而不是随意挖掘旧的问题，可以让您专注于完成工作。这意味着个人以及团队的工作效率都会更高。
跨语言、项目和整个组织的一致标准
“但是我处理的是一个使用‘非常古老的语言’的传统项目！” 你可能会说。没问题。无论使用何种语言，工具都是相同的。所以，你只需要和使用热门新语言工作的同事们遵循一样的标准：把你今天所写的代码处理好。这样，不管项目有多么古老或粗糙，都没关系。无论语言、项目的年限或现有技术债务如何，每个人都可以保持他们的新代码足够干净。
帮助完成工作的工具
我知道你要说：“好，但我该怎么做呢？”别担心，SonarQube为您提供了多种工具。首先是问题自动分配——没有人需要对别人的代码负责。如果你确实添加了新问题，它们将自动分配给你，您的同事也是如此。这样没有人需要帮助其他人进行清理工作。当然，这也适用于SonarQube发现的任何旧问题，就像它发现的新问题一样，因此，如果您查看“问题”页面上的“我的问题”过滤器，默认情况下，您将看到旧问题和新问题。这就是为什么工具箱里还有很多其他工具的原因。
最重要的工具是一个以新代码期为重点的质量门限。内置的质量门限只使用“新代码”上的条件。这意味着内置的发布能力指标只关注你最近更改的代码质量。还有项目主页，强调了那些新代码期的值。然后，如果你单击“新代码期”值或“质量门限”条件，你所看到的内容会自动预过滤，只显示新代码中的问题。
当然，还有PR分析（仅商业版本）和IDE中包括的SonarLint等功能，这样就能确保新的问题从一开始就不会被提交或合并进来。
技术债务补救：一切照旧的副作用
“可是那些旧的Blocker Bugs呢？！”我听到你在问。
之前我说过开发人员负责新代码，更具体地说是新代码的质量。我遗漏了一点，就是管理人员负责旧代码的质量。请记住，开发人员没有影响力来获取处理旧代码的资源，而管理人员可以。
这是有道理的，因为管理人员承担了在生产中出现这些旧问题的业务风险，并且，他们也承担着主动修复没有人投诉的代码的业务风险，这可能会在修复过程中破坏其他内容。因此，是否需要解决旧代码中的问题是一个业务决策，由管理层来确定处理旧代码工作的优先级。
但即使不处理这些问题，即使没有主动进行清理，代码库也会逐渐得到清理。在正常的业务过程中，当你接触旧代码并进行新更改时，经常修改的代码区域将会迅速修复。这样，将来对这些高流量区域的维护将更加容易、代价更小，而且避免了许多痛苦。流量较少的代码区域清理的速度会缓慢一些，但不受用户请求的影响意味着它们不那么关键，可以等待。
现在就开始清理！
就是这样。只要确保你的新代码是干净的，这样明天发布到生产环境中的代码至少与今天的代码一样好，甚至可能更好！SonarQube为你提供了实现这一目标所需的所有工具。你只需要开始行动。
文章来源：https://www.sonarsource.com/blog/clean-as-you-code/
立即尝试“边写边清洁”解决方案，请联系SonarQube中国官方授权合作伙伴——创实 ，我们提供SonarQube产品的咨询、销售、实施、培训及技术支持服务。