二十年前, 当我在汽车行业工作时, 一家工厂的厂长经常说, “我们只有一天时间造一辆车, 但是我们的客户有一辈子的时间来检查它.“质量是最重要的. 事实上, 在更成熟的行业，如汽车和建筑行业, 质量保证是系统地集成到产品开发过程中的关键考虑因素. 当然这是迫于保险公司的压力, 正如那位厂长所指出的，这也是由最终产品的寿命决定的.
说到软件, 然而, 更短的生命周期和持续的升级意味着源代码的完整性经常被忽视，而被新特性所取代, 复杂的功能, 以及进入市场的速度. 产品经理通常会降低源代码质量保证的优先级，或者将其留给开发人员处理, 尽管它是决定产品命运的关键因素之一. 对于产品经理来说，他们关心的是为产品开发和消除风险建立一个坚实的基础, 定义和实现对源代码质量的系统评估是必要的.
在探索正确评估和制定源代码的方法之前 质量保证过程在软件开发的上下文中，确定“质量”的含义是很重要的. 这是一个 复杂的 这是一个多方面的问题, 但是为了简单起见, 我们可以说，质量指的是支持产品价值主张的源代码，而不会损害消费者满意度或危及开发公司的业务模型.
换句话说, 高质量的源代码准确地实现了产品的功能规格, 满足非功能需求, 确保消费者满意, 最大限度地降低安全和法律风险, 并且可以负担得起维护和扩展.
考虑到软件的传播如此广泛和迅速, 软件缺陷的影响可能是显著的. bug和代码复杂性等问题会阻碍产品采用，增加软件资产管理(SAM)成本，从而损害公司的底线, 而安全漏洞和许可证遵从性违规可能会影响公司声誉并引发法律问题. 即使软件缺陷没有灾难性的 结果，它们有不可否认的代价. 在2018年 报告美国软件公司Tricentis发现，来自314家公司的606个软件故障造成了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, 这反过来又比在部署后解决问题要少得多.
尽管存在风险, 软件开发中的质量保证是零敲碎打的，其特点是采用被动的方法，而不是其他行业采用的主动方法. 源代码质量的所有权是有争议的, 当它应被视为不同职能的集体责任. 产品经理必须将质量视为有影响的特性，而不是开销, 管理者应该关注质量状态并投入其中, 工程功能应该抵制将代码清理视为“烫手山芋”.”
使这些委托挑战更加复杂的是，现有的方法和工具无法从整体上解决代码质量问题. 持续集成/持续交付方法的使用减少了低质量代码的影响, 但是，除非CI/CD是基于彻底和全面的质量分析，否则它不能有效地预测和解决大多数危害. 团队负责 QA测试, App 保护。, 许可证遵从性在竖井中工作，使用的工具被设计为只解决问题的一部分，并且只评估一些非功能性或功能性需求.
源代码质量造成了许多困境 产品经理 在产品设计和整个软件开发生命周期中的面孔. Τechnical债务是沉重的开销. 在低质量的代码库上添加和修改特性更加困难和昂贵, 支持现有代码的复杂性需要大量的时间和资源的投资，否则这些时间和资源将被花费在新产品开发上. 随着产品经理不断地平衡风险和上市速度, 他们必须考虑以下问题:
这些问题的答案会严重影响业务成果和产品经理自己的声誉, 然而，决策往往是基于直觉或过去的经验，而不是严格的调查和可靠的指标. 全面的软件质量评估过程不仅提供决策所需的数据, 同时也使利益相关者保持一致, 建立信任, 并有助于建立透明的文化, 其中的优先事项是明确和一致的.
完整的源代码质量评估过程会产生一种诊断，该诊断考虑了全套质量确定因素，而不是一个更大问题的一些孤立症状. 下面介绍的七步方法与方案一致 建议 为 过程改进 的目的是促进下列目标:
1. 产品-to-code映射: 将产品特性追溯到它们的代码库似乎是显而易见的第一步, 但是考虑到开发复杂性增加的速度, 这并不一定简单. 在某些情况下, 一个产品的代码被分成几个存储库, 而在其他国家, 多个产品共享相同的存储库. 在进行进一步的评估之前，有必要确定存放产品代码特定部分的各种位置.
2. 技术栈分析: 这一步考虑到使用的各种编程语言和开发工具, 每个文件的注释百分比, 自动生成代码的百分比, 平均开发成本, 和更多的.
建议的工具: cloc
3. 版本分析: 根据这部分审计的结果, 这涉及到识别代码库的所有版本并计算相似度, 可以合并版本并消除重复. 此步骤可以与a结合使用 故障点(热点) 分析, 哪一种方法可以识别出代码中最频繁修改的棘手部分，这些部分往往会产生更高的维护成本.
4. 自动代码审查: 这种检查探查代码中的缺陷, 编程实践违规, 还有像硬编码令牌这样的危险元素, 长方法, 和重复. 为此过程选择的工具将取决于上述技术堆栈和版本分析的结果.
选择: 撕裂, Veracode, 微焦点, 该公司，以及其他许多人. 另一个选择是 Sourcegraph，一个通用的代码搜索解决方案.
5. 静态安全性分析: 这一步, 也称为静态应用程序安全测试(SAST), 探索并识别潜在的应用程序安全漏洞. 大多数可用的工具扫描代码，以确定经常发生的安全问题，如组织 OWASP 和 无.
建议的工具: WhiteSource, Snyk, Coverity
选择: SonarQube, 洗下, Kiuwan, Veracode
6. 软件组件分析(SCA)/许可证遵从性分析: 这个审查包括识别直接或间接链接到代码的开放源代码库, 保护这些库的许可证, 以及与这些许可证相关联的权限.
建议的工具: Snyk, WhiteSource, 黑鸭子
7. 经营风险分析: 这个最后的度量包括巩固从前面步骤中收集到的信息，以便理解源代码质量状态对业务的全面影响. 分析的结果应该是一个全面的报告，为利益相关者提供, 包括产品经理, 项目经理, 工程团队, 和高级管理人员, 有了这些细节，他们就可以权衡风险，做出明智的产品决策.
尽管这个评估过程中的前面步骤可以通过广泛的开源和商业产品自动化和简化, 目前还没有支持完整的七步流程或其结果聚合的工具. 因为汇编这些数据是一项冗长而耗时的任务, 它要么随意执行，要么完全跳过, 可能危及开发过程. 这是一个彻底的软件检查过程经常崩溃的地方, 最后一步可以说是评估过程中最关键的一步.
尽管软件质量影响产品，从而影响业务结果, 工具选择通常委托给开发部门，非开发人员很难解释结果. 产品经理应该积极参与选择工具，以确保透明和有效 访问质量保证 过程. 虽然上面建议了评估中各个步骤的具体工具, 在任何工具选择过程中，都应该考虑一些一般的考虑因素:
一旦风险被识别并系统地分析, 产品经理可以围绕优先级做出深思熟虑的决定，并更准确地对缺陷进行分类. 可以重组团队，分配资源以解决最紧急或最普遍的问题. 像高风险许可证违规这样的“大麻烦”将优先于较低严重性的缺陷, 更多的重点将放在有助于减少代码库大小和复杂性的活动上.
然而，这不是一个一次性的过程. 测量和监视软件质量应该在整个SDLC中持续进行. 完整的七步评估应定期进行, 质量改进工作在每次分析之后立即开始. 发现新的风险点越快，补救措施就越便宜，影响也就越有限. 使源代码质量评估成为产品开发过程的中心，使团队关注, 将利益相关者, 降低风险, 给产品最好的成功机会——这是每个产品经理的职责.
保证质量, 代码QA过程必须考虑以下所有方面:功能稳定性, 可靠性, 表演。, 安全, 合规, 可维护性, 和可转移性.
定期的代码审查使团队能够识别技术债务, bug和缺陷, 安全风险, 在违反许可证对产品或业务构成重大威胁之前予以处罚.
一个好的代码审查使用工具组合来检查存储库, 技术堆栈, 版本, 缺陷, 安全风险, 违反许可证, 商业风险.
作者都是各自领域经过审查的专家，并撰写他们有经验的主题. 我们所有的内容都经过同行评审，并由同一领域的Toptal专家验证.