我的组织中的软件开发团队（开发API - 中间件）正准备一次采用至少一种最佳实践。列表如下：
单元测试（实际意义上）， 自动化单元测试， 测试驱动设计＆amp;发展， 静态代码分析， 持续集成能力等。
有人可以请我参加一项研究，该研究显示采用哪种“最佳”做法可以获得更好的投资回报率，并更快地提高软件质量。那里有研究吗？ 这应该有助于我（支持我的主张）优先实施这些做法。
答案 0 :(得分：7)
“一项研究表明，采用哪种'最佳'做法可以获得更好的投资回报率，并更快地提高软件质量”
那不是很棒！如果有这样的事情，我们都会这样做，你只需在DDJ中阅读它。
既然没有，你必须做出痛苦的判断。
没有“为8％的投资回报率做X”。一些技术需要大量投资。其他人可以免费开始。
您无法了解投资回报率。所以你只能优先考虑投资。有些东西比其他东西更容易被采用。你必须考虑到你的团队愿意接受这项技术。
编辑。单元测试是免费的。
“用于编码测试的时间可能用于编码列表中的下一个功能” 没错，测试意味着开发人员可以做更多工作，但支持可以减少调试工作。我认为这不是1：1的交易。编写（和传递）正式单元测试所花费的时间会大大减少支持成本。
“遗留代码怎么样？” 关键是免费是管理成本的问题。如果将单元测试添加到旧代码中，则成本不是免费的。所以不要这样做。相反，添加单元测试作为维护，错误修复和新开发的一部分 - 然后它是免费的。
“Traning 是一个问题” 根据我的经验，这只是一些实例，除了代码之外，管理层还需要单元测试。它不需要超过全手会议来解释单元测试 required ，这里是示例。然后它要求每个人报告他们的状态为“测试书面/测试通过”。你不是完成了60％，你在315次测试中有232次。
“如果它适用于特定项目，它只能平均免费” 永远是真的，好点。
“需要更多时间，时间不是免费的” 您可以编写几乎不起作用的错误代码并需要大量支持，或者您可以编写有效且不需要大量支持的优秀代码。我认为实际通过测试所花费的时间会降低支持，维护和调试成本。根据我的经验，重构的单元测试的价值大大减少了进行架构更改的时间。它减少了添加功能的时间。
“我不认为这是投资回报率” 实际上，一个单元测试具有如此巨大的投资回报率，很难刻画。第一个通过测试的人认为你可以真正信任。只需要一段值得信赖的代码就可以节省时间，因为你花费大量时间思考这件事就少了。
战争故事
本周我必须完成批量数据加载;它验证并加载我们从客户接受的30,000个行文件。我们有一个很好的库，用于上传一些内部开发的文件。我想将该模块用于客户文件。但客户文件足够不同，我可以看到库模块API不太合适。
所以我重写了API，重新测试并检查了更改。这是一个重大的API更改。很多破损。很多人寻找每个参考并修复它们。
在运行相关测试后，我检查了它。然后然后我重新认为我认为这是一个不密切相关的测试。糟糕！它失败了。它正在测试一些不属于API的东西，也破坏了。固定。再次入住（迟到一小时）。
如果没有基本的单元测试，这可能会导致QA中断，需要错误报告，需要调试和返工。看看人工：1小时的质量检查人员找到并报告错误+ 2小时的开发人员时间来重建质量保证方案并找出问题+ 1小时来确定要解决的问题。
使用单元测试：1小时即可意识到测试未通过，并修复代码。
底线。我花了3个小时写测试吗？没有。但是这项计划得到了三个小时的回报，我的投资用于编写测试。
答案 1 :(得分：1)
你在找这样的东西吗？
答案 2 :(得分：1)
你假设你出席的名单构成了一套“最佳实践”（尽管我同意它可能会这样做，顺便说一下）
为什么不检查一下当前的做法，而不是尝试挑选一个流程变更？
问问自己：
你在哪里感受到最痛苦的感觉？你可以改变什么来减少/消除它？重复直到无痛。
答案 3 :(得分：0)
有关单元测试和TDD的ROI参考。请参阅我对此相关问题的回复; Is there hard evidence of the ROI of unit testing?
答案 4 :(得分：0)
有“局部最佳”之类的东西。你可以在Goldratt的书中找到目标。它表示只有提高整体吞吐量，创新才具有任何价值。实施新技术的决定应与项目内部的关键路径相关。如果技术加速已经足够快，那么它只会产生不必要的现成模块积压。这没有必要提高项目开发的整体速度。
答案 5 :(得分：0)
您未在列表中提及代码审核。对于我们的团队来说，这可能是我们获得最大投资回报的原因（是的，投资很陡，但回报更大）。我知道Code Complete（至少是原始版本）提到了与查找缺陷VS测试的评论效率相关的统计数据。
答案 6 :(得分：0)
我希望我得到比其他答案更好的答案，但我没有，因为我认为真正得到的回报目前并不常规。也就是说，在设计中，要尽量减少redundancy。这很容易说，但需要经验。
在数据中，它意味着保持数据规范化，当它不可能时，以松散的方式处理它，可以容忍一些不一致，而不是依赖于紧密绑定的通知。如果这样做，它会大大简化代码并减少对单元测试的需求。
在源代码中，这意味着如果您的某些“输入数据”以非常慢的速率发生变化，您可以考虑代码生成，作为简化源代码和获得额外性能的一种方法。如果源代码更简单，则更容易查看，并且减少了测试它的需要。
不要成为一个脾气暴躁，但我担心，从我看过的项目来看，存在过度设计的强烈倾向，有太多的“抽象层”，其正确性不会受到质疑如果他们不在那里。
答案 7 :(得分：0)
一次一次练习不会带来最佳投资回报率。这些做法并不是独立的。