前段時間，由於系統需要擴充套件一下發送事件通知，一個服務可以傳送多個通知，而且通知裡需要有一些邏輯判斷。冥思苦想後，在抽象模板方法中增加了一個擴充套件點，又通過interceptor攔截服務的方法名，當時還在為自己高深的設計竊喜。

1. 找了一位同事幫我review下程式碼。大概1分鐘之後，給出的評價是設計比較抽象，太複雜了。
回頭好好想了想，軟體系統中的設計是幹嘛的?搞的那麼花花稍稍，真的可以通過花哨的設計來提高軟體的可維護性嗎?可以通過抽象來解耦合嗎?軟體是用來的維護的，維護就需要人來讀懂，太過抽象的設計並不利於軟體的維護。一個功能的實現也許有很多方法，但是真正適合我們的不是最抽象的，而是實實在在的、易讀的、易維護的設計。想起了以前讀過的X核心和Y核心的程式碼，X核心以JBPM的工作流狀態為核心，幾乎任何的操作服務都要經過狀態變更，幾十個方法都要經過業務引擎的才能完成任務，導致很多業務都只能在業務引擎中增加程式碼，越來越難讀，越來越難維護；還有那個產品模型，據說是伯克利大學的一個什麼東西，hoho，看起來真的很累，最後只能是越來越臃腫；而Y核心以計價模型為中心，但是我們現在的業務只涉及到計價模型的1/3，初讀者看起來會很痛苦，這也是過度設計嗎？也許是還沒有兩位架構的功底，也許是確實有點過度設計，也許更多的是需要時間和經驗去評判吧。

2.按照同事建議，花了一個晚上重構了程式碼。其中涉及到一個物件的深拷貝，網上搜搜，用java序列化的方法實現了深拷貝。接著又請教了另外一位同事，給出的意見是大道至簡，這種深拷貝平時用到很少，而只是需要這個拷貝物件的個別屬性，不需要搞這麼複雜。

突然想起來剛來公司的《大道至簡》的作者周愛民，此君已報道幾個月，作為業務架構師異常低調，想起剛加入公司時tony的原話“這裡的技術不簡單，這裡的業務很複雜”，看來就算大師來了也得熟悉熟悉咱公司的情況。牛人尚且如此啊，咱小菜鳥還需努力啊