對程序員來說，我們很多時候更專注于寫代碼，但是一個項目里代碼只是整個交付的一部分，需求、設計、溝通很多時候比代碼更重要，因為如果沒搞清 "WHAT TO DO", 那么我們 "HOW TO DO" 是沒有意義的。 根據我的經驗，大部分程序員在溝通這塊兒是需要提高的，而項目中很多問題，都是由溝通問題造成的，而這種問題的主要變現有多種，一種是我們不知道別人說什么，還有一種是別人不知道我們說的是什么。而文字很多時候是造成歧義的一個很重要的因素。

前言

對程序員來說，我們很多時候更專注于寫代碼，但是一個項目里代碼只是整個交付的一部分，需求、設計、溝通很多時候比代碼更重要，因為如果沒搞清 "WHAT TO DO", 那么我們 "HOW TO DO" 是沒有意義的。

根據我的經驗，大部分程序員在溝通這塊兒是需要提高的，而項目中很多問題，都是由溝通問題造成的，而這種問題的主要變現有多種，一種是我們不知道別人說什么，還有一種是別人不知道我們說的是什么。而文字很多時候是造成歧義的一個很重要的因素。

很多時候，我都推薦大家能用圖形表達的，就不要用文字表達，原因如下：

厘清思路

幫助我們自己想清楚。如果我們想用圖形表達，那么我們自己必須想清楚，不然圖形就畫不下去。

加速溝通反饋

圖形是我們思想的一個簡化模型的體現，可以去掉很多干擾信息，讓我們快速理解，從而加快了溝通反饋速度

減少歧義

很多圖形都是“通用語言”，就是已經在業界達成了共識，不用過多解釋。

人腦更擅長理解圖形

相對于文字，圖像有畫面感， 人腦更擅長記憶圖像。

圖像信息容量大

很多東西，如果我們用文字，需要幾十頁的描述，而用圖可能一張紙就表達了，這給交流帶來了極大的便利性。

程序員需要掌握的常用圖形

我們知道不管是什么軟件開發方法，傳統瀑布，還是現在的敏捷開發，都離不開需求分析、設計、開發、測試等等。

而現在越來越強調 “全棧程序員” ，也就是很可能，你一個人要做一個項目，而且一桿子擼到底。所以我們必須掌握一些常用的圖形表達工具。

在敏捷開發里，大家都用用戶故事來表示需求，但是我總是覺得光用戶故事感覺比較散，很難讓人對整體有個了解，我覺得下面兩種圖，對表示系統功能很有幫助。

需求相關

用例圖

用例圖主要是從系統使用者的角度來描述每個角色可以使用哪些功能。

主要包括，角色(Actor)，功能(Use Case)，以及功能間是擴展關系(Extends) 還是包含關系(Includes)

功能結構圖

功能結構圖，可以清晰的表達，功能之間的分組，比如大的功能塊下的小功能，通過這樣分組，有的時候我們很容易把其中一個分支剪出來做一個子項目或者微服務。同時我們也可以根據不同的色塊來標注功能的優先級。

腦圖

有的時候，在早期階段，我們主要收集需求的時候，腦圖給我們帶來了很多的靈活性，尤其是現在很多腦圖軟件，很方便的插入和修改。

設計相關

分層架構圖

這是我們最常用到的，這種圖形很簡單，基本用方框和線條就可以了，主要表達層次關系以及相互依賴關系，大家經常見到的三層或者多層圖就是這樣的。

三層架構圖

每層里面包含多個部分

包含通用組件，比如多個層里會用到的日志，異常模塊等

跨層調用圖

上面分層架構，一般都不會跨層調用，而現在有一些架構，比如領域驅動，整潔架構，六邊形等等都可以跨層調用，這類架構都強調領域核心的概念，就是外層可以跨層調用內層，但一般內層不允許調用外層?；旧隙际菑娬{隔離出容易變化的文件，網絡和外部依賴，以業務為核心。這類圖，一般都是圓形圖。

整潔架構

六邊形架構

交互相關

系統之間交互圖

這類圖，一般表示不同子系統直接的交互關系，比如微服務

流程圖

很多時候，我們想表達一些業務的流程，比如如果XXX，那么就YYY, 或者A完成就開始B，然后開始C等，那么流程圖就是我們必須要掌握的

泳道圖

主要用來表示不同角色或者不同組件之間的交互的順序。

最后

我們需要的是要掌握的是用圖來展示我們的想法，不要花太多時間讓圖很漂亮，比如色彩上。 大部分的圖基本上都可以用筆可以很快在紙或者白板上畫出來，或者Word一般就可以了。

當然，現在也有很多收費或者免費的軟件，當你熟練了要表達的內容和結構后，使用這些軟件就很容易。