開發者需要知道的有關軟件架構的五件事

本文要點：

• 因為軟件系統的分布式特點以及開發團隊的分布性，了解軟件架構的基礎變得越來越重要。
• 在過度設計和毫無設計之間，我們應該把注意力放在對軟件系統有重大影響的決策和權衡上。
• 好的架構師應該是團隊的活躍分子，不僅能夠進行代碼協作，還能為團隊提供技術指導。
• 軟件架構中的溝通環節極具挑戰性。C4模型對軟件架構中的溝通環節進行了結構化，從一個上下文圖表開始，再逐步深入到系統的各個技術層面。
• 實際上，可以多花一些時間實現好的架構，好的架構能夠帶來敏捷。

2010年，我寫了一篇叫作“ Are You a Software Architect? ”的文章，探討了軟件開發者與軟件架構師之間的區別，以及如何從一名軟件開發者轉成一名架構師。8年過去了，軟件行業也在發展，但開發團隊仍然面臨著類似的問題，特別是與軟件架構有關的問題。這些問題比以往任何時候都要來得突出，因為我們現在構建的系統越來越趨于分布式化，開發團隊也越來越分布式化。為了解開這些迷思，開發者需要了解以下五個與軟件架構有關的事實。

1.軟件架構不只是前期的“大設計”

傳統的觀點認為，軟件架構就是在前期進行“大設計”，然后通過瀑布模型進行交付，架構團隊要確保軟件的每一個元素在進行編碼之前都要考慮妥當。2001年，“敏捷開發宣言”建議我們“擁抱變化而不是遵循計劃”，但這個觀點后來卻被誤讀成不應該制定任何計劃。結果就是，有些開發團隊直接從原先的“大設計”變成了零設計。這兩種極端的行為都愚蠢至極，實際上，在某個時候，你會發現前期的設計并非開發出完美軟件的必要因素。前期的設計應該只是一個起點，或是作為團隊前進方向的指引。

在進行軟件設計時需要做出一些設計決策。在談及軟件架構和軟件設計之間的區別這個問題時，Grady Booch說，“架構代表了重要的決策，決策的重要程度通過變更成本來衡量”。換言之，就是看在后續進行變更時那個決策需要付出更大的成本。所以，好的前期設計就是要充分理解什么是“重要的決策”。這些決策通常與技術選型和結構（也就是分解策略、模塊化、功能邊界等）有關。如果開發的是一個單體系統，那么選擇何種編程語言可能就變得尤為重要。如果采用的是微服務架構，那么使用何種編程語言就變得不那么重要，但需要考慮其他方面的因素。類似的，如果采用了六邊形架構，雖然可以將業務邏輯與技術選型解耦開來，但仍然需要做出其他方面的權衡。

所以說，前期設計就是要了解影響軟件成型的重要決策，而不是具體的技術細節，比如數據庫的某個列要設置多大的長度。在現實當中，我會讓團隊真正去了解他們將要做什么、如何去做以及他們已經設計好的東西是否可行。可以讓他們識別出最高優先級的任務，如果有必要可以寫出代碼。總而言之，前期設計就是一個疊加成功幾率的過程。

2. 每個開發團隊都需要進行軟件架構

上述的內容適用于每一個開發團隊，從一個單人團隊到數百人的分布式團隊。設置起點和方向其實就是要建立技術領導力。如果做不到這一點，就可能出現混亂：結構混亂的代碼庫（典型的“大泥球”），難以理解，難以維護，質量不達標，如性能、伸縮性或安全性。簡而言之，任何一個開發團隊都需要技術領導力。

3. 軟件架構師要會寫代碼、指導他人以及參與協作

在大部分人看來，軟件架構師就是給開發團隊下達指令的人，就像接力賽中跑第一棒的人。但事實不是這樣的，現代的架構師喜歡編碼、指導他人并參與協作。我所遇見的好架構師也都是好的開發者，他們仍然喜歡編碼，最起碼他們并不想放棄編碼工作。因為變化太快，人們很容易就與技術失之交臂。但我認為軟件架構師應該是“建筑大師”，在必要的時候他們仍然可以寫代碼。作為團隊的一份子，編碼會讓架構師的工作變得更容易一些，因為編碼有助于架構師理解系統，而且團隊的其他成員會真正把架構師當成是同事。

需要注意的是，軟件架構師不一定要指定某個人來擔任。剛開始可以這樣做，但其實也可以由多個人共同承當這個角色。 但要注意，建立協作式的技術領導力并不是件輕而易舉的事。軟技能本來就不是很輕松就能獲得的。我曾經組建2到5個人的架構師小組，讓他們來設計軟件系統，但他們在與技術和設計決策方面無法達成共識。在極端情況下，個性沖突會導致小組解散。關鍵是要了解你的團隊，并確保應用了恰到好處的技術領導力。

4. 使用UML不是必需的

傳統的軟件架構通常包含大量的UML模型圖，試圖充分展現軟件系統的每一個細節。可惜的是，建模和UML在很大程度上與前期“大設計”相耦合，而這些技術在近幾年已經過時了。現在完全不懂UML的軟件開發團隊比率在逐步上升。

現如今，大部分人只是“在白板上畫幾個方塊和線條”，并將其作為溝通想法的手段。在過去幾年，我參與過的軟件架構小組畫過大量這樣的圖表，我把它們拍成照片，有好幾個G。我敢說，從行業角度來講，我們已經散失了軟件架構的溝通能力。我見過不計其數的圖表，它們有些是隨機著色方塊和線條的組合，模糊不清，難以辨認。如果一個團隊無法就軟件架構進行溝通，那么就無法設置起點和建立技術領導力。

我建議使用“C4模型”來進行軟件架構方面的溝通——上下文（Context）、容器（Containers）、組件（Components）和代碼（Code）。其本質是創建一系列結構化、可伸縮的圖表來描述軟件系統。為每一個軟件系統創建一個上下文圖表，用于描述軟件系統與真實世界之間的關系。然后放大系統邊界，讓內部的容器突顯出來——容器就是可部署、可運行的實體，比如運行在瀏覽器上的單頁應用、服務器端的Web應用、微服務、數據庫實例，等等。如果有必要，可以再將每個容器放大，讓容器內部的組件突顯出來。最后，你也可以放大組件，讓代碼級別的元素（類、接口、函數、對象等）也突顯出來。C4模型獨立于具體的表示方法，雖然我傾向于使用簡單的“方塊和線條”，但使用UML來表示也是可以的。

c4model.com提供了更多的信息、視頻、示例圖表和工具鏈接。如果你的團隊正糾結于軟件架構溝通方面的問題，那么可以看看這些資料。

5. 好的軟件架構是敏捷的

現在仍然存在一種誤解，認為“架構”和“敏捷”之間是一種競爭和沖突的關系。但其實不是的。相反，好的軟件架構也是敏捷的，它有助于應對業務變更，不管是需求變更、業務流程變更還是混合變更。當然，什么才是“好的架構”仍然有待商榷，但我認為，好的架構與好的模塊化息息相關。如果你曾經有過在“大泥球”上進行變更的痛苦經歷，那么你就會知道，好的代碼庫結構（好的模塊化）是多么的重要。

現如今，很多團隊都存在一個很大的問題，他們采用了一種叫作“架構中立的設計”，George Fairbanks在他的“ Just Enough Software Architecture ”一書中對此進行了描述。換句話說，他們采用了一種不需要考慮權衡因素的架構風格。在現實中，開發團隊使用微服務架構代替單體代碼庫。但實際上，他們有可能是創建出了一種“分布式的大泥球”，可見軟件設計和分解過程是多么的重要，不管是要構建一個單體還是一個微服務架構的系統。敏捷和好的軟件架構不是那么容易就能實現的，它需要一些精巧的設計，也需要作出一些權衡。這也再次說明為什么設置起點和建立技術領導力是如此的重要。

關于作者

Simon Brown  是一個獨立的軟件架構顧問，同時是“Software Architecture for Developers”一書的作者。他還是C4軟件架構模型的創立者。Simon是國際軟件開發大會的演講常客，并周游世界，幫助企業促進軟件架構方面的工作。

查看英文原文： Five Things Every Developer Should Know about Software Architecture

來自：http://www.infoq.com/cn/articles/architecture-five-things