90-10法则：帮助软件开发减少失败

作者：Lucas Majerowicz

90-10 法则是指不要把 90% 的时间花在担心剩下的 10% 的时间上。

换句话说，就是不要花费大量精力试图实现 100%。这是为什么呢？有两个原因。

第一个原因是收益递减定律（Law of Diminishing Return），这条定律不仅适用于软件开发，也适用于几乎所有其他事情。以软件开发团队为例。将开发团队的规模从一名开发人员增加到五名开发人员，这可能将生产力提高 500% 。如果继续不断向团队添加开发人员，会发生什么呢？在到达某个点之后，生产力只会略微增加（例如，将 7 名开发人员增加到 8 名开发人员），甚至开始下降（例如，一个有 20 名开发人员的团队）。

第二个原因是，如果过分关注软件开发的某个方面，那么可能最终会忽视其他方面。例如，性能通常是以简单性和/或成本为代价的。编写的测试越多，开发所需的时间就越长。

下面是一些我应用 90-10 法则的例子。

选择正确的技术

例如，假设您公司中的每个人都对某个特定数据库拥有大量实践的经验。现在开始做一个新项目。 你会选择哪种数据库？是每个人都使用过的数据库，还是更新、功能更丰富的数据库？我的第一选择始终是每个人都使用过的数据库，即使还有另一个具有更多更好功能的数据库。

精通数据库、框架、编程语言等需要多年的实际实践经验......这就是为什么前几个项目可能很糟糕而新项目要好得多。许多软件架构师和经理没有意识到这一点，而从已知技术转换到新技术所付出的努力和成本非常高，而且在大多数情况下，带来的额外好处可以忽略不计。

代码

代码是否应该清晰可维护？确实应该。代码是否应该完美无缺并且没有更多的改进空间？大可不必。如果当前的代码难以维护，那么优化代码肯定会在未来得到回报。但是，如果代码已经足够好或足够简单，那么从改进中获得的实际收益的可能非常小，甚至可能使事情变得糟。

性能

遇到瓶颈，需要提高响应时间或吞吐量？通常，最大的改进来自最简单的更改。通过简单的更改，可能会获得 200% 甚至 500% 的改进。之后，更多的改进通常需要进行非常复杂的更改，并且性能增益将是微不足道的。对于大多数应用程序来说，花费数月的开发工作以获得另外 10% 的性能提升可能毫无意义。

测试

测试覆盖率是实际收益递减定律的完美例子。在到达某一点之后，一旦拥有足够多的测试和覆盖率，那么增加额外覆盖率所花费的努力就变得不值得了。

学习与自我提升

在我刚开始工作的时候，非常渴望学习，以至于曾经花几个小时观看讲座、参加课程或阅读有关软件开发的书籍。如果你也这么做过，那么你可能已经注意到，在一段时间后，很再难找到有用的内容，也很难仅通过消化别人的内容来真正学习新事物。

如果目标是学习知识，我认为通过动手获得实际经验学到得最多。一旦拥有一份有趣的工作，从中学到新的技能和技巧，你参加课程、阅读书籍和听讲座的数量应该会减少。

最后的想法

我发现开发人员通常倾向于过度关注代码质量和最佳实践（尤其是在阅读《代码整洁之道》之后），而架构师则对性能过度关注，经理则是对度量和最佳实践得采用（如 TDD、敏捷性、测试覆盖率等...）过度关注。

90-10 法则与安于平庸或鼓励懒惰无关。它是关于进行合乎逻辑的成本效益分析，使人可以专注于真正重要的事情；它不会使你成为最棒的软件开发人员或架构师，但它会帮助你平衡软件开发中不同的、有时是相互矛盾的各个方面。