简单来说，过度设计就是进行了过多的面向未来的设计，进行了不必要的抽象封装，为系统增加了不必要的复杂度。
举个例子，你要做一个功能模块，但你考虑到到这个系统里还有几个未完成的模块和你要做的东西类似，所以你决定为此额外做一些抽象和封装，以便将来复用。然而到后来你开发那些相似的模块时你才发现，可能是由于抽象不足或抽象错误，你不得不重新修改之前的封装才能完成复用，导致最终成本实际上还不如不做；或者你发现复用的部分所降低的成本实际上还不如包装花费的成本。 这些都是最常见的过度设计的例子。
程序员在掌握了一些基本的设计能力之后，最常见也是最难克服的设计问题往往就是过度设计。上面的错误我相信大多数人都一而再，再而三的的犯过。

与过度设计相对的就是设计不足。
虽然是两个相对的概念，但设计不足和过度设计绝大多数时候都是一起出现的。都是最常见的设计问题。设计不足不仅常见于新手，老手也常犯。甚至我还见过有一类老程序员在经历过多次过度设计的打击之后，转向另一个极端，否定抽象封装的作用，走上“反设计”的道路。

过度设计和设计不足的平衡问题没有很好的解决办法，只有依靠经验的积累和不断的总结思考。如何把握这个度是最能考验程序员的经验和价值的问题之一。

我所尝试过的软件方法中，有一种方法的思维方式对于解决这个问题帮助最大，就是TDD（测试驱动开发），这里简单说下为什么TDD能解决这个问题：
TDD的一个核心思想是小步增量，不断重构。具体说来就是TDD有两个状态（常见的说法是两顶帽子）：
状态A：用test case描绘需求，并使用最简单的方式满足这个test case。注意要用最简单的方式满足这个需求，不能为任何test case之外的需求做任何设计。 test case通过之后进入状态B；
状态B：重构代码，让现有的代码在尽量保持简单性的同时足够优雅清晰。注意此时你只能对现有的实现代码进行重构，不能增加任何新的功能和test case。
整个TDD的过程就是在这两个状态间不断转换的过程。在状态A增加功能，在状态B优化设计。

TDD的这种思维方式走的稍微极端一点。它直接排斥任何对未来的设计，转而以优雅简洁的设计和test case来为未来需求的重构降低成本。 可以说严格遵循TDD做出来的设计必然在过度设计和设计不足方面都不会有太大的问题。