哪些软件开发实践提供了最高的ROI？

我所在组织的软件开发团队（开发API的中间件）准备一次至少采用一种最佳实践。名单上有以下内容：

单元测试（在其真正意义上）， 自动化单元测试， 测试驱动设计与开发， 静态代码分析， 持续集成能力等

有人能告诉我一项研究，该研究表明，采用哪种“最佳”实践可以获得更好的投资回报率，并更快地提高软件质量。外面有研究吗？

---

这应该有助于我（支持我的主张）优先考虑这些实践的实施。

有一些关于单元测试和TDD的ROI参考资料。请参阅我对这个相关问题的回答

“一项研究表明，采用哪种‘最佳’实践具有更好的投资回报率，并更快地提高软件质量”

那不是很好吗！如果有这样一件事，我们都会去做，你只需在DDJ中阅读即可

既然没有，你就必须做出痛苦的判断

没有“为8%的投资回报率做X”。有些技术需要大量投资。其他的可以免费启动

• 单元测试（真正意义上的）免费ROI立即开始
• 自动化单元测试——不是免费的——需要自动化
• 测试驱动的设计和开发-免费-立即启动ROI
• 静态代码分析-需要工具
• 持续集成功能-价格低廉，但不是免费的

你不可能知道投资回报率。所以你只能优先考虑投资。有些东西比其他东西更容易被人们接受。你必须考虑到你的团队是否愿意接受这项技术

编辑。单元测试是免费的

• “编写测试代码的时间可能用于编写列表中的下一个功能” 诚然，测试意味着开发人员要做更多的工作，但支持调试所做的工作更少。我认为这不是1:1的交易。多花一点时间编写（并通过）正式的单元测试可以显著降低支持成本

• “遗留代码呢？” 重点是，免费是一个管理成本的问题。如果将单元测试添加到遗留代码中，那么成本并不是免费的。所以不要那样做。相反，添加单元测试作为维护、bug修复和新开发的一部分——这样就免费了

• “培训是一个问题” 根据我的经验，这只是几个可靠的示例的问题，除了代码之外，管理层还需要进行单元测试。只需要召开全体会议就可以解释需要进行单元测试，下面是示例。然后，它要求每个人报告他们的状态为“编写的测试/通过的测试”。你还没有完成60%的测试，315次测试中你只完成了232次

• “只有在为给定项目工作时，它才平均免费” 总是正确的，好的观点

• “需要更多的时间，时间不适用于业务” 您可以编写几乎无法工作且需要大量支持的坏代码，也可以编写可以工作且不需要大量支持的好代码。我认为让测试真正通过所花费的时间减少了支持、维护和调试成本。根据我的经验，重构单元测试的价值大大缩短了进行架构更改的时间。它减少了添加功能的时间

• “我也不认为这是立即的投资回报” 实际上，一个单元测试的ROI非常大，很难描述。第一个通过的测试就是你认为你可以真正信任的测试。只有一段值得信赖的代码可以节省时间，因为它减少了你花大量时间思考的事情

战争故事

本周我必须完成一个批量数据加载程序；它验证并加载我们从客户处接受的30000行文件。我们有一个很好的库，用来上传一些内部开发的文件。我想将该模块用于客户文件。但是客户文件差异很大，我可以看出库模块API并不真正合适

因此，我重写了API，重新运行测试，并检查了中的更改。这是一个重大的API变化。很多破损。对源代码进行大量修改，以查找每个引用并修复它们

在运行相关测试之后，我将其签入。然后我重新进行了一次我认为不密切相关的测试。哎呀。它失败了。它测试的东西不是API的一部分，它也坏了。固定的。再次登记（晚了一小时）

如果没有基本的单元测试，这将破坏QA，需要错误报告，需要调试和返工。看看工作量：1小时的QA人员查找并报告错误+2小时的开发人员时间来重建QA场景并定位问题+1小时来确定要修复的问题

单元测试：用1小时意识到测试没有通过，并修复代码

---

底线。写测试花了我3个小时吗？没有。但是我花了三个小时写这个测试，这个项目又回来了。

你在找这样的东西吗

---

有一种东西叫做“局部最优”。你可以在戈德拉特的书《目标》中读到。它说，创新只有在提高总体吞吐量的情况下才有价值。实施新技术的决策应与项目内部的关键路径相关。如果技术的速度已经足够快，那么它只会造成不必要的模块积压。这并没有必要提高项目开发的总体速度。
您假设您提供的列表构成了一组“最佳实践”（尽管我同意它可能是这样，顺便说一句）
与其试着挑选一个过程变更，为什么不检查一下您当前的实践呢
问问自己：
你在哪里感觉最好