二十年前, 当我在汽车行业工作时, 一家工厂的厂长经常说, “我们只有一天时间造一辆车, 但是我们的客户有一辈子的时间来检查它.“质量是最重要的. 事实上, in more mature sectors like the automotive 和 construction industries, quality assurance is a key consideration that is systematically integrated into the product development 过程. 当然这是迫于保险公司的压力, it is also dictated—as that factory director noted—by the resulting product’s lifespan.

说到软件, 然而, shorter life cycles 和 continuous upgrades mean that source code integrity is often overlooked in favor of new features, 复杂的功能, 以及进入市场的速度. 产品 managers often deprioritize source code quality assurance or leave it to developers to h和le, despite the fact that it is one of the more critical factors in determining a product’s fate. For 产品经理s concerned about building a solid foundation 为 product development 和 eliminating risks, defining 和 implementing a systematic assessment of source code quality is essential.

定义“质量”

Be为e exploring the ways to properly evaluate 和 enact a source code 质量保证过程, it’s important to determine what “quality” means in the context of software development. 这是一个 复杂的 这是一个多方面的问题, 但是为了简单起见, we can say quality refers to source code that supports a product’s value proposition without compromising consumer satisfaction or endangering the development company’s business model.

换句话说, quality source code accurately implements the functional specifications of the product, 满足非功能需求, 确保消费者满意, 最大限度地降低安全和法律风险, 并且可以负担得起维护和扩展.

考虑到软件的传播如此广泛和迅速, 软件缺陷的影响可能是显著的. Problems like bugs 和 code 复杂的ity can hurt a company’s bottom line by hindering product adoption 和 increasing software asset management (SAM) costs, while 安全 breaches 和 license 合规 violations can affect company reputation 和 raise legal concerns. 即使软件缺陷没有灾难性的 结果，它们有不可否认的代价. 在2018年 报告, software company Tricentis found that 606 software failures from 314 companies accounted 为 $1.去年损失了7万亿美元的收入. 在刚刚发布的2020年报告中， 方案 将低质量软件的成本放在美国.S. at $2.08万亿美元，另有1万亿美元.未来31万亿美元的技术债务成本. 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, which is in turn exponentially less than resolving the issue after deployment.

处理烫手山芋

尽管存在风险, quality assurance in software development is treated piecemeal 和 is characterized by a reactive approach rather than the proactive one taken in other industries. 源代码质量的所有权是有争议的, when it should be viewed as the collective responsibility of different functions. 产品 managers must view quality as an impactful feature rather than overhead, executives should pay attention to the quality state 和 invest in it, 和 engineering functions should resist treating code-cleaning as a “hot potato.”

Compounding these delegation challenges is the fact that existing methodologies 和 tools fail to address the code quality issue as a whole. The use of continuous integration/continuous delivery methodologies reduces the impact of low-quality code, but unless CI/CD is based on a thorough 和 holistic quality 分析 it cannot effectively anticipate 和 address most hazards. 团队负责 QA测试, App 保护。, 和 license 合规 work in silos using tools that have been designed to solve only one part of the problem 和 evaluate only some of the non-functional or functional requirements.

考虑到产品经理的角色

源代码质量造成了许多困境 产品经理 faces during product design 和 throughout the software development life cycle. Τechnical债务是沉重的开销. It is harder 和更多的 expensive to add 和 modify features on a low-quality codebase, 和 supporting existing code 复杂的ity requires significant investments of time 和 resources that could otherwise be spent on new product development. As 产品经理s continually balance risk against go-to-market speed, 他们必须考虑以下问题:

• Should I use an OSS (open source software) library or build functionality from scratch? What licenses 和 potential liabilities are associated with the selected libraries?
• 哪个技术栈最安全? 这确保了快速和低成本的开发周期?
• Should I prioritize app configurability (high cost/time delay) or implement customized 版本 (high 维护 cost/lack of scalability)?
• How feasible will it be to integrate newly acquired digital products while maintaining high code quality, 尽量减少风险, 保持低工程成本?

The answers to these questions can seriously impact business outcomes 和 the 产品经理’s own reputation, yet decisions are often made based on intuition or past experience rather than rigorous investigation 和 solid metrics. A thorough software quality evaluation 过程 not only provides the data needed 为 decision-making, 同时也使利益相关者保持一致, 建立信任, 并有助于建立透明的文化, 其中的优先事项是明确和一致的.

实施7步流程

A complete source code quality evaluation 过程 结果 in a diagnosis that considers the full set of quality determinations rather than a few isolated symptoms of a larger problem. 下面介绍的七步方法与方案一致 建议 为 过程改进 的目的是促进下列目标:

• 找到、测量并解决问题，接近其根本原因.
• Invest smartly in software quality improvement based on overall quality measurements.
• Attack the problem by analyzing the complete set of measurements 和 identifying the best, 最具成本效益的改进.
• 考虑软件产品的全部成本, 包括拥有成本, 维护, 以及许可证/安全法规的一致性.
• Monitor the code quality throughout the SDLC to prevent unpleasant surprises.

1. 产品-to-code映射: Tracing product features back to their codebase may seem like an obvious first step, 但是考虑到开发复杂性增加的速度, 这并不一定简单. 在某些情况下, 一个产品的代码被分成几个存储库, 而在其他国家, 多个产品共享相同的存储库. Identifying the various locations that house specific parts of a product’s code is necessary be为e further evaluation can take place.

2. 技术栈分析: 这一步 takes into account the various programming languages 和 development tools used, 每个文件的注释百分比, 自动生成代码的百分比, 平均开发成本, 和更多的.

建议的工具: cloc

选择: Tokei, 鳞状细胞癌, sloccount

3. 版本分析: 根据这部分审计的结果, which involves identifying all 版本 of a codebase 和 calculating similarities, 可以合并版本并消除重复. 此步骤可以与a结合使用 故障点(热点) 分析, which identifies the tricky parts of code that are most frequently revised 和 tend to generate higher 维护 costs.

建议的工具: cloc, 鳞状细胞癌, sloccount

4. 自动代码审查: 这种检查探查代码中的缺陷, 编程实践违规, 还有像硬编码令牌这样的危险元素, 长方法, 和重复. The tool(s) selected 为 this 过程 will depend on the 结果 of the 技术堆栈 和 版本 analyses above.

建议的工具: SonarQube, Codacy

选择: 撕裂, Veracode, 微焦点, 该公司，以及其他许多人. 另一个选择是 Sourcegraph，一个通用的代码搜索解决方案.

5. 静态安全性分析: 这一步, 也称为静态应用程序安全测试(SAST), explores 和 identifies potential App 保护。 vulnerabilities. The majority of available tools scan the code against the frequently occurring 安全 concerns identified by organizations such as OWASP 和 无.

建议的工具: WhiteSource, Snyk, Coverity

选择: SonarQube, 洗下, Kiuwan, Veracode

6. 软件组件分析(SCA)/许可证遵从性分析: This review involves identifying the open source libraries linked directly or indirectly to the code, 保护这些库的许可证, 以及与这些许可证相关联的权限.

建议的工具: Snyk, WhiteSource, 黑鸭子

选择: 窝, Sonatype，以及其他

7. 经营风险分析: This final measure involves consolidating the in为mation gathered from the previous steps in order to underst和 the full impact of the source code quality status on the business. The 分析 should result in a comprehensive 报告 that provides stakeholders, 包括产品经理, 项目经理, 工程团队, 和高级管理人员, with the details they need to weigh risks 和 make in为med product decisions.

Although the previous steps in this evaluation 过程 can be automated 和 facilitated via a wide range of open source 和 commercial products, there are no existing tools that support the full seven-step 过程 or the aggregation of its 结果. 因为汇编这些数据是一项冗长而耗时的任务, 它要么随意执行，要么完全跳过, 可能危及开发过程. This is the point at which a thorough software inspection 过程 often falls apart, making this last step arguably the most critical one in the evaluation 过程.

选择合适的工具

Although software quality impacts the product 和 thus the business outcomes, tool selection is generally delegated to the development departments 和 the 结果 can be difficult 为 non-developers to interpret. 产品 managers should be actively involved in selecting tools that ensure a transparent 和 访问质量保证 过程. While specific tools 为 the various steps in the evaluation are suggested above, there are a number of general considerations that should be factored into any tool selection 过程:

• 支持的技术栈: Keep in mind that the majority of available offerings support only a small set of development tools 和 can result in partial or misleading 报告ing.
• 安装简单: 工具 whose installation 过程es are based on 复杂的 scripting may require a significant engineering investment.
• 报告: 应该优先考虑导出详细信息的工具, well-structured 报告s that identify major issues 和 provide 建议 为 fixes.
• 集成: 工具 should be screened 为 easy integration with the other development 和 management tools being used.
• 定价: 工具很少有一个全面的价目表, 因此，仔细考虑所涉及的投资是很重要的. Various pricing models typically take into account things like team headcount, 代码大小, 以及相关的开发工具.
• 部署: When weighing on-premise versus cloud deployment, consider factors like 安全. 例如, if the product being evaluated h和les confidential or sensitive data, 内部部署工具和使用盲审计方法的工具(FOSSID)可能更可取.

让它继续

一旦风险被识别并系统地分析, 产品经理s can make thoughtful decisions around prioritization 和 triage 缺陷 more accurately. Teams could be restructured 和 resources allocated to address the most emergent or prevalent issues. “Showstoppers” like high-risk 违反许可证 would take precedence over lower-severity 缺陷, 和更多的 emphasis would be placed on activities that contribute to the reduction of codebase size 和 复杂的ity.

然而，这不是一个一次性的过程. Measuring 和 monitoring software quality should happen continuously throughout the SDLC. 完整的七步评估应定期进行, with quality improvement ef为ts beginning immediately following each 分析. The faster a new risk point is identified, the cheaper the remedy 和 the more limited the fallout. Making source code quality evaluation central to the product development 过程 focuses teams, 将利益相关者, 降低风险, 和 gives a product its very best chance at success—和 that’s every 产品经理’s business.