【敏捷開發】論設計階段如何畫圖

    軟件開發中，分析和設計時，文檔的編寫和思想的交流，常常要繪製各類各樣的圖。

    相對於人類的天然語言，描繪複雜結構，圖具備直觀和總體的特徵，有着不可替代的表現力。

    軟件開發是創造性的勞動，開發人員幾乎在每一分鐘都要作出某些選擇，每個選擇都好像決定着最後的結果。

    繪圖的時候也是如此，腦中有完整或不完整的想法，要清晰的表現出來時至關不容易。

    事實上，許多老手都不會畫圖。

    在實踐的過程當中，總結了一些經驗，得出了一些結論。

1. 不畫沒有必要的圖

    若是簡單的文字就能說得很清楚，還畫圖幹什麼！

    對代碼級別的細節，不要畫圖來表現；

    不要藉助圖來讓你的文檔得變大；畫蛇莫要添足。

2. 忽略底層的細節

    軟件是一個多層的東西，一個圖只展示恰當抽象層次之上的細節。

    一個過細的圖，大量的信息會掩蓋真正重要的東西。

    好比：在一個流程圖上，不須要把「文件打開的錯誤判斷」也做爲一個分支畫在圖上，除非你「無聊到」要強調這個顯而易見的異常處理；

3. 圖不要太大

    若是一個圖上包含上百個對象，看起來不舒服，應該化整爲零，使用多個圖，每一個圖描述不一樣的部分。

4. 畫純種的圖

    圖傳遞的信息應該明確，無歧義。

    必定要明確圖中的各個組成元素都是什麼東西，整個圖要表現什麼。

    儘可能使用規範的圖。好比：

1. 流程圖中，應關注控制的傳遞，不要有從文件中讀取數據的數據流；
2. 軟件結構圖中，描述模塊之間的父子關係的同時，不要有模塊之間的數據流。
3. 常見到這樣的圖：在圖中既有「控制流」，也有「數據流」，不三不四，名之曰「示意圖」。
4. 交流時，這種示意圖在白板上隨手畫畫還能夠，而不該該出如今正式的文檔上。
5. 這些圖中的控制流，實是一個模糊概念，A->B能夠表示：1)A調用B，把控制傳遞給B；2）A啓動B,把控制傳遞給B；3）A向B傳遞一個控制信號；4)有一個第三者調用A完成後，立刻調用B。

5. 圖的佈局要簡潔，美觀

    我據說：書寫大幅的毛筆字，特別講究佈局。

    一樣道理，畫軟件圖，儘可能密度分佈均勻，減小連線的交叉。 

    爲了減小連線的交叉， 一樣的單元能夠在圖中出現屢次。

6. 其實並不須要完備的圖

    使用UML有三種方式：

1. UML as sketch(草圖)，使用不完備的圖進行系統某一部分或某一方面的內容進行交流；
2. UML as blueprint（籃圖），經過完備的UML圖表現詳細設計的全部決定；
3. UML as programming language，自動精確的UML圖，直接編譯成可執行的代碼（如今好像尚未實現）。

    Martin Fowler說：使用UML繪製草圖的人，真正關注UML的精髓（大師就是大師，說話就是不同）。

    所謂「不足勝有餘」，無論什麼圖，圖應該集中表現其關注的方面，恰當的忽略一些細節時必要的。

    類圖中，每每沒有必要包含類的全部函數合成員說明；

    在表現對象之間協做的順序圖中，大多時候也沒有必要表現存在的分支和循環。

7. 全部的規則都是用來遵照和打破的

    上面的全部道理，也並不是是不變的真理。

    可是，道理被打破之前，你應該瞭解它，熟悉它，批評它，忘記它（追求相似張三丰太極劍的境界）。

    古人云：事有反道而適權，僞經而和道者。

    笑傲江湖說：獨孤九劍，無招勝有招。

    蕭大俠：刪繁就簡，取精用宏。 

規勸朋友也規勸本身：連有招的境界還沒有達到，應該知道本身該作什麼。