源代码 QA：不再只是针对开发人员

二十年前，当我在汽车行业工作时，一家工厂的厂长经常会说，“我们有一天造车，但我们的客户有一辈子的时间来检查它。” 质量是最重要的。 事实上，在汽车和建筑行业等更成熟的行业，质量保证是系统集成到产品开发过程中的关键考虑因素。 虽然这当然是由保险公司的压力推动的，但正如工厂主管所指出的那样，最终产品的使用寿命也决定了这一点。

然而，在软件方面，较短的生命周期和持续升级意味着源代码完整性往往被忽视，而倾向于新特性、复杂功能和上市速度。 产品经理经常不重视源代码质量保证或将其留给开发人员处理，尽管事实上它是决定产品命运的更关键因素之一。 对于关心为产品开发打下坚实基础和消除风险的产品经理来说，定义和实施对源代码质量的系统评估至关重要。

定义“质量”

在探索正确评估和制定源代码 QA 流程的方法之前，重要的是要确定“质量”在软件开发环境中的含义。 这是一个复杂且多方面的问题，但为了简单起见，我们可以说质量是指支持产品价值主张而不影响消费者满意度或危及开发公司业务模式的源代码。

换言之，优质的源代码准确地实现了产品的功能规范，满足了非功能性需求，保证了消费者的满意度，最大限度地降低了安全和法律风险，并且可以负担得起的维护和扩展。

考虑到软件分布的广泛和迅速，软件缺陷的影响可能很大。 错误和代码复杂性等问题可能会阻碍产品采用并增加软件资产管理 (SAM) 成本，从而损害公司的底线，而安全漏洞和许可证合规违规可能会影响公司声誉并引发法律问题。 即使软件缺陷没有造成灾难性的后果，它们也有不可否认的代价。 在 2018 年的一份报告中，软件公司 Tricentis 发现，来自 314 家公司的 606 次软件故障导致上一年的收入损失达到 1.7 万亿美元。 在刚刚发布的 2020 年报告中，CISQ 将美国劣质软件的成本估计为 2.08 万亿美元，另外估计还有 1.31 万亿美元的未来成本来自技术债务。 这些数字可以通过早期干预来减少； 在产品设计期间解决问题的平均成本明显低于在测试期间解决相同问题的成本，而这反过来又比部署后解决问题的成本低得多。

处理热土豆

尽管存在风险，但软件开发中的质量保证是零散的，其特点是采用被动方法，而不是其他行业采用的主动方法。 源代码质量的所有权是有争议的，当它应该被视为不同功能的集体责任时。 产品经理必须将质量视为一种有影响力的特性，而不是开销，管理人员应关注质量状态并对其进行投资，工程职能部门应抵制将代码清理视为“烫手山芋”。

使这些委托挑战更加复杂的是，现有的方法和工具无法从整体上解决代码质量问题。 使用持续集成/持续交付方法可以减少低质量代​​码的影响，但除非 CI/CD 基于彻底和整体的质量分析，否则它无法有效地预测和解决大多数危害。 负责 QA 测试、应用程序安全和许可证合规性的团队使用旨在仅解决问题的一部分并仅评估某些非功能或功能需求的工具在孤岛中工作。

考虑产品经理的角色

源代码质量是产品经理在产品设计和整个软件开发生命周期中面临的众多难题。 技术债务是沉重的开销。 在低质量的代码库上添加和修改功能更加困难和昂贵，并且支持现有代码复杂性需要大量时间和资源投资，否则这些时间和资源可能会花费在新产品开发上。 随着产品经理不断平衡风险与上市速度，他们必须考虑以下问题：

• 我应该使用 OSS（开源软件）库还是从头开始构建功能？ 哪些许可和潜在责任与所选图书馆相关？
• 哪种技术栈最安全？ 哪个确保了快速和低成本的开发周期？
• 我应该优先考虑应用程序的可配置性（高成本/时间延迟）还是实施定制版本（高维护成本/缺乏可扩展性）？
• 在保持高代码质量、最小化风险和保持低工程成本的同时集成新获得的数字产品的可行性如何？

这些问题的答案可能会严重影响业务成果和产品经理自己的声誉，但决策通常是基于直觉或过去的经验，而不是严格的调查和可靠的指标。 一个全面的软件质量评估过程不仅提供决策所需的数据，而且还使利益相关者保持一致，建立信任，并有助于形成一种透明的文化，在这种文化中，优先级是明确的和商定的。

实施 7 步流程

一个完整的源代码质量评估过程会产生一个诊断，该诊断考虑了完整的质量确定集，而不是一个更大问题的几个孤立的症状。 下面介绍的七步方法与 CISQ 的流程改进建议一致，旨在促进以下目标：

• 查找、衡量和解决接近其根本原因的问题。
• 根据整体质量测量，明智地投资于软件质量改进。
• 通过分析完整的测量集并确定最佳、最具成本效益的改进来解决问题。
• 考虑软件产品的全部成本，包括拥有成本、维护成本和许可/安全法规调整成本。
• 监控整个 SDLC 的代码质量，以防止令人不快的意外。

1. 产品到代码的映射：将产品功能追溯到其代码库似乎是显而易见的第一步，但考虑到开发复杂性增加的速度，这并不一定简单。 在某些情况下，一个产品的代码被划分在多个存储库中，而在其他情况下，多个产品共享同一个存储库。 在进行进一步评估之前，有必要确定包含产品代码特定部分的各个位置。

2. 技术栈分析：这一步考虑了使用的各种编程语言和开发工具、每个文件的注释百分比、自动生成代码的百分比、平均开发成本等。

推荐工具：cloc

替代品：Tokei、scc、sloccount

3. 版本分析：根据这部分审计的结果，包括识别代码库的所有版本并计算相似性，可以合并版本并消除重复。 此步骤可以与 bugspots（热点）分析结合使用，该分析可以识别代码中最常被修改且往往会产生更高维护成本的棘手部分。

推荐工具：cloc、scc、sloccount

4. 自动代码审查：这种检查会探测代码中的缺陷、违反编程实践的情况以及硬编码令牌、长方法和重复等风险元素。 为此过程选择的工具将取决于上述技术堆栈和版本分析的结果。

推荐工具：SonarQube、Codacy

替代方案：RIPS、Veracode、Micro Focus、Parasoft 等。 另一种选择是 Sourcegraph，一种通用代码搜索解决方案。

5. 静态安全分析：这一步也称为静态应用安全测试（SAST），探索和识别潜在的应用安全漏洞。 大多数可用工具针对 OWASP 和 SANS 等组织发现的经常发生的安全问题扫描代码。

推荐工具：WhiteSource、Snyk、Coverity

替代方案：SonarQube、Reshift、Kiuwan、Veracode

6. 软件组件分析 (SCA)/许可证合规性分析：此审查涉及识别直接或间接链接到代码的开源库、保护每个库的许可证以及与每个许可证相关的权限。

推荐工具：Snyk、WhiteSource、Black Duck

替代品：FOSSA、Sonatype 等

7. 业务风险分析：此最终措施涉及整合从前面步骤收集的信息，以了解源代码质量状态对业务的全面影响。 分析应生成一份综合报告，为利益相关者（包括产品经理、项目经理、工程团队和最高层主管）提供他们权衡风险和做出明智产品决策所需的详细信息。

尽管此评估过程中的先前步骤可以通过广泛的开源和商业产品实现自动化和便利化，但没有现有的工具可以支持完整的七步过程或其结果的聚合。 由于这些数据的编译是一项繁琐且耗时的任务，因此要么随意执行，要么完全跳过，可能会危及开发过程。 这是一个彻底的软件检查过程经常崩溃的点，这使得这最后一步可以说是评估过程中最关键的一步。

选择正确的工具

尽管软件质量会影响产品并因此影响业务成果，但工具选择通常委托给开发部门，非开发人员可能难以解释结果。 产品经理应积极参与选择确保透明和可访问的 QA 流程的工具。 虽然上面建议了评估中各个步骤的具体工具，但在任何工具选择过程中都应考虑一些一般性考虑因素：

• 支持的技术堆栈：请记住，大多数可用产品仅支持一小部分开发工具，并可能导致部分或误导性报告。
• 安装简单：安装过程基于复杂脚本的工具可能需要大量的工程投资。
• 报告：应优先使用能够导出详细、结构良好的报告的工具，这些报告可以识别主要问题并提供修复建议。
• 集成：应筛选工具，以便与正在使用的其他开发和管理工具轻松集成。
• 定价：工具很少附带全面的价目表，因此仔细考虑所涉及的投资非常重要。 各种定价模型通常会考虑团队人数、代码大小和所涉及的开发工具等因素。
• 部署：在权衡内部部署与云部署时，请考虑安全性等因素。 例如，如果被评估的产品处理机密或敏感数据，则本地工具和使用盲审方法 (FOSSID) 的工具可能更可取。

保持下去

一旦有条不紊地识别和分析了风险，产品经理就可以围绕优先级和更准确地分类缺陷做出深思熟虑的决策。 可以重组团队并分配资源以解决最紧急或普遍的问题。 诸如高风险许可证违规之类的“搅局者”将优先于低严重性缺陷，并且将更加重视有助于减少代码库大小和复杂性的活动。

然而，这不是一个一次性的过程。 测量和监控软件质量应该在整个 SDLC 中持续进行。 应定期进行完整的七步评估，每次分析后立即开始质量改进工作。 识别新风险点的速度越快，补救措施就越便宜，影响也就越有限。 将源代码质量评估作为产品开发过程的核心，使团队能够集中注意力、协调利益相关者、降低风险并为产品提供最大的成功机会——这是每个产品经理的工作。