程序員能夠用思惟導圖作什麼

爲何一開始會想寫這個，相信全部java學習者一開始都會接觸到一個東西，UML（Unified Modeling Language）。 UML是一種統一建模語言，爲面向對象開發系統的產品進行說明、可視化、和編制文檔的一種標準語言。UML圖，包括用例圖、協做圖、活動圖、序列圖、部署圖、構件圖、類圖、狀態圖。 相信我不用過多解釋，應該都有接觸過，可是我想問的是，你們平時工做有用到這個玩意嗎。對於大廠我不清楚，但對於一直在小廠的我，確實沒有用到過，甚至連念頭都沒有產生過。爲何，理由和藉口一堆，項目小型用不上（實際上任何項目若是想用均可以），沒法在開始正式編碼前想清楚全部邏輯，佛系寫碼，時間不容許，弄起來麻煩等等。下面是一個示例

講真我本身是接受不了，可能從入行一開始就沒有養成這個習慣，實際工做中，項目迭代快，小組人員能力良莠不齊，也無法做爲強制要求，大多數狀況下就是指派任務，而後自由佛系發揮，項目跑得起來測試能過就行。或許穩定的後臺服務須要這個，而多變的APP用這個神煩？

但最近整理一個Android項目，發現有一個痛點，在不熟悉的狀況下，如何掌握頁面間的關係，好比某某界面經過哪裏跳轉到哪裏，每次後端或者測試問到某個頁面用到什麼，從哪裏過去時，總是先全局搜索頁面關鍵詞（由於對項目不熟），找到這個頁面，再去找其中的邏輯，很麻煩。因此突發奇想，若是本身先整理一遍頁面關係，記錄下來生成獨立文檔，之後不就好定位了，由於全部的頁面在初次開發時，邏輯序列由產品經理定義，相比定義類與類的關係，類該有的屬性，簡單使用UML來表述頁面的關係是否是感受輕鬆多了。在開發階段就能夠順手添加，好比

這樣既記錄了頁面所屬類，也記錄了邏輯流向。但本身折騰了一下，發現有點不三不四，沒用到UML的重點(模型和視圖)，只是用在這個功能的話，徹底不須要用UML。改用思惟導圖來作，隨時添加刪除，方便好作還好看，雖然個人圖示醜了點，例如

這麼一搞是否是感受清楚多了，並且增刪改容易，沒什麼門檻，幾乎大部分在線的思惟導圖工具都有小組協做模式，開發初期各自按本身的分到的需求順手添加，不衝突，並且有序的導圖，對新人友好，剛入職就能快速定位所屬業務頁面，快速上手。

總的來講，我以爲忙活這麼一出，一個是方便之後查找，還能縷清本身產品業務的主體邏輯，並且上述圖示是能夠強化增長元素的，好比光用名字本身也不清楚說的是哪一個頁面的話，能夠添加詳細的應用截圖說明，這樣會更明瞭。總之思惟導圖，用處不限於這個，但至少簡單的使用其特色，對於開發來講，小助手性質吧。