昨天review了乙份設計文件，資料模型設計的異常的"靈活「，令我幾乎無法理解其中設計的奧妙...有感而發
記得以前我的**在接手乙個快爛掉的系統的時候，將該系統裡面的源**仔細閱讀後，砍掉了其中近1/3的**行，原因很簡單，原來系統設計了一大堆」靈活「的設計，使得系統看起來很強大，實際上由於各個人員水平參持不起，反而使得系統變得脆弱，配置複雜難用，問題百出。
再舉個例子，比如系統的配置引數，很多開發人員為了使得系統更加靈活，在系統中增加了很多配置引數，這種靈活的方式出發點是好的，但是可能帶來一系列的問題，比如安裝維護的問題（如何理解配置引數，配置引數的預設值），比如良好的配置引數介面的問題等等，這些問題如果沒有統一考慮，當配置引數越來越多的時候，系統將變得混亂不堪，難以管理。
同時，靈活設計應該是建立在全面的分析考慮基礎上的，反思自己過去的一些設計，或者看到別人的一些」靈活「的設計，我發現有相當的設計，都是不全面，但是確是『靈活』的，有用的，但是靈活帶來的好處沒有多少，系統的複雜性和穩定性卻降低了。
早期的時候，覺得多執行緒可能提高系統的併發處理能力，因此在很多程式開發中總是喜歡用多執行緒併發處理，但實際上多執行緒帶來的卻是系統的複雜性和加鎖後系統效能的下降，還不如採用單執行緒＋訊息度佇列處理的模式簡單可行。
靈活的設計是雙刃劍，帶來的是靈活，同時也帶來了高度的抽象以及系統的複雜性，越複雜，意味著對系統開發人員的要求越高，實現難度越大，風險也越高。把簡單的事情變複雜往往很容易，把容易的事情變簡單才困難。
是否採用」靈活「的設計，如果沒有客戶的實際需求支撐，實際是一種應該盡量避免的做法；如果沒有全面考慮清楚，則設計應該保留簡單，清晰，可擴充套件，只要能夠為未來的進一步的設計打好基礎，就足夠了。
應該記住：僅為可變而設計，不用擔心未來系統的靈活性，我們會不斷重構系統的！
軟體架構為誰而設計
節選自 軟體架構設計 書稿 如此看來，架構師應當為專案相關的不同角色而設計 如圖 5 2所示 l架構師要為客戶負責，滿足他們的業務目標和約束條件 l架構師要為使用者負責，使他們關心的功能需求和執行期質量屬性得以滿足 l架構師必須顧及處於協作分工 下游 的開發人員，l架構師還必須考慮 周邊 的管理人員...
軟體架構為誰而設計
2006年10月24日 16 24 00 節選自 軟體架構設計 書稿 如此看來，架構師應當為專案相關的不同角色而設計 如圖 5 2所示 l架構師要為客戶負責，滿足他們的業務目標和約束條件 l架構師要為使用者負責，使他們關心的功能需求和執行期質量屬性得以滿足 l架構師必須顧及處於協作分工 下游 的開發...
軟體架構為誰而設計？
1.為使用者而設計。不僅包括功能性需求，也包括非功能性需求，例如效能 穩定性 健壯性等。2.為客戶而設計。使用者和客戶有時是不一樣的，可以這樣理解 客戶是出錢的，使用者是軟體產品的直接使用者。需要充分考慮客戶的特點。業務目標 時間需求 預算限制以及整合需求。3.為開發人員而設計。主要關注軟體的非功能...