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）嚴格執行計劃 ? ?經過估算后，設計階段已然有明確的計劃。制定項目計劃時我們要盡量民主，但是當計劃制定下來后，要維護其嚴肅性，不能一味的調整。 ? ?例如：有計劃延期，無法調整時需要加班解決，也是在情理之中的，否則項目計劃很快會成為一紙空文。