軟件開發前期設計時的注意事項
說起軟件設計，我們可能每個人都做過，但是什么樣的方案才是好的設計方案？如何才能設計出一個好的設計方案？在設計過程中需要注意哪些呢？不要總是說：低耦合、可維護性、可擴展性、簡易性、可重用性等，本文試圖另一個角度出發，帶著前面的這些問題，使大家能明白那些問題的答案，并與大家一起探討。
什么樣的方案才是好的設計方案？
當我們完成了一個良好的設計方案后，我們回頭再仔細分析是什么因素影響了我們的思路，使我們最終完成（確切的說是選擇了）了這個設計方案（而不是另一個），我們會發現這些因素是：用戶功能性的需求、技術性能上的要求和研發成本（或能力）的制約，當然其實還有一些其它因素如：客戶主觀上的要求、審美或商務因素、向前兼容性要求等，不過這些因素多半是一些非技術性因素，我們在此不做過多討論；能否很好的滿足這些因素就決定了一個設計方案是否是一個好的設計方案，所以我們在設計之初就必須對這些因素加以充分的考慮。
如何才能設計出一個好的設計方案？
但事實上，基本上沒有一個方案是可以每個因素都能***滿足的，一個好的設計方案，往往是一個平衡的結果，這也是為什么我們在討論設計方案是總是可能爭論不休的原因，因為不同的人從不同的角度出發都可以得到他認為好的一個方案，人們總是會有各自的理由，而且那些理由都是有道理的，但請大家記住：一個好的設計方案，往往是一個平衡的結果。從某種意義上說能否做好平衡是決定一個方案是否是好的方案的關鍵，尤其是對那些復雜的大的設計方案。
平衡的藝術
但怎樣才能做好平衡呢？ 答案顯然不是：“ 一碗水要端平 ” 。有一個著名的原理叫 28 原理，它同樣也適合我們軟件開發的規律，我們的百分之 80 的精力設計和開發的部分只給我們帶來了百分之 20 的回報，或者說，我們百分之 80 的回報只是我們的百分之 20 的努力得來的，這個原理告訴我們，我們在平衡時要抓住重點，那些非重點的部分，如果必要可以舍棄，舍棄它們可能會帶來更大的價值。下面我們先分析一下前面提到的幾個關鍵因素來仔細討論下平衡的藝術。
用戶功能性的需求
毫無疑問，我們的軟件最終的目的就是為了要滿足用戶的需求，由于我們要設計的是一個產品型的軟件，這就決定了我們的需求不是很好明確，面可能比較廣，甚至有些需求可能還是我們自己想象出來的，但正因為如此我們才有平衡的必要，試想如果我們做的是一個項目，那只需要按照甲方的要求完成即可，合同上甚至很明確要求了，此時也沒有多少需要平衡的了。一個產品型的軟件，要把百分之80 以上用戶都用的功能進行良好的設計做到易用好用性能出眾并投入大量人力研發，而那些 50% 用戶會用到的需求就可以少投入些人力與時間，那些百分之 5 用戶才可能會用的功能且需要耗費大量人力時間的甚至可以舍棄不做。
但平衡也不僅僅是在與選擇做與不做某個功能，更在于怎么做某個功能，一般對于用戶的需求我們會有下面幾個實現方式：
1 實現一個簡單易用、設計良好、100% 滿足用戶需求的界面或功能
2 通過一些界面上的選項設置來實現用戶的需求
3 通過手工修改一些配置文件來實現用戶的需求（這種實現方式可能需要的研發資源只占***種實現方式的1% ）
4 通過腳本來實現用戶的需求
5 通過插件或定制開發來實現用戶的需求（后2 種方式其實就是說現在不考慮這個需求，以后就算有了我們能支持即可）
不同的實現方式需要投入不同的量級的研發資源，從上至下占用研發資源越來越少，這就是我們需要做平衡的地方。
技術性能上的要求
用戶總希望在軟件界面上執行任何操作都能立即得到結果、希望系統能支持越來越多的在線并發、希望系統能全年不停機運行不出任何錯誤，希望系統能兼容各種平臺…… ，所以對我們的系統有很多性能上的要求，要求我們必須支持集群、各種高速緩存、多語言、支持事務操作等，有些性能要求是必須在設計之初加以認真考慮的，因為從以往的經驗來看，如果出于研發成本的考慮，系統一開始沒有考慮集群、多語言、事務，而在以后系統成型后再予以考慮，那會往往付出更大的代價，這種代價有時是傷筋動骨的。
同樣是滿足用戶功能上的需要，一個實現需要投入大量研發資源，但程序效率很高，而另一個只需要少量的研發資源，但程序效率稍差，此時該如何平衡呢？相信大多數人都能做出正確的選擇，要綜合考慮：目前可用的人力資源數量、需要投入的研發資源的差異，模塊的使用頻度的因素；我經常說，對于客戶端應用來說在用戶的一次界面操作中只執行一次的函數就可以少花點時間實現，因為3ms 完成一個操作的執行和 300ms 完成一個菜單的執行其實對用戶來講是差別不大的，但這個并不適用與服務器端應用，服務器端應用還需要考慮到在線人數，如果能 3ms 完成就能支持更多的在線用戶。
研發成本（或能力）的制約
這個因素往往是我們最應該多考慮，但是經常缺忽視的一個因素。
以一個工程師一年開發3 個模塊和一年讓他開發 10 個模塊來做個比較，只開發 3 個模塊時，他基本上可以做到讓每個模塊完成到 90 分以上，包括代碼質量、測試單元、文檔等，還能有些時間學習和研究些新技術，并能保持一個愉快的心情高效率的工作下去；但是如果一年讓他開發 10 個模塊，他可能只能勉強做到讓每個模塊完成 60 分以上，代碼可能有考慮不周全留下隱患、測試覆蓋率不高、文檔欠缺，終日忙于趕進度沒時間充電，工作疲憊效率低下。
多半的研發工程師是樂觀的，在開始的時候自信滿滿，過低的估計了研發需要的時間，我經常說，要把一個模塊完成到60 分可能 1 個人月，要完成到 80 分可能就要 3 個人月，要完成到 90 分以上可能需要 8 個人月，這個增長的比例并不是直線性的而是拋物線形的，所以研發周期往往難以估計，我們必須為將來準備足夠的緩沖時間，某種意義說，越多越好。
所以這也正是在上面的一些平衡過程中，有一些因素要讓位于研發資源的投入的重要原因，一個為將來的研發困難做好了充分準備的設計方案才能算是一個好的方案。
在設計過程中需要注意哪些呢？
從需求出發
從用戶角度理解的需求出發考慮總是沒錯的，最忌設計時只考慮技術方面的問題，當然技術方面的問題也必須予以考慮，但前提是必須對需求***充分的了解和分析，從需求出發并不是說需求***，需求有時也必須讓位于其他的一些因素，要做好平衡。
從一開始就考慮那些影響面很廣的技術要求
這些因素很可能嚴重的影響設計，必須提前予以研究，這種研究可以是脫離需求的零散的，有時甚至可以寫一些測試代碼，但最終必須還是從需求出發，在充分的了解了各種技術點之后，再決定自己的最終設計
充分考慮研發資源成本
再好的設計沒有付諸實施的資本也不行，所以還是那句話，要做好平衡。
【編輯推薦】
