本节书摘来自异步社区《重构与模式（修订版）》一书中的第1章1.1节过度设计，作者【美】Joshua Kerievsky，更多章节内容可以访问云栖社区“异步社区”公众号查看。
第1章 本书的写作缘由重构与模式（修订版）软件模式的伟大之处，就在于它们传达了许多有用的设计思想。所以，在学习了大量模式之后，就理应成为非常优秀的软件设计人员，不是吗？当学习、使用了几十个模式后，我也曾这样认为。模式帮助我开发灵活的框架，帮助我构建坚固、可扩展的软件系统。但是几年后，我却发现自己在模式方面的知识和使用模式的方式总是使我在工作中犯过度设计的错误。
设计技术进一步提高之后，我发现自己使用模式的方式逐渐发生了变化：我开始“通过重构实现模式、趋向模式和去除模式（refactoring to，towards，and away from pattern）”，而不再是在预先（up-front）设计中使用模式，也不再过早地在代码中加入模式。这种使用模式的新方式来自于我对极限编程（XP）设计实践的采用，它帮助我既避免了过度设计，又不至于设计不足。
1.1 过度设计重构与模式（修订版）所谓过度设计（over-engineering），是指代码的灵活性和复杂性超出所需。有些程序员之所以这样做，是因为他们相信自己知晓系统未来的需求。他们推断，最好今天就把方案设计得更灵活、更复杂，以适应明天的需求。这听上去很合理，但是别忘了，这需要你未卜先知。
如果预计错误，浪费的将是宝贵的时间和金钱。花费几天甚至几星期对设计方案进行微调，仅仅为了增加过度的灵活性或者不必要的复杂性，这种情况并不罕见，而且这样只会减少用来添加新功能、排除系统缺陷的时间。
如果预期中的需求根本不会成为现实，那么按此编写的代码又将怎样呢？删除是不现实的。删除这些代码并不方便，何况我们还指望着有一天它们能派上用场呢。无论原因如何，随着过度灵活、过分复杂的代码的堆积，你和团队中的其他程序员，尤其是那些新成员，就得在毫无必要的更庞大、更复杂的代码基础上工作了。
为了避免这一问题，人们决定分头负责系统的各个部分。这看似能使工作更容易，但是副作用又产生了。因为每个人都在自己的小天地里工作，很少看看别处的代码是否已经完成了自己需要的功能，最后生成大量重复的代码。
过度设计下的代码会影响生产率，因为当其他人接手一个过度设计的方案时，必须先花上一些时间了解设计中的许多微妙之处，然后才能自如地扩展或者维护它。
过度设计总在不知不觉之中出现，许多架构师和程序员在进行过度设计时甚至自己都不曾意识到。而当公司发现团队的生产率下降时，又很少有人知道是过度设计在作怪。
程序员之所以会过度设计，也许是因为他们不想受不良设计的羁绊。不良的设计可能会深深地融入代码之中，对其进行改进不啻严峻的挑战。我遇到过这种情况，所以使用模式预先进行设计对我的吸引力才会如此之大。
本文仅用于学习和交流目的，不代表异步社区观点。非商业转载请注明作译者、出处，并保留本文的原始链接。
相关资源：重构与模式.pdf （高清完整版）