一、前言
UML分析、模組化與設計 來自現實世界中的概念的抽象描述方法（摘取自《UML面向對象分析、模組化與設計（第2版）》）
就我對UML分析與模組化技術的認知，最早可追溯至2019年時的學習。也是在正式開發項目前，最後學習的一門設計類知識，我認為這是軟體開發者描述業務邏輯的最佳方式。
寫這篇部落格，我是希望在未來，我的同僚、合作者或者是交流人員，能夠擁有一定的模組化習慣。或者在互相關注之後，能夠知道我的程式設計習慣是怎樣的，能夠擁有更好的默契和愉快的合作。
二、代碼注釋與UML語言
（代碼注釋）
在項目編碼過程中，是必不可缺的一個環節，也是工作組中合作交流的關鍵。在中大型項目中，如果個人的代碼、算法、業務處理能力一般，但是注釋完善易懂的話，去請教大佬，還是會得到善意的幫助。就算在開發的過程中，遇到了bug，也能快速定位問題出現的位置。
但是大篇大論的語言表達總是蒼白無力，一個複雜的算法或者業務邏輯，是很難使用語言（漢語、英語等）去表達的。就算表達出來了，了解這個邏輯也需要花費一定時間。
我舉兩個例子。
（第一個）甲和乙是室友，甲回到寝室，突然告訴乙：我丢，今天在路上遇到了一個腿長、漂亮（帥氣）的女孩（男孩）。這麼說乙能夠了解，無非就是表達一個身材好、吸人眼球的女孩（男孩）。可以自動将思維帶入短視訊裡的某一個up主或者正能量。
/ *
* 實作資料按某個要求排列，并自動将使用者愛好優先排列在最上層。（優先級：使用者愛好>某個要求)
* @參數a （什麼意思，什麼作用，有沒有關鍵作用）
...
* @developer [開發者]
* @see [相關類/方法]
* @since [産品/子產品版本]
* @deprecated
*/
public ...
（第二個）甲、乙、丙是室友，甲和乙回到寝室，甲對丙說：今天我們兩在商業街看到一個小姐姐，身材目測無限接近于黃金比例（0.618）、微胖、事業線驚人。可惜穿搭上有所欠妥，沒有完全展示出她的優點，但氣質彌補了這一問題（然後又描寫氣質）。這樣表達也确實詳細，但是關注點太多，腦海生成出一個這樣的人，就比較緩慢。這時乙拿出手機将拍到的照片給丙看，這一切就明朗了（現實生活中可不能這麼來，乙的行為是錯誤的，應該大膽上去加微信，大膽通路空間），而個照片可以看做是UML分析、模組化與設計。
/ *
* 調用了（方法1）（方法2）能夠實作對錄影機内頭像的實時捕獲，并同步生成什麼樣的人臉資料，這個資料要進行什麼樣的操作和導出，才能完成對比
* @參數a （什麼意思，什麼作用，有沒有關鍵作用）
* @檔案b 資料是什麼類型 識别轉換的資料排列方式
....
* @developer [開發者]
* @see [相關類/方法] [class1.java、class2.java、class.java]
* @since [産品/子產品版本]
* @deprecated
*/
public ...
（UML分析、模組化與設計）
一般執行于項目編碼之前，是對一個子產品（功能）的具體（圖像流程）分析與描述。開發過程能否順利，測試結果能否過關，憑借于UML的設計嚴謹程度。當然也有一些厲害的、業務邏輯熟練的開發工作者，對于模組化隻是一張草圖而已，甚至模組化軟體都不用打開，就能完整的開發出一個功能來的，也是非常常見。
就我22年2月份找的那份工作，一個負責金融交接功能子產品的小組，全小組就一個人。非常厲害的一位大佬，聽說是上海回來，之後回不去了，隻好在本地老家就業。在一次聚餐時，因為兩個人都吃不了辣（我是因為打了疫苗，大佬是因為習慣了上海的飲食），有幸結識了這位大佬，進行了技術交流。聽他說，他處理這套邏輯已經7,8年，相容不同的開發架構也有五、六種，反正對業務邏輯非常熟悉，全公司就他一個人熟悉金融交接，注釋随便寫，模組化就算了。
如果在我的組裡，組長告訴我哪個功能子產品出現了bug，需要我去修改一下。注釋和模組化描述不清，我可能會出于行内禮貌，重新定義一個方法、接口去取代他那個有問題的子產品。但如果全是黑黢黢的代碼，不好意思，請這位靓仔（靓女）和我進行工作銜接時，注意頭上那所剩不多的幾根毛的存在意義。當然替換了新方法，有可能回出現連鎖反應，導緻其他方法出現故障，這個時候還是要盡量去重新定位和觀察被取代的代碼。貿然将自己的方法交上去，導緻了這個問題，一般公司會完完整整的将問題全算你的頭上。如果隻是重構，問題沒有得到解決，可以拖着這位同僚來分擔火力，一切的一切都是他不寫注釋、不模組化而導緻我對這個問題不清楚。
三、開發工作中的UML
根據軟體三大生存周期：軟體定義時期、軟體開發時期和軟體維護時期。
UML分析、模組化與設計的工作處于軟體定義後期和開發前期，分布于項目說明書的需求分析、總體設計、概要設計三個标題中。主要作用是為了使用者（上司）能夠淺顯看懂内部邏輯（拿了工資，幫他實作了這個功能沒，一般都是看頭看尾看大概）、開發期同僚相容其他功能、維護期維護人員能夠快速了解内部邏輯。