(由于现在很多人言必提设计模式，好像知道几个设计模式就成了高手)

《人月神话》中有这么一段：

在开发第一个系统时，结构师倾向于精炼和简洁。他知道自己对正在进行的任务不够了解，所以他会谨慎仔细地工作。

在设计第一个项目时，他会面对不断产生的装饰和润色功能。这些功能都被搁置在一边，作为“下一个”项目的内容。第一个项目迟早会结束，而此时的结构师，对这类系统充满了十足的信心，熟练掌握了相应的知识，并且时刻准备开发第二个系统。

第二个系统是设计师们所设计的最危险的系统。而当他着手第三个或第四个系统时，先前的经验会相互验证，得到此类系统通用特性的判断，而且系统之间的差异会帮助他识别出经验中不够通用的部分。 一种普遍倾向是过分地设计第二个系统，向系统添加很多修饰功能和想法，它们曾在第一个系统中被小心谨慎地推迟了。结果如同Ovid所述，是一个“大馅饼” 

现在这个现象似乎加重了，因为设计模式的出现，很多所谓的系统架构师在第一次设计系统时就会引入大量的设计模式，由于设计模式的基本要求是使用者能预测将来的需要的改动，那些对系统需求都没摸透的系统架构师就会猜测将来的变化并采取相应的设计模式（甚至有的人都不知道将要面对什么变化，只是绝能能套设计模式）。

于是我看到了这样一个复杂的架构，里面采用了代理模式，Facade模式，DAO模式，工厂模式....但是，如果我要加一个东西，却需要按照他的文档到某个XML文件中加几句，再到某个文件中加几个宏，然后再到某个包中加一个类，并实现某个接口，然后再到另外一个地方加一个工厂类，并实现另外一个接口，同时该工厂类的实现必须按照某种规范返回刚才的类......还不如一个超级耦合的系统，性能要好很多，调试也容易。