說起軟體設計，我們可能每個人都做過，但是什麼樣的方案才是好的設計方案？如何才能設計出乙個好的設計方案？在設計過程中需要注意哪些呢？不要總是說：低耦合、可維護性、可擴充套件性、簡易性、可重用性等，本文試圖另乙個角度出發，帶著前面的這些問題，使大家能明白那些問題的答案，並與大家一起**。
什麼樣的方案才是好的設計方案？
當我們完成了乙個良好的設計方案後，我們回頭再仔細分析是什麼因素影響了我們的思路，使我們最終完成（確切的說是選擇了）了這個設計方案（而不是另乙個），我們會發現這些因素是：使用者功能性的需求、技術效能上的要求和研發成本（或能力）的制約，當然其實還有一些其它因素如：客戶主觀上的要求、審美或商務因素、向前相容性要求等，不過這些因素多半是一些非技術性因素，我們在此不做過多討論；能否很好的滿足這些因素就決定了乙個設計方案是否是乙個好的設計方案，所以我們在設計之初就必須對這些因素加以充分的考慮。
如何才能設計出乙個好的設計方案？
但事實上，基本上沒有乙個方案是可以每個因素都能百分之百滿足的，乙個好的設計方案，往往是乙個平衡的結果，這也是為什麼我們在討論設計方案是總是可能爭論不休的原因，因為不同的人從不同的角度出發都可以得到他認為好的乙個方案，人們總是會有各自的理由，而且那些理由都是有道理的，但請大家記住：乙個好的設計方案，往往是乙個平衡的結果。從某種意義上說能否做好平衡是決定乙個方案是否是好的方案的關鍵，尤其是對那些複雜的大的設計方案。
平衡的藝術
但怎樣才能做好平衡呢？ 答案顯然不是：一碗水要端平。有乙個著名的原理叫 28 原理，它同樣也適合我們軟體開發的規律，我們的百分之 80 的精力設計和開發的部分只給我們帶來了百分之 20 的回報，或者說，我們百分之 80 的回報只是我們的百分之 20 的努力得來的，這個原理告訴我們，我們在平衡時要抓住重點，那些非重點的部分，如果必要可以捨棄，捨棄它們可能會帶來更大的價值。下面我們先分析一下前面提到的幾個關鍵因素來仔細討論下平衡的藝術。
使用者功能性的需求
毫無疑問，我們的軟體最終的目的就是為了要滿足使用者的需求，由於我們要設計的是乙個產品型的軟體，這就決定了我們的需求不是很好明確，面可能比較廣，甚至有些需求可能還是我們自己想象出來的，但正因為如此我們才有平衡的必要，試想如果我們做的是乙個專案，那只需要按照甲方的要求完成即可，合同上甚至很明確要求了，此時也沒有多少需要平衡的了。乙個產品型的軟體，要把百分之80 以上使用者都用的功能進行良好的設計做到易用好用效能出眾並投入大量人力研發，而那些 50% 使用者會用到的需求就可以少投入些人力與時間，那些百分之 5 使用者才可能會用的功能且需要耗費大量人力時間的甚至可以捨棄不做。
但平衡也不僅僅是在與選擇做與不做某個功能，更在於怎麼做某個功能，一般對於使用者的需求我們會有下面幾個實現方式：
1 實現乙個簡單易用、設計良好、100% 滿足使用者需求的介面或功能
2 通過一些介面上的選項設定來實現使用者的需求
3 通過手工修改一些配置檔案來實現使用者的需求（這種實現方式可能需要的研發資源只佔第一種實現方式的1% ）
4 通過指令碼來實現使用者的需求
5 通過外掛程式或定製開發來實現使用者的需求（後2 種方式其實就是說現在不考慮這個需求，以後就算有了我們能支援即可）
不同的實現方式需要投入不同的量級的研發資源，從上至下占用研發資源越來越少，這就是我們需要做平衡的地方。
技術效能上的要求
研發成本（或能力）的制約
這個因素往往是我們最應該多考慮，但是經常缺忽視的乙個因素。
以乙個工程師一年開發3 個模組和一年讓他開發 10 個模組來做個比較，只開發 3 個模組時，他基本上可以做到讓每個模組完成到 90 分以上，包括**質量、測試單元、文件等，還能有些時間學習和研究些新技術，並能保持乙個愉快的心情高效率的工作下去；但是如果一年讓他開發 10 個模組，他可能只能勉強做到讓每個模組完成 60 分以上，**可能有考慮不周全留下隱患、測試覆蓋率不高、文件欠缺，終日忙於趕進度沒時間充電，工作疲憊效率低下。
多半的研發工程師是樂觀的，在開始的時候自信滿滿，過低的估計了研發需要的時間，我經常說，要把乙個模組完成到60 分可能 1 個人月，要完成到 80 分可能就要 3 個人月，要完成到 90 分以上可能需要 8 個人月，這個增長的比例並不是直線性的而是拋物線形的，所以研發週期往往難以估計，我們必須為將來準備足夠的緩衝時間，某種意義說，越多越好。
所以這也正是在上面的一些平衡過程中，有一些因素要讓位於研發資源的投入的重要原因，乙個為將來的研發困難做好了充分準備的設計方案才能算是乙個好的方案。
在設計過程中需要注意哪些呢？
從需求出發
從使用者角度理解的需求出發考慮總是沒錯的，最忌設計時只考慮技術方面的問題，當然技術方面的問題也必須予以考慮，但前提是必須對需求最好充分的了解和分析，從需求出發並不是說需求最大，需求有時也必須讓位於其他的一些因素，要做好平衡。
從一開始就考慮那些影響面很廣的技術要求
這些因素很可能嚴重的影響設計，必須提前予以研究，這種研究可以是脫離需求的零散的，有時甚至可以寫一些測試**，但最終必須還是從需求出發，在充分的了解了各種技術點之後，再決定自己的最終設計
充分考慮研發資源成本
再好的設計沒有付諸實施的資本也不行，所以還是那句話，要做好平衡。
艾偉也談專案管理，架構組織管理
架構組織管理的五大原則 構想 節奏 預見 協作和簡化 架構組織的三在概念 準則 模式和反模式 準則 為了把原則運用到實踐中，需要實施細節。準則把廣泛的原則翻譯成是否和如何執行原則的細節。模式 描述了開發或者使用軟體架構時可能遇到的常見問題的解決方案。反模式 反模式描述了組織在實踐中可能遇到的陷阱，描...
艾偉也談專案管理，成功軟體專案管理的奧秘
如何入門並設定軟體成功的目標 實踐技能建議 要點說明 1 設定優先順序 1 為團隊成員提供服務 2 滿足組織客戶的需求 3 從事自己相關的專案 2 分析自我能力差距 人員管理 人際關係 解決衝突 推銷想法 聆聽技巧 鍛鍊演講表達能力 3.學會定義質量 與開發團隊 客戶確定一致的產品質量定義與準則 4...
艾偉也談專案管理，微型專案實踐感悟
微型專案是指絕大部分工作由乙個人員負責的專案，這個核心成員負責專案的系統分析 構架 及絕大部分的編碼工作。專案的持續時間一般不會超過乙個月。專案的參與人員除了核心的程式設計師外還可能一部分輔助人員，包括第二程式設計師 負責一部分編碼工作 美工 負責介面設計 等。微型專案的規模一般很小，業務邏輯也比較...