Twenty years ago, when I worked in the automotive industry, the director of one factory would often say, “We have one day to build a car, but our customer has a lifetime to inspect it.” Quality was of the utmost importance. Indeed, 在更成熟的行业，如汽车和建筑行业, 质量保证是系统地集成到产品开发过程中的关键考虑因素. While this is certainly driven by pressure from insurance companies, 正如那位厂长所指出的，这也是由最终产品的寿命决定的.

When it comes to software, however, 更短的生命周期和持续的升级意味着源代码的完整性经常被忽视，而被新特性所取代, sophisticated functionality, and go-to-market speed. 产品经理通常会降低源代码质量保证的优先级，或者将其留给开发人员处理, 尽管它是决定产品命运的关键因素之一. 对于产品经理来说，他们关心的是为产品开发和消除风险建立一个坚实的基础, 定义和实现对源代码质量的系统评估是必要的.

Defining “Quality”

在探索正确评估和制定源代码的方法之前 QA process在软件开发的上下文中，确定“质量”的含义是很重要的. This is a complex and multifaceted issue, but for the sake of simplicity, 我们可以说，质量指的是支持产品价值主张的源代码，而不会损害消费者满意度或危及开发公司的业务模型.

In other words, 高质量的源代码准确地实现了产品的功能规格, satisfies the non-functional requirements, ensures consumers’ satisfaction, minimizes security and legal risks, and can be affordably maintained and extended.

Given how widely and quickly software is distributed, the impact of software defects can be significant. bug和代码复杂性等问题会阻碍产品采用，增加软件资产管理(SAM)成本，从而损害公司的底线, 而安全漏洞和许可证遵从性违规可能会影响公司声誉并引发法律问题. Even when software defects don’t have catastrophic results, they have an undeniable cost. In a 2018 report美国软件公司Tricentis发现，来自314家公司的606个软件故障造成了1美元的损失.7 trillion in lost revenue the previous year. In a just-released 2020 report, CISQ put the cost of poor quality software in the U.S. at $2.08 trillion, with another estimated $1.31 trillion in future costs incurred through technical debt. These numbers could be mitigated with earlier interventions; the average cost of resolving an issue during product design is significantly lower than resolving the same issue during testing, 这反过来又比在部署后解决问题要少得多.

Handling the Hot Potato

Despite the risks, 软件开发中的质量保证是零敲碎打的，其特点是采用被动的方法，而不是其他行业采用的主动方法. The ownership of source code quality is contested, 当它应被视为不同职能的集体责任. 产品经理必须将质量视为有影响的特性，而不是开销, executives should pay attention to the quality state and invest in it, 工程功能应该抵制将代码清理视为“烫手山芋”.”

使这些委托挑战更加复杂的是，现有的方法和工具无法从整体上解决代码质量问题. 持续集成/持续交付方法的使用减少了低质量代码的影响, 但是，除非CI/CD是基于彻底和全面的质量分析，否则它不能有效地预测和解决大多数危害. Teams responsible for QA testing, application security, 许可证遵从性在竖井中工作，使用的工具被设计为只解决问题的一部分，并且只评估一些非功能性或功能性需求.

Considering the Product Manager’s Role

Source code quality plays into numerous dilemmas a product manager 在产品设计和整个软件开发生命周期中的面孔. Τechnical debt is heavy overhead. 在低质量的代码库上添加和修改特性更加困难和昂贵, 支持现有代码的复杂性需要大量的时间和资源的投资，否则这些时间和资源将被花费在新产品开发上. 随着产品经理不断地平衡风险和上市速度, they must consider questions like:

• 我应该使用OSS(开源软件)库还是从头开始构建功能? 与所选库相关的许可和潜在责任是什么?
• Which tech stack is safest? Which ensures a fast and low-cost development cycle?
• 我应该优先考虑应用程序的可配置性(高成本/时间延迟)还是执行定制版本(高维护成本/缺乏可扩展性)?
• 在保持高代码质量的同时集成新获得的数字产品有多可行, minimizing risks, and keeping engineering costs low?

这些问题的答案会严重影响业务成果和产品经理自己的声誉, 然而，决策往往是基于直觉或过去的经验，而不是严格的调查和可靠的指标. 全面的软件质量评估过程不仅提供决策所需的数据, but also aligns stakeholders, builds trust, and contributes to a culture of transparency, in which priorities are clear and agreed-upon.

Implementing a 7-Step Process

完整的源代码质量评估过程会产生一种诊断，该诊断考虑了全套质量确定因素，而不是一个更大问题的一些孤立症状. The seven-step method presented below is aligned with CISQ’s recommendations for process improvement and is meant to facilitate the following objectives:

• Find, measure, and fix the problem close to its root cause.
• 明智地投资于基于整体质量度量的软件质量改进.
• 通过分析完整的测量集并确定最佳方法来解决问题, most cost-effective improvements.
• Consider the complete cost of a software product, including the costs of ownership, maintenance, and license/security regulation alignment.
• 在整个SDLC中监控代码质量，以防止不愉快的意外.

1. Product-to-code mapping: 将产品特性追溯到它们的代码库似乎是显而易见的第一步, but given the rate at which development complexity increases, it is not necessarily simple. In some situations, a product’s code is divided among several repositories, while in others, multiple products share the same repository. 在进行进一步的评估之前，有必要确定存放产品代码特定部分的各种位置.

2. Tech stack analysis: 这一步考虑到使用的各种编程语言和开发工具, the percentage of comments per file, the percentage of auto-generated code, the average development cost, and more.

Suggested tools: cloc

Alternatives: Tokei, scc, sloccount

3. Versions analysis: Based on the results of this portion of the audit, 这涉及到识别代码库的所有版本并计算相似度, versions can be merged and duplications eliminated. This step can be combined with a bugspots (hot spots) analysis, 哪一种方法可以识别出代码中最频繁修改的棘手部分，这些部分往往会产生更高的维护成本.

Suggested tools: cloc, scc, sloccount

4. Automated code review: This inspection probes the code for defects, programming practice violations, and risky elements like hard-coded tokens, long methods, and duplications. 为此过程选择的工具将取决于上述技术堆栈和版本分析的结果.

Suggested tools: SonarQube, Codacy

Alternatives: RIPS, Veracode, Micro Focus, Parasoft, and many others. Another option is Sourcegraph, a universal code search solution.

5. Static security analysis: This step, also known as static application security testing (SAST), 探索并识别潜在的应用程序安全漏洞. 大多数可用的工具扫描代码，以确定经常发生的安全问题，如组织 OWASP and SANS.

Suggested tools: WhiteSource, Snyk, Coverity

Alternatives: SonarQube, Reshift, Kiuwan, Veracode

6. Software components analysis (SCA)/License compliance analysis: 这个审查包括识别直接或间接链接到代码的开放源代码库, the licenses that protect each of these libraries, and the permissions associated with each of these licenses.

Suggested tools: Snyk, WhiteSource, Black Duck

Alternatives: FOSSA, Sonatype, and others

7. Business risk analysis: 这个最后的度量包括巩固从前面步骤中收集到的信息，以便理解源代码质量状态对业务的全面影响. 分析的结果应该是一个全面的报告，为利益相关者提供, including product managers, project managers, engineering teams, and C-suite executives, 有了这些细节，他们就可以权衡风险，做出明智的产品决策.

尽管这个评估过程中的前面步骤可以通过广泛的开源和商业产品自动化和简化, 目前还没有支持完整的七步流程或其结果聚合的工具. Because compilation of this data is a tedious and time-consuming task, it is either performed haphazardly or skipped entirely, potentially jeopardizing the development process. 这是一个彻底的软件检查过程经常崩溃的地方, 最后一步可以说是评估过程中最关键的一步.

Selecting the Right Tools

尽管软件质量影响产品，从而影响业务结果, 工具选择通常委托给开发部门，非开发人员很难解释结果. 产品经理应该积极参与选择工具，以确保透明和有效 accessible QA process. 虽然上面建议了评估中各个步骤的具体工具, 在任何工具选择过程中，都应该考虑一些一般的考虑因素:

• Supported tech stack: 请记住，大多数可用的产品只支持一小部分开发工具，并可能导致部分或误导性的报告.
• Installation simplicity: 安装过程基于复杂脚本的工具可能需要大量的工程投资.
• Reporting: Preference should be given to tools that export detailed, 结构良好的报告，确定主要问题并提供修复建议.
• Integration: 应该筛选工具，以便与正在使用的其他开发和管理工具轻松集成.
• Pricing: Tools rarely come with a comprehensive price list, so it is important to carefully consider the investment involved. 不同的定价模式通常会考虑团队人数等因素, code size, and the development tools involved.
• Deployment: 在权衡内部部署与云部署时，要考虑安全性等因素. For example, if the product being evaluated handles confidential or sensitive data, on-prem tools and tools using the blind-audit approach (FOSSID) may be preferable.

Keeping It Going

Once risks have been identified and analyzed methodically, 产品经理可以围绕优先级做出深思熟虑的决定，并更准确地对缺陷进行分类. 可以重组团队，分配资源以解决最紧急或最普遍的问题. 像高风险许可证违规这样的“大麻烦”将优先于较低严重性的缺陷, 更多的重点将放在有助于减少代码库大小和复杂性的活动上.

This is not a one-time process, however. 测量和监视软件质量应该在整个SDLC中持续进行. The full seven-step evaluation should be conducted periodically, 质量改进工作在每次分析之后立即开始. 发现新的风险点越快，补救措施就越便宜，影响也就越有限. 使源代码质量评估成为产品开发过程的中心，使团队关注, aligns stakeholders, mitigates risks, 给产品最好的成功机会——这是每个产品经理的职责.