是什么？

进行了过多的面向未来的设计：进行了不必要的抽象封装，为系统增加了不必要的复杂度。

问题分析

程序设计的一切应以需求为准。
过度设计不是实现了太多功能，而是为了实现太多自己觉得以后会出现但是结果没出现的需求，导致系统架构过于庞大复杂。
本质：想太多，妄想自己的程序能应对更多（甚至一切）需求的变化。

怎么解决这个问题

在做设计时

提醒自己：设计是为了满足需求，别为了设计而设计
不要指望设计出所有细节，边写边重构

测试驱动开发

小步增量，不断重构。分2步。

1. 用测试用例描绘需求，用最简单的方式满足测试用例。
2. 重构。让现有代码在尽量保持简单的同时足够优雅清晰。不许引入任何新功能。

排斥任何对未来的设计，用优雅简洁的设计为未来的重构降低成本。

相关思考

对于规模大的项目来说，因为人多人杂，如果不尽可能预先设计会容易造成返工浪费资源，设计的适度依赖于架构师的经验和需求的稳定性，想完全避免过度设计是几乎不可能的。可以前期控制参与人员的数量，在小范围内实现核心功能（精益），通过重构改良设计，再增加人员全面开发。

对于只有一两个开发者的小项目来说，导出好设计的唯一手段就是重构，妄图不经反复修改而一次性解决问题最终会发现都是在自找麻烦。

应对需求变动的常用方式

1. 代码不重复（单点改动）
2. 高聚合（细分功能代码，提倡小对象、短方法），低耦合（隔离变动）
3. 代码易读，符合思维习惯

需权衡：灵活、易读、效率

• 灵活：精细的功能分解和更抽象的概念，以方便复用
  功能细分会影响局部开发效率（更多的代码量）和整体运行效率（调用和传参增多）
  概念抽象会增加阅读负担

砍掉工作量大且不易理解的灵活性设计，保留工作量小且不需引入新概念的灵活性设计。
发现重复代码时，立刻通过重构改为单点。
写新代码的过程中尽可能把旧代码中的“臭味”重构掉。