大道至简与过度设计

前段时间，由于系统需要扩展一下发送事件通知，一个服务可以发送多个通知，而且通知里需要有一些逻辑判断。冥思苦想后，在抽象模板方法中增加了一个扩展点，又通过interceptor拦截服务的方法名，当时还在为自己高深的设计窃喜。

1. 找了一位同事帮我review下代码。大概1分钟之后，给出的评价是设计比较抽象，太复杂了。
回头好好想了想，软件系统中的设计是干嘛的?搞的那么花花稍稍，真的可以通过花哨的设计来提高软件的可维护性吗?可以通过抽象来解耦合吗?软件是用来的维护的，维护就需要人来读懂，太过抽象的设计并不利于软件的维护。一个功能的实现也许有很多方法，但是真正适合我们的不是最抽象的，而是实实在在的、易读的、易维护的设计。想起了以前读过的X核心和Y核心的代码，X核心以JBPM的工作流状态为核心，几乎任何的操作服务都要经过状态变更，几十个方法都要经过业务引擎的才能完成任务，导致很多业务都只能在业务引擎中增加代码，越来越难读，越来越难维护；还有那个产品模型，据说是伯克利大学的一个什么东西，hoho，看起来真的很累，最后只能是越来越臃肿；而Y核心以计价模型为中心，但是我们现在的业务只涉及到计价模型的1/3，初读者看起来会很痛苦，这也是过度设计吗？也许是还没有两位架构的功底，也许是确实有点过度设计，也许更多的是需要时间和经验去评判吧。

2.按照同事建议，花了一个晚上重构了代码。其中涉及到一个对象的深拷贝，网上搜搜，用java序列化的方法实现了深拷贝。接着又请教了另外一位同事，给出的意见是大道至简，这种深拷贝平时用到很少，而只是需要这个拷贝对象的个别属性，不需要搞这么复杂。

突然想起来刚来公司的《大道至简》的作者周爱民，此君已报道几个月，作为业务架构师异常低调，想起刚加入公司时tony的原话“这里的技术不简单，这里的业务很复杂”，看来就算大师来了也得熟悉熟悉咱公司的情况。牛人尚且如此啊，咱小菜鸟还需努力啊