2013.6.2
設計能力是技術人員水平的主要象徵之一，項目組的技術人員跋涉了前面的各個階段，終於迎來了由他們自己主導的時間。優秀系統的總設、優秀的模組的概設追根到底是設計人員的自己能力的展現，這要求他們有足夠的視野，經驗和思考。專案管理在設計階段主要起到的作用是：
1、協助設計經驗不足的組員進行缺陷預防，保住設計品質的底線2、給予經驗豐富的專家以明確的目標，以便進一步提高設計的品質3、降低返工的風險
按照項目的五要素，設計階段分為以下階段(圖片可放大網頁看)：
1、干係人期望-目標 在項目流程中劃分總設，概設，詳設的主要目的是： 總設：根據架構和需求將系統劃分為多個功能和基礎模組，並定義清這些模組的互動方法及介面。 概設：模組概要設計是將模組拆分成多個子模組，並定義清子模組間的互動方法及介面。 詳設：將每個子模組的內部邏輯，流程圖，甚至虛擬碼理清，為後續的編碼直接服務。 在設計階段常見的干係人： 1）主管/產品經理：他們主要期望產品的穩定性及擴充性，通常一個設計被大家認可，至少要包含這兩方面中一個因素。 基礎功能的穩定效能夠迎來客戶的好感，而擴充性能夠降低後續再次開發的工作量，會被主管和產品經理所期望。穩定性通常在產品需求中會進行要求， 擴充性往往是可以獲得亮點的突破口。 2）技術支援人員/客服人員：他們期望系統及模組能夠被方便的調試排查問題，即設計的可維護性。 3）測試團隊：測試期望開發在設計階段能夠考慮清自動化測試的方案，以便能夠降低執行測試及迴歸測試的工作量。 4）專案經理/主管：在總設階段能夠抽出公用代碼以便降低目前的版本的風險及工作量，同時能夠為後續的項目提供協助。
2、沙盤-思路 1） 開始前掛牌講解好的設計及槽糕的設計 能夠做好一件事情的前提是，要當事人能夠清晰“好”的判斷標準是什嗎？如果要超預期，首先要當事人瞭解到“期望”是什嗎？因此對於新員工或是設計經驗還不足的組員，能夠幫他們理清“怎麼樣的設計才算是一個好的設計”至關重要，這樣他們才能夠在正確的方向上投入他們的精力。而做這件事情的一個最好的辦法，就是開始設計前講解當前部門或公司裡的典型好的設計及壞的設計，如此這樣能夠讓大家在出發前得到一個方向上的共識。需要注意的是：槽糕的設計教育的意義往往用處比好的設計更大，因為好的設計需要積累和靈感，而槽糕的設計往往是可以避免的，一個中規中矩的設計不是一個很高的要求。
2）健壯性分析 對整個系統及關鍵模組做健壯性分析往往非常有必要。因為當系統或關鍵模組遇到異常往往會給客戶帶來巨大的影響，甚至是不可恢複的損失。健壯性分析的主要的方法是羅列可能遇到的異常情境及系統或模組應該做出的處理如何。 例如：給客戶提供使用者認證的模組應該至少應考慮如下異常情境： 1）當系統記憶體不足時，如何保證認證的優先順序 2）當進程出現假死後，如何檢查出來，防止長時間無法影響認證請求 3）程式崩潰時，如何快速恢複進程 4）裝置掉電或程式崩潰時，如何保證已經通過認證的客戶，不用全部重新認證 等等 3）擴充性分析 擴充性對於可預計會經常變化的業務模組尤為重要。達成好的擴充性的方法是通過“高內聚，低耦合”，將業務代碼和邏輯代碼分離來實現。好的擴充性可以大大降低後續的開發成本，對於持續化的項目非常重要。 例如：做一個抓包的協議分析軟體（譬如：wireshake），它的擴充性主要在於 1）後續可能會有更多的協議需要分析 2）後續可能會有更多的包分析結果的呈現方式 將這兩部分做成外掛程式式載入則是非常恰當的設計 4）可維護性分析（自動升級等） 可維護性設計通常包含兩部分; a、當系統或模組出現故障時是否容易排錯 這裡便要求系統或模組設計便提供方便的排錯方法，以上面提到的使用者認證為例: 例如：日誌分級，我們可以將使用者認證步驟分為12個步驟，並將每個步驟列印一條日誌，則方便追蹤問題。 記憶體列印，從後台輸入參數可以將指定使用者或所有使用者當前的記憶體狀態列印出來。
b、當系統或模組出現故障時，修複成本及風險是否可控 對於做產品的企業，一個故障排查出來後，通常外面在使用有問題的產品的客戶已經很多，這時候能否方便，快速的更新則非常重要。而能否方便和快速，取決於系統或模組的可維護性。 例如：一個產品本身有自動升級功能，當前排查的故障在於網路流量更新，導致外掛程式功能失效，同時主程式對外掛程式有強校正，這時候我們就可以快速得將新的外掛程式更新到網路上。
5）自動化測試分析 好的設計應該從一開始就為自動化測試進行考慮。一個系統或模組能夠方便編寫出準系統的自動化測試案例對於品質是件非常有益的事情。以協議分析軟體為例，我們可以設計如下的自動化方法： a、編寫一個工具可以產生指定協議的資料包 b、系統可以從檔案中直接load資料包，進行協議分析，並且自動校正是否與輸入期望的結果相符
6）方案選型評審 在設計開始之前，設計者應該將自己的想法及方案講述給專家，方案選型的文檔不要求複雜，可以是一封郵件，可以是一張圖，但是做了這件事，能夠避免設計大量返工。不得不說在工作中，經常發生一些諸如此類的感慨：“這件事怎麼想成這樣？” “這個肯定要重做了”等，這些都是沒有做好基本思路確認的問題導致的。
3、計劃制定
設計階段的評審工作量是非常大的，如果此時項目組需要很多外部專家的把關，則需要提前和這些專家協商出一個時間並統一制定出一份評審計劃，以防止評審時間延拖，導致下一個階段的工作無法完全啟動。
4、風險管理
1）太重技巧，過度設計 不得不說確實存在這樣一些同事喜歡濫用或是說過度追求設計模式，本來一個不複雜的模組，生生要套上幾個設計模式，搞得繼承，多態一大堆，代碼可讀性大大下降。所以這裡要需謹慎，事實往往證明經常夸夸其談設計模式、方法的人，通常或多或少都有過度設計的毛病。因此對不熟悉的組員，不能僅根據其言行，便主觀降低他的設計風險。
2）邏輯不周全，設計不足 相對於上個風險來說，對於一些設計經驗不足的同事，往往習慣把一件事情看得簡單化，導致編碼階段有很多意想不到的“驚喜”發生。經過好的詳設後編碼應該波瀾不驚，不能有大波大浪。對於這些組員時，有一個基本的設計方面的流程約束就顯得很必須了。 例如：詳設必須把主要的函數都畫出流程圖，經過評審。
5、團隊管理 1）新員工有師徒制 新員工往往沒有什麼設計理念，這時候不僅僅是評審和理清思路就可以解決問題的。這時候他們需要更加細緻的指導，因此給他們安排一個師父，就很必要了。
2）評審時指定負責的專家 大家很多時候對於和自己沒有直接關係的事情，會抱著得過且過的狀態。在設計文檔評審時，也有可能發生這樣的情況。因此在評審前明確哪個專家需要對設計負責，會對品質把關非常有益處。
3）嚴格執行計畫 經過估算後，設計階段已然有明確的計劃。制定專案計劃時我們要盡量民主，但是當計劃制定下來後，要維護其嚴肅性，不能一味的調整。 例如：有計劃延期，無法調整時需要加班解決，也是在情理之中的，否則專案計劃很快會成為一紙空文。
