對編碼、設計中「極簡原則」的想法

早上剛看了博文《對於開發人員，「極簡原則」須要修正，請看「新極簡原則」》，有一些想法想說說。 我用了三年的時光維護一個不算簡單的系統，竊覺得，「極簡原則」也好，單一職能原則也好，最根本的目的是爲了易讀易懂；

極簡必要性： 舉個例子，我之前命名API，務求全面詳實，但願用戶看到方法名，就理解其功能、特色、參數類型、返回值；但結果是名稱冗長，不易閱讀。 如：Member getMemberInfoByMemberno(String id) 當隔段時間再來看，連我本身都被長長的命名弄得煩躁不安，不想去細看。因此長命名並無達到預期效果。 實際上，這個接口充分利用已存在返回值和形參名，就能夠精簡不少。 如：Member getInfo(String memberno)；

再舉個例子,一樣是獲取郵件模板的ServletApi： 
   /email/getEmailTempliteByTitle.do 
  /email/getModel.do 
在有前綴/email的狀況下，後面的方法名不必再說明是獲取email模板。

極簡過分： 舉個過去追求極簡，一句話包含無數信息的例子， member.setName(StringUtil.filterKeyword(user.getUserName().trim()));

無論你信不信，反正我看了這句話有想吐的衝動；若是不巧要調試這句話，那麼我確定罵娘。 這一句包含的信息量太大，若是出bug，那麼就須要細緻定位，是user==null，仍是user.getUserName() == null，或者StringUtil.filterKeyword寫錯了，或member.setName沒有生效。 系統設計裏定義模塊的目的之一，就是將bug的發生限制在必定範圍，但太過追求「能一句代碼實現的，就不用兩句代碼」，那麼災難就會降臨，阿門……

因此，我以爲編碼的最根本原則是「易讀易懂」。若是寫兩句可以讓人清晰的讀懂，不必非得整合成一句。 
由於「代碼是給開發人員看的」，或者更進一步，代碼是給系統維護人員看的。