如何构建高质量软件：一个被忽略的课题 [译] | 宝玉的分享

by Florian Bellmann

你是否曾在一个软件项目中发现缺少关键的质量保证（QA）措施？这种情况其实在很多公司和项目中都普遍存在。很多人虽然知道有质量保证这个环节，也明白我们应该去实施它，但所有的努力往往都集中在产品发布前的那一轮紧张的 QA 冲刺中。这种压力巨大的时刻，往往只能保证软件勉强能用。而且，这种混乱在下一次的发布周期中又会重演，而且毫无改善。

大学教给你的

谈到大学教育，如果你学习计算机科学，你会发现课程并没有教授如何确保软件的质量标准。大部分时间都在学习算法、计算机的工作原理、一些编程语言和概念的历史等等。至少在我的学习经历中，还包括了一个学期关于项目管理和敏捷开发的内容。这些知识固然重要，但却完全没有涉及 QA。这是非常遗憾的，因为超过 90% 的计算机专业学生毕业后都会在公司里工作，而在这些环境中，按时交付没有缺陷的软件是非常必要的。

公司如何勉强按时交付

我已经见过太多次了：在项目预算紧张的情况下，质量保证（QA）标准和措施往往是最先被牺牲的。这些措施通常被安排在项目的最后阶段，但如果开发耗时过长（这种情况很常见）或者出现需求膨胀（几乎总是会发生），那么就没有剩余的时间来进行 QA 了。结果，我们只能进行最基本的非结构化测试，然后上线一个结构脆弱的数字产品。

在一些公司或团队中，确实存在一些 QA 标准。这通常是由团队中的资深成员来强制执行。他们很可能已经深刻体会到，没有 QA 的话，后续的工作会变得极为困难。遗憾的是，即使存在这些标准，也并不足以确保质量。这些团队经常只是为了满足项目管理的指标而编写测试，而不是真正关注质量。

如何打破日复一日的工作循环

我花了好几年的时间积累经验和信心，才敢在项目中指出缺失的 QA（质量保证）措施。我与管理层争论、在产品发布的紧张时刻苦苦挣扎、处理生产系统的故障，还要四处寻找缺失的监控措施。这些经历并不愉快。对于代码库或项目的其他改进，比如重构，情况也差不多，因为这些对管理者来说并不直观。但对 QA 来说，挑战尤为巨大，因为如果我们从未实施过任何措施，我们也就无法学会正确的方法。

当你的单元测试通过了，但集成测试失败时的情景。

只有持续提出问题，反复引发讨论，我们才能找到跳出这个无尽循环的第一步。

讨论金钱的重要性

我后来意识到，我之前的论点并不够有效。向那些不直接参与代码工作的人解释软件“更稳定”或“维护更容易”这些观点，对他们来说太抽象了。我们需要谈论的是金钱。作为开发者，我们需要讨论不进行 QA 所带来的成本。这是商业和管理层更通用的语言。现在，我总是试图用类似这样的例子来说明 QA 措施的重要性：‘如果我们现在不这样做，4 个月后的开发工作（以及相关成本）将增加 15%。’或者‘我们需要为所有功能实现单元测试，否则我们的发布稳定化阶段会越来越长。这与我们构建的每个功能直接相关，因为我们需要每次手动测试所有的副作用。这将导致我们在每次发布时取得的进展越来越少。’

根据我的经验，这种观点的转变有助于更清晰地传达问题的核心。最终，你的努力将让每个人的生活变得更好，尽管目前还不是每个人都意识到这一点。

最小有效剂量

为了保持现实，重要的是不要在 QA（质量保证）措施上进行过度设计并投入过多的初期成本。我们不应该阻碍整个项目的进展，而且这种方法也不太可能获得所有利益相关方的支持。我建议始终专注于应用程序中最关键的部分。通常，会有某个特定用例、功能或其他核心内容，整个应用就是围绕它构建的。一些对于客户而言至关重要的核心功能必须正确运行。对这些功能进行测试。想出措施和方法，确保它们始终按预期运行。

我很喜欢“最小有效剂量”（MED）这个概念。它指的是能产生预期结果的最小剂量。在 QA 中，这可能意味着一个手动测试计划、流水线中的自动化测试，或者其他方式。这是一个好的起点。如果核心功能得到了保障，你可以逐步扩展到其他稳定性更高的领域。例如，对于所有新功能，都增加一个单元测试。此外，考虑一下那些你无法控制的信息来源，如外部 API 或用户输入。找到验证它们的方法，因为这些地方是软件由于误用而崩溃的潜在风险点。进行迭代和逐步改进，这也适用于 QA。

我关注的事项

每当我开始或加入一个新项目，我都会特别关注质量保证（QA）的概念。不论项目大小，我认为团队应该对此有深入的思考。

• 我们准备发布什么产品？
• 我们需要确保哪些功能能够正常运作？
• 我们如何达成这个目标？
• 我们有意放弃哪些措施，背后的原因是什么？

拥有一份关于这些内容的书面文件，以及一个测试计划，是软件发展的坚实基础。这表明我们作为一个团队已经考虑了前进的方向。再次强调，考虑到最小有效剂量的重要性。此外，我建议定期回顾所选择的方法，比如每季度进行一次。

在编写新代码时，我虽然不采用测试驱动开发（TDD），但我强烈推荐在 编写软件的同时编写测试。这是编写测试的最佳时机。如果你在实现功能的同时编写测试，你的代码就必须被结构化成可以实际测试的形式。事后为现有软件编写测试往往会发现代码过于互相依赖，或者违反了单一职责原则。通过测试，你可以证明你理解了期望的行为，并确保一切都按预期工作。如果愿意，这甚至可以被看作是一种代码文档。

项目的好处

当你积极发言时，周围的人会感受到你对项目的关心。提出有关质量的讨论并建议可能的解决方案，可以增强你作为开发者的影响力。这不仅对你个人有利，也有利于整个项目。它能够提升开发人员和管理人员的工作生活质量，并且这种改变是显而易见的。

只有实施了合适的 QA 措施，项目才能健康、稳定地成长。

让项目变得更好的方法

你的项目中已经开始实施 QA（质量保证）措施了吗，还是一切仍显得很脆弱？你是否渴望提升自己的开发技能，成为编写优质软件的佼佼者？

先从小事做起。思考一下你项目中的最小有效剂量（MED）。主动承担责任，成为你团队中推动积极变革的引领者。不是每个人都需要成为 QA 的倡导者，但你可以通过身体力行，教会团队成员必要的方法和技巧。激发团队内的讨论。

行动起来吧。

祝好，
Flo