架構(gòu)設計50-架構(gòu)師技術(shù)01-怎么畫架構(gòu)圖

架構(gòu)設計系列文章，請參見連接。

0. 前言

0.1 業(yè)界現(xiàn)狀

在軟件業(yè)界有一個說法：PPT架構(gòu)師。PPT架構(gòu)師的由來肯定是因為架構(gòu)師有很大一部分工作在做PPT或者在講PPT。一方面“畫圖”在架構(gòu)師的工作占比中已經(jīng)非常大了。另外一方面也代表著架構(gòu)師畫圖能力代表著成為架構(gòu)師所必要的能力。

0.2 架構(gòu)師必不可缺

軟件研發(fā)最簡單的理解是：使用技術(shù)解決業(yè)務問題。而對于技術(shù)的使用過程是怎樣的過程是需要架構(gòu)師進行管理的，并在軟件系統(tǒng)發(fā)展過程中對于技術(shù)治理工作還是需要架構(gòu)師處理的。架構(gòu)師公司發(fā)展過程中還需要將公司的發(fā)展納入到技術(shù)演進過程中。所以說架構(gòu)師在公司發(fā)展過程中是必不可缺的。

0.3 本文概要

鑒于此架構(gòu)師用“圖”來描述系統(tǒng)工程規(guī)范、技術(shù)規(guī)范、業(yè)務轉(zhuǎn)換架構(gòu)過程、架構(gòu)、流程等等內(nèi)容，并將“圖”交付給團隊進行實施。在”架構(gòu)設計“過程中這么大的畫圖工作量，架構(gòu)師肯定要明確的知道：

  • 為什么要畫圖？
    說明畫圖是為了解決什么問題的。
  • 什么是架構(gòu)圖？
    說明什么樣的圖是架構(gòu)圖。
  • 怎么畫架構(gòu)圖？
    說明以什么樣的過程，什么樣的規(guī)則可以畫出好的圖。
  • 用什么畫架構(gòu)圖？
    說明用什么工具什么樣的圖比較合適。
  • 總結(jié)一下
    最后討論一下：畫圖是一種技能嗎？

1. 為什么畫架構(gòu)圖？

很多研發(fā)人員對于軟件的認知：軟件開發(fā)就是在處理細節(jié)。處理各種各樣的細節(jié)，在軟件研發(fā)的各個階段。靠人把所有的細節(jié)全部記??？還是靠某種機制將細節(jié)記錄下來？這只是為什么要畫架構(gòu)圖中的一個最簡單的原因，其他原因可以看下面。

1.1 為什么要畫圖

畫圖其實是承載了設計中的信息，以圖的形式進行傳遞。那為什么很多團隊還是不進行設計呢？

1.1.1 為什么不設計？

  • 設計是反人類的。
    就像學習是反人類的一樣。很多人理不清到底要做什么，只有在實現(xiàn)過程遇到了才能知道有這個問題，并解決這個問題。
  • 容易被人挑戰(zhàn)
    沒有設計方法、不體系化、遺漏等問題使提出的解決方案有很多點都會被挑戰(zhàn)。
  • 意識到問題是問題
    沒有設計大家也過的挺好的，為啥要設計？所以意識到?jīng)]有設計是個問題是很很重要的問題。沒意識問題的存在就永遠解決不了問題。

1.1.2 為什么要設計？

戰(zhàn)術(shù)編程的結(jié)果

  • 戰(zhàn)術(shù)編程的問題
    FaceBook 是一個鼓勵戰(zhàn)術(shù)編程的公司。原公司座右銘："快速行動，打破常規(guī)"，后來意識到問題改成了"以堅實的基礎設施快速發(fā)展"。

    戰(zhàn)術(shù)編程的問題在于它是短視的。-《軟件設計哲學 3.1 戰(zhàn)術(shù)編程》

  • 識別風險，理清計劃
    前面的文章中有討論為什么要設計，這里也是參照02.終極問題--為什么要架構(gòu)設計？。

    一個公司可以用任何一種方法取得成功。然而，在一家關(guān)心軟件設計并擁有干凈代碼庫的公司工作要有趣得多。-《軟甲設計哲學 3.4 創(chuàng)業(yè)與投資》

1.2 系統(tǒng)復雜度從哪里而來？怎么解決？

1.2.1 系統(tǒng)復雜度從哪里而來？

軟件開發(fā)就是在處理細節(jié)？
  • 業(yè)務本身復雜度
    為了創(chuàng)建真正能耐為用戶活動所用的軟件，開發(fā)團隊必須運用一整套與這些活動有關(guān)的知識體系。所需知識的廣度可能令人望而生畏，龐大而復雜的信息也可能超乎想象。那怎么才能讓實現(xiàn)過程中一直都能記清之前的想法是什么樣的？
  • 演化過程中的復雜度
    在軟件系統(tǒng)的發(fā)展過程中，在新增或修改業(yè)務時未進行良好的設計的業(yè)務進入到系統(tǒng)后就會帶來混亂。這種混亂會不斷的在技術(shù)組件間傳播擴散，甚至可能傳播到系統(tǒng)之外。

1.2.2 怎么解決？

cynefin問題認知框架就是用來解決復雜問題的。主要的方式就是將復雜問題使用各自對應的方法將問題變?yōu)楹唵螁栴}，然后再解決簡單問題。


cynefin認知框架

在通過對微服務大泥球的整理與處理之后，可以看到與之前的大泥球有很大的不同。

設計后的結(jié)果

1.3 細節(jié)重要還是整體重要？

上一節(jié)已經(jīng)討論到了軟件中有很多很多的細節(jié)，細節(jié)導致了復雜度指數(shù)級的提升。那么解決問題的時候就需要關(guān)注并解決所有的細節(jié)嗎？

1.3.1 還原論vs整體論=系統(tǒng)論

系統(tǒng)論

解決復雜領域的問題，就不能單純靠還原論的解題思路。一個復雜的動態(tài)系統(tǒng)整體遠大與構(gòu)成該系統(tǒng)的各個部分之和，同理一個動態(tài)系統(tǒng)的問題也不能單純通過分而析之的方式來解決。

1.3.2 道法術(shù)勢器

不同層次的軟件組成

我們提供的軟件產(chǎn)品在不同的層面為不同的人提供用戶不同的解決方案。在提升軟件交付效率的領域中，我們?nèi)绻皇翘峁〤I/CD工具是可以解決用戶的問題，但如果提供解決問題的方法論才能讓用戶更好的使用應用我們的工具。

1.3.3 重要的是？

需要以系統(tǒng)化的方法認知細節(jié)和整體。這樣才能在不同的層面上同時獲取成功。

1.4 “設計”的理解一致嗎？

1.4.1 認知過程

鄧寧-克魯格心理效應

根據(jù)鄧寧-克魯格心理效應：對于同一件事情，人的認知也是經(jīng)過這個過程的。從愚昧山峰到大師級別看到的內(nèi)容做的內(nèi)容都是一樣的，但是對于同一件事情的背后認知是不一致的。例如：敏捷的形式中有每日晨會，對于剛接觸和有深度認知的人對于晨會的認知是不一樣的。

1.4.2 智慧形成過程

數(shù)據(jù)->信息->知識->智慧

認知過程中將數(shù)據(jù)變?yōu)橹腔鄣姆绞讲煌瑢е旅總€人的對同一件事的認知不同。這可以很好的解釋不同的人對同一件事的不同側(cè)面的認知深度都是不同的。

1.4.3 理解一致嗎？

在不同的鄧寧-克魯格階段，不同的智慧形成過程。再加上一個人的精力是有限的，并且每個人的興趣內(nèi)容也不相同。所以會形成雖然大家都是Java后端軟件研發(fā)，有些對Java線程比較懂，有些對數(shù)據(jù)庫原理比較懂。更不用說對于業(yè)務的理解是不可能達成一致的。就需要以某種形式讓軟件研發(fā)需求，實現(xiàn)形成某種統(tǒng)一的認知。

1.5 業(yè)務到實現(xiàn)之間的轉(zhuǎn)換怎么才是好的?

從軟件需求到軟件實現(xiàn)之間有多種轉(zhuǎn)換方式，那種方式是最好的？那種方式可以盡量的提升效率，降低成本都是需要在設計階段確認的。

  • 管理復雜性，效率最大化
    需求->技術(shù)

    在業(yè)務需求和系統(tǒng)實現(xiàn)之間做權(quán)衡，從而來應對未來變化的不確定性。無論是何種變化，在我看來架構(gòu)都是在不斷的判斷和取舍。而變化和不確定性導致權(quán)衡取舍，再不進行說明的情況下很難讓人理解為什么這樣做？
  • 架構(gòu)是系統(tǒng)實現(xiàn)的藍圖
    設計

    僅憑程序員自己腦子里的模糊設想，也許你可以像傳統(tǒng)手藝人一樣獨自創(chuàng)造出一些美好有用的小東西（比如 Linux 0.01 版本），但不太可能以工程的方式協(xié)同一個團隊共同建造起一個與摩天大樓規(guī)模類似的復雜軟件系統(tǒng)（比如現(xiàn)代的 Linux 系統(tǒng)）。

1.6 結(jié)論：

解決系統(tǒng)復雜度最好的方式是簡化，擁有從全局的整體到局部的細節(jié)的上下統(tǒng)一觀點，并理解團隊中的成員對業(yè)務的、技術(shù)的理解都是不一致的。才能比較好的理解架構(gòu)的作用是管理復雜度，系統(tǒng)藍圖的作用。

1.6.1 控制復雜度

軟件開發(fā)本質(zhì)上是復雜的，所以首要任務就是管理復雜度！《人月神話》

當復雜性失去控制時，開發(fā)人員就無法很好的理解軟件，因此無法輕易、安全地更改和擴展它。而好的設計可以為開發(fā)復雜特性創(chuàng)造更多機會。《領域驅(qū)動設計：軟件核心復雜性應對之道》

架構(gòu)設計的目的是為了解決軟件系統(tǒng)的復雜度帶來的問題，對系統(tǒng)的高可用、高性能、可擴展、安全、伸縮性、簡潔等做系統(tǒng)級的把握。《架構(gòu)即未來》

成為一名優(yōu)秀的軟件設計師的第一步是認識到僅僅為了完成工作編寫代碼是不夠的。為了更快地完成當前的任務而引入不必要的復雜性是不可接受的。最重要的是這個系統(tǒng)的長期結(jié)構(gòu)。《軟件設計哲學》- 3.2 戰(zhàn)略規(guī)劃

設計和編碼混合在一起的風險就是可能沒設計就編碼了——一旦出現(xiàn)這種情況，演進式設計就可能脫軌并失敗。《設計已死》

如果你在開發(fā)小組，那么你可以通過代碼來判斷是不是有設計。如果代碼越來越復雜，越來越難搞，那么就是設計沒有做足。但杯具的是這個觀點比較主觀。我們沒有一個可靠的標尺來給我們一個客觀的衡量設計好壞的方法。《設計已死》

1.6.2 形式是什么？

一圖勝千言

一圖勝千言，用圖來傳遞信息是最快的方式。并且可以傳遞更多的信息。但在此過程中很多時候都會想到MDD(模型驅(qū)動開發(fā)），MDD是被生成代碼所耽誤的一種開發(fā)方法。在后面會討論各種畫圖方法論來說明并不是只有UML一種畫圖方式。使用圖的方式進行大部分信息的展示，但還是需要配合圖進行一些文字描述來說明圖的意圖。

2. 什么是架構(gòu)圖？

架構(gòu)設計有多種方法論，而撐起這些方法論的就是其下各種各樣的圖。這些圖描述方法論中所特有的內(nèi)容，那么這些架構(gòu)設計方法論中會將軟件所有細節(jié)都落到圖上嗎？基于這么多的架構(gòu)設計方法論，我們最后的架構(gòu)圖有應該是什么？

2.1 有哪些圖可以表示架構(gòu)？

2.1.1 現(xiàn)有的圖分類

圖分類

上圖中是簡單的分類，因為每種圖都不是在一個過程中會使用到。而且還有很多圖未分類進入軟件工程中：

2.2.2 (標準)架構(gòu)描述

在標準組織ISO/IEC/IEEE 42010:2011 A Conceptual Model of Architecture Description中描述了架構(gòu)所組成的元素。在架構(gòu)圖中也需要包含這些元素。

The Core of Architecture Description

2.2 方法論

架構(gòu)一大目標就是為了讓開發(fā)團隊快速達成共識。而這個目標就需要有具體的方法才可以達成。
例如架構(gòu)設計的Togaf中的adm進行設計，C4的設計方法，DDD中實踐方法DCI，還有面面俱到的RUP，還有4+1視圖法，所以要具體選擇那種呢？

架構(gòu)方法論分類

每種方法論都有優(yōu)點，而且都有它所適用的場景。在阿里的從方法到思維：什么是應用邏輯架構(gòu)的正確姿勢？（上）中描述了從需求到代碼實現(xiàn)的整個過程。TOGAF的典型EA的方法論，RUP+”4+1視圖“發(fā)的面向?qū)ο蠓治龊驮O計方法。也有從架構(gòu)的方面考慮的：結(jié)構(gòu)+架構(gòu)決策+設計原則+架構(gòu)特征。還有其他各種各樣的架構(gòu)過程，也伴隨著不同的方法。例如：1.3.3. Refined Architecture階段:落地的5視圖方法

2.2.1 設計方法對應的圖

先將方法論進行歸類，方面在后面的文章中進行細節(jié)的分享。并從方法論的層面上了解架構(gòu)設計方法論有多少種：


方法論

另外還有：ADL、SysML、AADL、BPMN等

2.2.2 RUP

統(tǒng)一軟件開發(fā)過程和4+1視圖出現(xiàn)在差不多的時間段。所以在初期的時候就有uml和4+1視圖的結(jié)合，這里將圖轉(zhuǎn)換一下形成下圖：


uml和4+1視圖

讓4+1視圖和UML結(jié)合才能形成比較完善的架構(gòu)圖的原因是UML都在細節(jié)，對于架構(gòu)設計的上層結(jié)構(gòu)的描述力不足所以需要結(jié)合4+1視圖的視角來描述上冊。這樣才可以形成比較完善的架構(gòu)描述方法。

2.2.2.1 UML的問題

Martin Fowler在一篇文章中說明UML的三種用法：草圖、藍圖與編程。那我們分析一下這三個角度：

  • 草圖
    草圖是用來大概描述系統(tǒng)結(jié)構(gòu)、設計結(jié)構(gòu)的。來傳遞概要性的概念，但是現(xiàn)在UML發(fā)展的越來越復雜越來越細化的情況下很難描述一個概要性的信息。
  • 藍圖
    藍圖描述整體最終的架構(gòu)、架構(gòu)的愿景。而UML的發(fā)展是1.0是9中圖到2.5的時候已經(jīng)變成了12中23個了。UML發(fā)展成描述更多的細節(jié)，捕捉更多的細節(jié)。失去了對于整體的描述方法。
  • 編程
    現(xiàn)在的變成要不用MVC要不用代碼從生成器，使用設計模式的時候都很少。所以說對于快速變化的業(yè)務與系統(tǒng)來說花大力氣畫出來的UML圖在三天后可能都不適用了，這種大投入小回報的方式是違反了敏捷背后的原則的。

并不是反駁Martin Fowler，只不過想說UML點錯了技能樹沒有辦法很好的反應現(xiàn)在軟件研發(fā)過程了。有一些大神通過各種方式也說明了UML的問題例如《UML 怎么就真“掛”了？ 2021 年 5 月 09 日》，《UML三大硬傷-程序員雜志2002年第5期》中描述了UML的問題：上不著天、下不著地、一盤散沙。還有知乎上的大神對于UML的討伐，我這里整理一下：

  • 過于復雜：圖形化是為了傳達信息，復雜之后就很難有效的傳達信息
    所有的圖都是針對某一個方面的細節(jié)的。沒有一張圖可以表示架構(gòu)所要的全局。
  • UML試圖去捕捉軟件中的每一個細節(jié)。
    1. 但是根據(jù)人的認知過程來說的現(xiàn)在認為的正確細節(jié)在過不了多長時間之后就會變的錯誤。
    2. 并且不能適應現(xiàn)在敏解式“擁抱變化”的情況。
  • 圖形的意義不明確導致畫出來的圖會有各種歧義，需要不斷的解釋與說明才可以完成業(yè)務。
    1. 主要是因為圖形太多，符號太多。導致符號體系中有重復覆蓋相同功能的問題

2.2.3 C4

C4

C4補充圖

C4 模型是一種“抽象優(yōu)先”（abstraction-first）的架構(gòu)制圖方法，它也是受前面的 UML 和“4+1”視圖模型所啟發(fā)，但相對而言要更加簡單和輕量，只包含少量的一組抽象和圖表，很易于學習和使用。

2.3 DDD

經(jīng)典DDD中沒有說明領域模型應該怎么畫圖，但是它是一個不可忽視的架構(gòu)設計方法論。在其他的DDD的文檔中也有很多方式進行領域驅(qū)動的描述。

2.3.1 DDD原模型

戰(zhàn)術(shù)設計+戰(zhàn)略設計

領域分層

2.3.2 DDD建模過程

經(jīng)典DDD中更多的是說明概念，對于它應該怎樣實施，怎樣完成這個過程。DDD很難學習也是基于此，只有概念沒有動手的方法。其實DDD的實施過程也是需要畫圖的。

ddd starter modelling process

上圖是從DDD入門建模過程拉過來的。

DDD 建模工作坊指南

上圖是從DDD 建模工作坊指南拉過來的

2.4 面向過程

面向過程

這里想說明的是DFD是一種分層圖，在不同的層次中有不同的細節(jié)內(nèi)容。魚骨圖很多時候用來做根因分析，軟件故障的分析可以用魚骨圖來完成。

2.5 EA

企業(yè)架構(gòu)從上到下描述了軟件的整體過程。他不止描述實體的生命周期，它還會表述系統(tǒng)、平臺的生命周期管理。


TOGAF ADM
MEAF

2.5.1 EA-TOGAF ArchiMate

TOGAF圖例

上圖是從ArchiMate教程和ArchiMate示例中抓取過來的。

2.6 總結(jié)

在圖形分類、標準定義兩個側(cè)面說明了架構(gòu)設計和畫圖是有很多中方法論的，然后討論了五種體系化的方法論。那么我們看過了這么多定義和方法論之后再進行分析（回歸本源）得出結(jié)論（元元模型）。

2.6.1 回歸本源

2.6.1.1 系統(tǒng)之美

有一本書叫做《系統(tǒng)之美》討論了系統(tǒng)的定義：

系統(tǒng) = 結(jié)構(gòu) + 關(guān)系 + 目標/功能

2.6.1.2 ISO/IEC 42010:20072

標準化組織也定義了類似的內(nèi)容：


2.6.1.3 架構(gòu)藍圖--軟件架構(gòu) "4+1" 視圖模型


從幾個方面抽象出架構(gòu)圖到底應該有哪些內(nèi)容組成，必須包括哪些內(nèi)容。上圖是從4+1視圖的第一篇論文中翻譯過來的內(nèi)容：Architectural Blueprints—The “4+1” View Model of Software Architecture

2.6.2 元元模型


從組成、視角、分層這幾個角度可以描述一個架構(gòu)，然后再加上”時間“這個維度形成4維空間來描述架構(gòu)可以以一種比較完備的方式描述清晰一個可靠的架構(gòu)。

2.7 結(jié)論

最后說明一下各種各樣的方法論存在并不代表著混亂，而恰恰代表著架構(gòu)設計方法論的繁榮發(fā)展。但每個方法論都代表著一個方法論的應用場景。所以需要進行權(quán)衡，選擇合適的。

2.7.1 權(quán)衡

合適的是最好的，不是最新的是最好的。很多研發(fā)人員因為各種原因喜歡新的技術(shù)，新的工具，新的方法論。在我看來這么做就代表著決策方式就看那個新就用那個，而不是進行實際的分析之后再進行決策。這樣的決策過程肯定是有問題的。所以才有了權(quán)衡。

2.7.2 副作用

工程化、系統(tǒng)、嚴謹、完整、標準。只要有圖就很好，有了圖就可以更好的與團隊進行溝通。就可以說明系統(tǒng)的規(guī)范、計劃、評審等等內(nèi)容。

2.7.3 架構(gòu)圖特點

從各種方法論就總結(jié)出架構(gòu)描述的方法：組成元素、多視角、分層次、輔以文字描述。

3 怎么畫架構(gòu)圖？

有架構(gòu)圖的組成元素、視角、分層就可以畫出架構(gòu)圖嗎？

3.1 怎么畫圖？


畫圖是不是一種技術(shù)?前面那么多方法論都有規(guī)范的圖的意義，圖的畫法規(guī)范等等。那么畫圖是一種技術(shù)嗎？是不是學過這些方法就可以有實際的實踐意義？并不是，還是需要有自己的一些做事規(guī)范來規(guī)范化自己的輸出，提要自己的職業(yè)化能力。
這里畫圖的方式以：流程+規(guī)則->圖即代碼

3.2 流程

架構(gòu)設計流程用來說明在不同的階段應該畫什么樣的圖，設計階段說明主要進行設計階段。

3.2.1 設計流程


3.2.2 設計階段


ArchiMate，DDD設計都包含了從概要到詳細的設計過程，所以這里只是區(qū)分了uml+”4+1視圖“的方式。

3.3 規(guī)則

畫圖從哪里畫？圖要覆蓋哪些內(nèi)容？

3.3.1 從上到下

金字塔模型中以上統(tǒng)下的方式進行設計開始。


3.3.2 逐層分解

分層、分塊的對整個系統(tǒng)進行描述，力求將信息清晰的傳遞過去。


清晰架構(gòu)分塊表示

3.4 圖即代碼

一切即代碼

3.4.1 架構(gòu)即代碼

使用編寫代碼的方式進行架構(gòu)設計。

分兩個層次：組件以及組件之間的關(guān)系。對于組件的描述，表示組件內(nèi)容。對于組件之間關(guān)系

3.5 結(jié)論

原則
  • 準確（accurate）：錯的圖比沒有圖還糟糕；即使一開始是準確的，后面也需要定期更新校對；
  • 完整（complete）：需要覆蓋架構(gòu)的核心要素和關(guān)鍵信息，為受眾呈現(xiàn)一個沒有殘缺的完整架構(gòu)設計；
  • 清晰（clear）：制圖時最好帶上圖例（形狀、顏色、線型、箭頭）；用圖描述不清的地方，還可以加上文字標注做補充；
  • 一致（consistent）：比如同一類型的圖，最好使用相同的記號風格，以降低受眾的理解成本；不一致往往還會帶來混淆；
  • 簡潔（consise）：在滿足以上 4 點基礎之上，還需要讓圖更加簡潔，一方面是更容易被人接受（沒人讀 = 沒寫)，另一方面更新維護成本也更低。

圖表必須是自我描述的、一致的、足夠準確的并且與代碼相關(guān)聯(lián)。 這就是為什么每個架構(gòu)師或軟件工程師在創(chuàng)建架構(gòu)圖時都依賴幾個指導方針很重要的原因，因為它們是隨著時間的推移（例如結(jié)構(gòu)、元素、關(guān)系、屬性、原則）和不同利益相關(guān)者之間交流應用程序架構(gòu)的共同基礎各種技術(shù)背景和關(guān)注點。

4. 用什么畫圖？

4.1 工具發(fā)展

從剛畢業(yè)的時候用Visio，Astah UML，StarUML這樣的UML工具。原來從Visio到PPT，再從PPT再到ProcessOn再到draw.io。工具也在不斷的發(fā)展，從原先的客戶端模式到比較流行的在線版，再到以代碼畫圖的的現(xiàn)在。工具在不斷的發(fā)展，現(xiàn)在看代碼畫圖有不宜用，不完善的點待到大家認識到圖即代碼的優(yōu)點的時候圖即代碼工具肯定會有更好的發(fā)展。

4.2 實踐過程

4.2.1 ADL（架構(gòu)描述語言）分類

  • 使用解釋型文件： 所有的配置信息都被定義于可執(zhí)行的配置解釋文件中，比如說shell腳本，ansible的playbooks，Chef的recipes，或者Puppet的manifests。人們無需登入服務器，就可以做出實時的動態(tài)調(diào)整。開發(fā)時，這些代碼可以作為持續(xù)的定義，來減少任何生成雪花服務器（SnowflakeServer）的風險。這也意味著更新代碼的頻率要快。幸運的是，計算機可以快速執(zhí)行程序，并可以準備數(shù)百個服務器，速度比任何人類都快。
  • 自歸檔的系統(tǒng)和過程： 相比于人們使用文檔中的指示來執(zhí)行操作（人工級別的可靠性），代碼更加清晰準確并且可以不斷的被執(zhí)行。而且如果有必要的話，根據(jù)這些代碼也可以生成一些更具有可讀性的文檔。
  • 給所有代碼做版本控制： 要讓所有的代碼都處于版本控制之中。這樣每次配置以及每個修改都會有記錄可以查詢的到，而且還可以利用可重用的構(gòu)建（ReproducibleBuild）來診斷問題。
  • 持續(xù)地測試系統(tǒng)和過程： 測試可以幫助計算機快速地找到基礎設施配置中的諸多錯誤。在現(xiàn)代軟件系統(tǒng)中，你可以搭建用于基礎設施代碼的“部署流水線”，這能夠讓你實踐針對基礎設施變化的持續(xù)交付流程。

4.2.2 工具

還有很多工具可以進行圖即代碼的畫圖過程：Graphviz，Mermaid，OmniGraffle，code2flow，Lucidchart。

5. 總結(jié)

軟件的設計應該是為了便于閱讀，而不是便于書寫。--《軟件設計的哲學》

攻技者，短之；理論者，長之；踐行者，勝之。
云原生體系下的技海浮沉與理論探索-王銀利(蕓崢) 阿里巴巴云原生

即使學了很多軟件架構(gòu)畫圖方法，但是要描述一個完成的架構(gòu)做到哪一步才可以還是需要實踐才能知道。

5.1 什么時候畫圖？

都可以，只要你認為用語言表示困難的時候都可以畫圖來解釋。

5.2 畫圖要畫到那種細節(jié)程度？

都可以，只要你認為圖可以在評審和實現(xiàn)過程中表示清楚即可。

6. 參考：

第一節(jié)

架構(gòu)制圖：工具與方法論
如何畫好一張架構(gòu)圖？
制作架構(gòu)圖的藝術(shù)
為什么說我們需要軟件架構(gòu)圖？
軟件設計的哲學：第三章 編程的戰(zhàn)術(shù)和戰(zhàn)略
浮現(xiàn)式設計
軟件設計的哲學：第三章 編程的戰(zhàn)術(shù)和戰(zhàn)略
【萬字長文】探討可信構(gòu)架之道
Is Design Dead?

什么是Cynefin框架？
什么是Cynefin框架
應用 Cynefin 框架，您的團隊可以識別好的問題
Cynefin框架

第二節(jié)

軟件工程用圖
A Conceptual Model of Architecture Description
企業(yè)架構(gòu)、TOGAF與 ArchiMate 概覽
淺談架構(gòu)設計（上）
架構(gòu)制圖：工具與方法論

第三節(jié)

The Art of Crafting Architectural Diagrams
用于軟件架構(gòu)的 C4 模型

InfrastructureAsCode(中文版：基礎設施即代碼)
OmniGraffle中文網(wǎng)站
軟件開發(fā)過程
軟體架構(gòu)分析方法
軟件架構(gòu)
graphviz
Text to UML tools – Fastest way to create your models
code2flow
Lucidchart
Mermaid，一個生成結(jié)構(gòu)圖的工具
mermaid

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點，簡書系信息發(fā)布平臺，僅提供信息存儲服務。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容