架構師應該多維度多視角地思考 - Gregor

banq發表於2022-04-29

程式設計師是無到有構建程式碼,應該注重組合思維,做出來的東西需要能夠相互組合在一起;而架構師是從上而下的視角,因為不參與具體細節構建,但為了落地,應該具有多維度多維度視角,從程式設計師到架構師思維轉變很重要,下面是原文摘要:
一個人能看得更多不僅意味著要有更好的視力,還意味著能看到更多的維度。想象以下情況:

架構師應該多維度多視角地思考 - Gregor

兩個人正在爭論一個物體的形狀。一個人一直聲稱它是一個矩形,而另一個人堅持認為它是一個圓形。討論一直在進行:“矩形!”、“圓形!”、“來吧,它有 4 個角!”、“什麼?它就像它得到的那樣圓!”。因為圓形和矩形實際上是完全不同的形狀,所以看不到和解。雙方都是聰明人,排除了缺乏理解是他們爭吵的原因。一位建築師進來並注意到他們都在看同一個物體:一個圓柱體。

從側面看圓柱體的人會準確地看到一個矩形。同樣,從頂部看同一個物體的另一個人也清楚地看到了一個圓圈。只要每個參與者都保持自己的觀點,他們就可以爭論很長時間。這就是為什麼軟體先驅Alan Kay 有一句名言:

“一個觀點的改變值得 80 點智商。”
這是一個強有力的宣告,但也是一個很大的解脫。

建築師不必是房間裡最聰明的人。相反,他們讓其他人更聰明。

架構是一個視角問題
IT 處理巨大的複雜性:在龐大的系統數量之下,存在如此密集的相互依賴關係網路,如果蝴蝶扇動翅膀導致颶風或系統中斷,您不會感到驚訝。

我們通過使用簡化的模型或預測來應對這種複雜性。流行的4+1 架構檢視模型就是一個典型的例子。為了推理和描述應用程式的架構,該模型提出了以下檢視:

  • 邏輯檢視通常通過類圖描述系統的功能結構。
  • 過程檢視描述了系統的過程和行為,例如通過狀態圖。
  • 開發檢視說明了軟體模組。
  • 物理檢視描述瞭如何將軟體工件部署到基礎設施資源,例如伺服器。
  • 場景通過將用例對映到其他檢視(因此 +1)來驗證設計。

這些檢視在系統上放置不同的鏡頭或過濾器,以便更容易描述系統的結構和行為。然而,我們必須提醒自己,這些預測中的每一個都是對底層系統的巨大簡化。檢視的存在主要是為了讓我們更容易理解系統。

模型的力量和危險
架構師在模型中思考——這就是他們處理複雜性並做出更好決策的方式,而不是僅僅跟隨他們的直覺或傾聽最響亮的人。

上面的檢視是模型。但是,模型是簡化的,我們很清楚所有模型都是錯誤的(請參閱The Software Architect Elevator)。

一般來說,沒關係,模型無法匹配現實,因為那樣它們就不會抽象事物或降低複雜性。

你選擇的模型會影響你的想法。您需要簡單但不簡單的模型。

在過去,地球被認為是大多數事物的中心,導致地心模型。這個模型適用於太陽的運動,但除非你試圖創造抽象藝術,否則行星的運動相當複雜且難以解釋。然而,這種模式在很大程度上受到宗教學者的青睞。

在 IT 中,這將是由象牙塔架構師定義的參考架構,他們更滿足於滿足特定的結構規則而不是系統的實際行為(隨意將“地球”替換為“核心系統”)。

哥白尼一定看到這個模型有問題,並推匯出了一個將太陽置於中心的替代模型,恰當地稱為日心說。在這個模型中,行星的運動顯得更有條理和合理。您可以將哥白尼視為變革推動者,他提出了諸如執行其他人的軟體是一件壞事這樣的異端思想。

多維度
因此,我們上面的圓柱體故事涉及使用不同模型的兩個人。就像哥白尼和他的前輩們觀察天空中行星的相同運動一樣,他們對所看到的東西有著截然不同的想法,就像圓形和矩形一樣。而且由於人們的觀點植根於二維,同一物體可以有不同形狀取決於你看它的角度的想法對他們來說似乎很陌生。

架構師依賴模型和預測,但意識到它們植根於同一個底層系統。
架構師喜歡模型和投影,但他們意識到投影並不是孤立存在的——它們植根於同一個底層系統。這就是為什麼建築師傾向於較少陷入圓形與矩形辯論的原因。

人體維度
與許多其他架構主題一樣,維度不僅適用於技術系統,也適用於組織系統。

對話可能會像圓形與矩形辯論一樣容易陷入困境。一個很好的例子是關於團隊自治與一致性的討論。大多數經理認為,給予團隊更多的自主權意味著他們在地圖上到處都是,即不是很一致。因此,他們認為他們必須在一個和另一個之間做出選擇——圓形或矩形,但不能同時選擇兩者。

Spotify 已經意識到,讓自治發揮作用的原因實際上是一致性,正如他們的一個工程文化視訊中所展示的那樣:

架構師應該多維度多視角地思考 - Gregor


Stephen Bungay 的優秀著作《行動的藝術》很好地解釋了對齊的需要作為自治的先決條件,而不是相反。組織架構師也看到了圓柱體。
 

相關文章