简单即完美

 记得第一次在项目组中独立设计一个功能时，我花了很多时间组织业务模块，然后又花了将各个类的交互图、类图。全部搞定后，又手把手编写了全部源码。 最后找人维护时候，发现每次都要解释很久才能将我的想法说清楚。  当时并没有意识到是哪里出了问题。

   首先我的设计是可行的，这是在源码中实现就能够说明的。其次，类之间的耦合并不高，每个类都各司其事，真正依赖的是接口之间的依赖关系。
   业务流程呢，本身是有些复杂。那么这是导致我的设计不易理解的真正原因吗？我一直都怀着这个态度向其他人解释，本身业务复杂导致了我的设计复杂。所以需要消耗点经历去熟悉业务。

   后来经过相当长一段时间，原本的设计也经历了好多次迭代。我才渐渐发现，事实好像并非我想的那样。业务流程本身的复杂度并没有改变，但是我的设计越来越容易被理解了。

  很显然，迭代让我的代码获得了新生。  迭代主要遵循了以下原则：

1、使用更简单的方式重构设计
实际开发中我发现之前的设计有很多冗余的地方，虽然不影响最终实现功能与业务。但本身复杂的业务背景下，冗余设计对整个框架的理解会带来不小的干扰。 

2、使用更简单的方法实现设计
如果说原则1是设计层面的重构，那么原则2可以说成是类层面的重构。  比如一个方法的提取、删除或重命名。 类名变更、类的关系重构等。

这里不由得想到了重构入门的一本书《重构：改善既有代码的设计》，推荐一读

无数次历史经验告诉我们：简单最好！从此这也成为我的程序员生涯的座右铭。