我组织中的软件开发团队（开发 API - 中间件）正准备一次采用至少一种最佳实践。以下是名单：
单元测试（真正意义上的）、自动化单元测试、测试驱动设计与开发、静态代码分析、持续集成能力等。
有人可以向我指出一项研究，该研究表明采用哪些“最佳”实践具有更好的投资回报率，并更快地提高软件质量。那里有研究吗？这应该有助于我（支持我的主张）优先考虑这些实践的实施。
Test Engineering Manager
问问题
1300 次
8 回答
8
“一项研究表明采用哪些‘最佳’实践具有更好的投资回报率，并更快地提高软件质量”
那岂不是很棒！如果有这样的事情，我们都会这样做，而您只需在 DDJ 中阅读即可。
既然没有，你就不得不做出痛苦的判断。
没有“为 8% 的 ROI 做 X”。其中一些技术需要大量投资。其他的可以免费启动。
- 单元测试（真正意义上的） - 免费 - ROI 立即开始。
- 自动化单元测试——不是免费的——需要自动化。
- 测试驱动的设计和开发 - 免费 - 立即开始投资回报。
- 静态代码分析 - 需要工具。
- 持续集成能力——便宜，但不是免费的
你无法知道投资回报率。所以你只能优先考虑投资。有些东西比其他东西更容易被人们采用。你必须考虑你的团队是否愿意接受这项技术。
编辑。单元测试是免费的。
“编写测试代码的时间本可以用于编写列表中的下一个功能” 确实，测试意味着开发人员做更多的工作，但支持做的调试工作更少。我认为这不是 1:1 的交易。多花一点时间编写（和通过）正式的单元测试可以显着降低支持成本。
“遗留代码呢？” 关键是免费是管理成本的问题。如果您将单元测试添加到遗留代码中，则成本不是免费的。所以不要那样做。相反，添加单元测试作为维护、错误修复和新开发的一部分——然后它是免费的。
“培训是一个问题” 根据我的经验，这是几个可靠的例子，以及除了代码之外对单元测试的管理需求。只需召开全体会议就可以解释需要进行单元测试，这里是示例。然后它要求每个人都将他们的状态报告为“已编写测试/已通过测试”。你还没有完成 60%，你已经完成了 315 次测试中的 232 次。
“平均而言，如果它适用于给定的项目，它只是免费的”总是正确的，好点。
“需要更多的时间，时间对业务来说不是免费的” 你可以编写几乎不工作但需要大量支持的糟糕代码，或者你可以编写可以工作但不需要大量支持的好代码。我认为让测试真正通过所花费的时间减少了支持、维护和调试成本。根据我的经验，重构单元测试的价值大大减少了进行架构更改的时间。它减少了添加功能的时间。
“我也不认为它是立即的 ROI” 实际上，一个单元测试具有如此巨大的 ROI，以至于很难表征。第一个通过的测试成为你认为可以真正信任的测试。只拥有一段值得信赖的代码可以节省时间，因为它减少了您需要花费大量时间思考的事情。
战争故事
这周我必须完成一个批量数据加载器；它验证并加载我们从客户那里接受的 30,000 个行文件。我们有一个很好的库，用于上传一些内部开发的文件。我想将该模块用于客户文件。但是客户文件有很大的不同，我可以看到库模块 API 并不适合。
所以我重写了 API，重新运行了测试并检查了更改。这是一个重大的 API 更改。破损多。寻找所有参考资料并修复它们。
运行相关测试后，我将其签入。然后我重新运行了我认为不密切相关的测试。哎呀。它失败了。它正在测试一些不属于 API 的东西，这也坏了。固定的。再次登记入住（晚了一个小时）。
如果没有基本的单元测试，这将在 QA 中出现问题，需要错误报告，需要调试和返工。看劳动力：QA人员1小时发现并报告错误+开发人员2小时重构QA场景并定位问题+1小时确定修复什么。
使用单元测试：1 小时意识到测试没有通过，并修复代码。
底线。我写测试花了3个小时吗？没有。但是该项目因我在编写测试方面的投资而获得了三个小时的回报。
于 2008-11-27T02:47:20.697 回答
1
您没有在列表中提及代码审查。对于我们的团队来说，这可能是我们获得最大投资回报的原因（是的，投资很陡，但回报更高）。我知道 Code Complete（至少是原始版本）提到了与查找缺陷 VS 测试的审查效率相关的统计数据。
于 2008-11-27T14:15:58.640 回答
1
您假设您提供的列表构成了一组“最佳实践”（尽管我同意它可能确实如此，顺便说一句）
与其尝试挑选一种流程变更，不如检查一下您当前的做法？
问问自己这个：
你最痛的地方在哪里？你可以改变什么来减少/消除它？
重复直到无痛。
于 2008-11-27T12:14:58.400 回答
1
于 2008-11-27T02:50:18.477 回答
0
我希望我有一个比其他答案更好的答案，但我没有，因为我认为目前真正得到回报的不是传统的。也就是说，在设计上，尽量减少冗余。说起来容易，但需要经验。
在数据中，它意味着保持数据规范化，当它不能规范化时，以一种可以容忍一些不一致的松散方式处理它，而不是依赖于紧密绑定的通知。如果你这样做，它会大大简化代码并减少对单元测试的需求。
在源代码中，这意味着如果您的某些“输入数据”以非常慢的速度更改，您可以考虑代码生成，作为简化源代码并获得额外性能的一种方式。如果源代码更简单，则更容易审查，并减少对其进行测试的需要。
不是脾气暴躁，但我担心，从我所看到的项目中，过度设计的趋势很强烈，有太多的“抽象层”，如果不是，它们的正确性就不会受到质疑甚至没有。
于 2008-11-27T14:53:04.413 回答
0
有一些关于单元测试和 TDD 的 ROI 参考资料。请参阅我对这个相关问题的回复；单元测试的投资回报率有确凿的证据吗？.
于 2008-11-27T02:42:00.147 回答
0
一次一种做法不会产生最佳的投资回报率。这些做法不是独立的。
于 2009-11-12T10:19:37.533 回答
0
有一种叫做“局部最优”的东西。您可以在 Goldratt 的书 Goal 中了解它。它说，只有提高整体吞吐量，创新才有任何价值。实施新技术的决定应该与项目内部的关键路径相关。如果技术加速已经足够快的过程，它只会造成不必要的准备模块积压。这没有必要提高项目开发的整体速度。
于 2008-11-27T03:17:27.767 回答