16.8　过度的开发（Over-engineering）

几年前，曾参与了一个产品重构的开发，该产品有4个模块，为了避免风险，我们从一个最简单也最基本的模块入手，原计划是在半年内完成重构，然而经过了一年的开发仍未结束，设计人员总是觉得某些方面可以做得更好，特别是技术方面，他们经常发现某些技术上的一些小的以前未使用的功能，他们拼命地把这些功能加入软件，并且随着时间的发展，新的技术、新的软件和新版本的发布带来了更好的功能，这些最终让他们看花了眼，导致不断推翻之前使用的技术，而未提炼模型，最终软件迟迟不能发布，功能却没有得到明显的增强。

一年之后，我便离开了那家公司。又过了两年，我碰巧遇到一位以前参与开发的工程师，他告诉我那个简单的模块还没有完成重构，其他模块也没有开始重构。

这是一个真实的故事，我至今还记得他们为了使用Hibernate的一个小小功能而大肆修改，导致其他使用该产品的项目停滞等待。虽然他们在不停地完善软件，但只注重了使用技术，而没有花时间去提炼完善的模型，殊不知最重要的是模型。其间往往导致不仅功能没有增强，反而因为模型的粗糙而不得不经常推翻以前所使用的新技术。

虽然导致三年仍未完成一个模块重构的原因是多方面的，但是过度的开发是其失败的一个重要原因。从某种程度上来说，一个软件在任何时候都需要重构，但是完美的软件是不存在的，你必须首先承认这一点，然后才能开发出成功的软件。过度开发不仅浪费了时间和金钱，还造成了代码过度复杂臃肿，产生很多无用的接口和配置，为了增加一个小小的功能必须得大动干戈，给维护造成很大的麻烦，而且可配置的功能太多会造成使用上的不方便。

在软件开发中，我们经常使用到一条原则叫Pareto原则^[1]（也称为8020原则），这条原则在各个领域都经常被使用到。

20%的工作需要花费80%的精力。

为了避免过度开发，我们在这里也可以应用该原则。

你的开发可以让80%的常用功能非常容易实现，而剩下20%的功能可以实现但需要花费较多的精力。

这样，你就可以避免为那些不常用的功能和需求而花费大量的精力，导致过度的设计。使用XP（极限开发）可以由浅入深地开发，一定程度上避免过度的开发，但是经验并不丰富的开发人员在开发过程中往往造成了过于简单和粗糙的设计，而不易扩展和完成必要的功能。既想避免过度开发，又能设计出扩展性良好的软件，绝非一朝一夕就能够做到的。

Eric Evans的“Domain-Driven Design：Tackling Complexity in the Heart of Software”，书中详细地讲述了如何使用DDD解决复杂领域问题，使用DDD开发能够在开发中平衡这二者，有兴趣的读者可以阅读此书以作更深入的了解。

[1]Pareto法则最初在1906年被Vilfredo Pareto发现，当时是为了说明经济现象：意大利80%的土地掌握在20%的人手里。这条原则被广泛地使用到各个领域，例如在商业上：80%的销售来自20%的客户。