记得第一次在项目组中独立设计一个功能时,我花了很多时间组织业务模块,然后又花了将各个类的交互图、类图。全部搞定后,又手把手编写了全部源码。 最后找人维护时候,发现每次都要解释很久才能将我的想法说清楚。 当时并没有意识到是哪里出了问题。
首先我的设计是可行的,这是在源码中实现就能够说明的。其次,类之间的耦合并不高,每个类都各司其事,真正依赖的是接口之间的依赖关系。
业务流程呢,本身是有些复杂。那么这是导致我的设计不易理解的真正原因吗?我一直都怀着这个态度向其他人解释,本身业务复杂导致了我的设计复杂。所以需要消耗点经历去熟悉业务。
后来经过相当长一段时间,原本的设计也经历了好多次迭代。我才渐渐发现,事实好像并非我想的那样。业务流程本身的复杂度并没有改变,但是我的设计越来越容易被理解了。
很显然,迭代让我的代码获得了新生。 迭代主要遵循了以下原则:
1、使用更简单的方式重构设计
实际开发中我发现之前的设计有很多冗余的地方,虽然不影响最终实现功能与业务。但本身复杂的业务背景下,冗余设计对整个框架的理解会带来不小的干扰。
2、使用更简单的方法实现设计
如果说原则1是设计层面的重构,那么原则2可以说成是类层面的重构。 比如一个方法的提取、删除或重命名。 类名变更、类的关系重构等。
这里不由得想到了重构入门的一本书《重构:改善既有代码的设计》,推荐一读
无数次历史经验告诉我们:简单最好!从此这也成为我的程序员生涯的座右铭。