程序員的自我修養系列(四):圖形化表達

前言

對程序員來講,咱們不少時候更專一於寫代碼,可是一個項目裏代碼只是整個交付的一部分,需求、設計、溝通不少時候比代碼更重要,由於若是沒搞清 "WHAT TO DO", 那麼咱們 "HOW TO DO" 是沒有意義的。網絡

根據個人經驗,大部分程序員在溝通這塊兒是須要提升的,而項目中不少問題,都是由溝通問題形成的,而這種問題的主要變現有多種,一種是咱們不知作別人說什麼,還有一種是別人不知道咱們說的是什麼。而文字不少時候是形成歧義的一個很重要的因素。架構

不少時候,我都推薦你們能用圖形表達的,就不要用文字表達,緣由以下:微服務

釐清思路

幫助咱們本身想清楚。若是咱們想用圖形表達,那麼咱們本身必須想清楚,否則圖形就畫不下去。工具

加速溝通反饋

圖形是咱們思想的一個簡化模型的體現,能夠去掉不少干擾信息,讓咱們快速理解,從而加快了溝通反饋速度測試

減小歧義

不少圖形都是「通用語言」,就是已經在業界達成了共識,不用過多解釋。設計

人腦更擅長理解圖形

相對於文字,圖像有畫面感, 人腦更擅長記憶圖像。3d

圖像信息容量大

不少東西,若是咱們用文字,須要幾十頁的描述,而用圖可能一張紙就表達了,這給交流帶來了極大的便利性。日誌

程序員須要掌握的經常使用圖形

咱們知道不論是什麼軟件開發方法,傳統瀑布,仍是如今的敏捷開發,都離不開需求分析、設計、開發、測試等等。blog

而如今愈來愈強調 「全棧程序員」 ,也就是極可能,你一我的要作一個項目,並且一杆子擼到底。因此咱們必須掌握一些經常使用的圖形表達工具。

在敏捷開發裏,你們都用用戶故事來表示需求,可是我老是以爲光用戶故事感受比較散,很難讓人對總體有個瞭解,我以爲下面兩種圖,對錶示系統功能頗有幫助。

需求相關

用例圖

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

主要包括,角色(Actor),功能(Use Case),以及功能間是擴展關係(Extends) 仍是包含關係(Includes)

功能結構圖

功能結構圖,能夠清晰的表達,功能之間的分組,好比大的功能塊下的小功能,經過這樣分組,有的時候咱們很容易把其中一個分支剪出來作一個子項目或者微服務。同時咱們也能夠根據不一樣的色塊來標註功能的優先級。

腦圖

有的時候,在早期階段,咱們主要收集需求的時候,腦圖給咱們帶來了不少的靈活性,尤爲是如今不少腦圖軟件,很方便的插入和修改。

設計相關

分層架構圖

這是咱們最經常使用到的,這種圖形很簡單,基本用方框和線條就能夠了,主要表達層次關係以及相互依賴關係,你們常常見到的三層或者多層圖就是這樣的。

三層架構圖

每層裏面包含多個部分

包含通用組件,好比多個層裏會用到的日誌,異常模塊等

跨層調用圖

上面分層架構,通常都不會跨層調用,而如今有一些架構,好比領域驅動,整潔架構,六邊形等等均可以跨層調用,這類架構都強調領域核心的概念,就是外層能夠跨層調用內層,但通常內層不容許調用外層。基本上都是強調隔離出容易變化的文件,網絡和外部依賴,以業務爲核心。這類圖,通常都是圓形圖。

整潔架構

六邊形架構

交互相關

系統之間交互圖

這類圖,通常表示不一樣子系統直接的交互關係,好比微服務

流程圖

不少時候,咱們想表達一些業務的流程,好比若是XXX,那麼就YYY, 或者A完成就開始B,而後開始C等,那麼流程圖就是咱們必需要掌握的

泳道圖

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

最後

咱們須要的是要掌握的是用圖來展現咱們的想法,不要花太多時間讓圖很漂亮,好比色彩上。 大部分的圖基本上均可以用筆能夠很快在紙或者白板上畫出來,或者Word通常就能夠了。

固然,如今也有不少收費或者免費的軟件,當你熟練了要表達的內容和結構後,使用這些軟件就很容易。

相關文章
相關標籤/搜索