軟件開發和軟件架構之間有一條微妙的線。有人會說，這條線根本不存在，架構只是開發者設計過程的簡單延伸。

[[350961]]

圖片來自 Pexels 

另外一部分人則說，這是一條巨大的鴻溝，只有少數出類拔萃的開發者才能跨越，這些開發者都認為你必須不斷地向上抽象，避免陷入令人生厭的實現細節的泥沼。

如果以務實的眼光看，那這兩者之間必定存在某個平衡點，但這接著也提出了問題：如何從開發者變成架構師?

將軟件架構從軟件設計和開發中區分開來的關鍵因素包括：規模的上升、抽象層次的上升， 以及做出正確的設計決策帶來的影響的上升等等。

軟件架構就在于能有一個全局視角、能具備更大的視野，理解軟件系統作為一個整體是如何工作的。

這些因素對區分軟件開發和軟件架構也許有幫助，但還是無法解釋一些人如何從開發轉到了架構。

進一步地，對于如何識別哪些人將會成為出色的架構師，作為 HR 如何發現這些人，以及自己是不是一名架構師，上述定義也無能為力。

1、經驗

盡管經驗是一個很好的衡量指標，但你應該看得更深。

沒有人是在一夜之間或一次升職就成為軟件架構師的。架構師是一個角色，而非級別。

這是一個演進的過程，在這個過程中你會不斷獲得承擔架構師角色所需的經驗與自信。

架構師身上有許多不同的品質，而他們過去的經驗通常是承擔這個角色所需能力的一種很好的度量。

架構師角色包括很多方面，因此需要在更深的層次地去理解架構師在不同方面展現出來的參與度、影響力、領導力和責任。

寬泛地說，大部分項目的軟件架構過程可以分成兩個階段：定義階段和交付階段。

2、軟件架構的定義

架構的定義過程似乎相當直接：確定需求，然后設計一個滿足這些需求的系統。

但實際上并沒有這么簡單，由于參與程度和對待自己角色的認真程度各有不同，軟件架構的角色也有很大的區別。

如下圖所示，角色的架構定義部分可以進一步分解為幾個子部分：

 

①非功能性需求的管理

軟件項目經常將注意力放在用戶的功能特性上，而很少問用戶有什么非功能需求或系統性能要求。

有時需求方會告訴我們說“系統必須足夠快”，但這種表述太主觀了。要滿足非功能需求，那這些需要必須是具體的、可測量、可實現以及可測試的。

大部分非功能需求本質上是技術性的，而且通常對軟件架構有很大影響。理解非功能需求是架構師角色的核心能力之一，但試圖理解這些需求與質疑這些需求的合理性有所不同。

畢竟，你見過多少真正需要 7x24 小時運行的系統呢?

 

②架構定義

弄清了非功能需求后，下一步就要思考如何定義架構，解決需求方提出的問題。

我們可以說每個軟件系統都有架構，但不是每個軟件系統都有現成的架構。這才是關鍵點。

軟件定義過程需要思考如何在給定的限制下滿足提出的需求，進而解決問題。架構定義過程是在項目的技術方面引入結構、規范、原則和領導力的過程。

定義架構軟件架構師的工作，但從頭設計一個軟件系統與擴展一個現有系統還是有很大的差別。

 

③技術選型

技術選擇通常是一個愉快的過程，但當考慮到成本、授權、供應商關系、技術策略 、兼容性、互操作性、支持、部署、升級策略、終端用戶環境等問題時，挑戰往往相當大。

這些因素綜合起來，經常會把一個簡單的選擇某些東西，例如設計一個功能豐富的客戶端，變成一場噩夢。

接下來還有另一個問題：這些技術能否像期望的那樣運行。

技術選型的本質管理風險：在復雜性或不確定性較高的地方減少引入風險，在可能帶來收益的地方適當接受風險。

技術決策需要考慮所有的因素并需要評審和評估，包括軟件項目的核心組件，以及開發過程會用到的庫和框架。

如果正在進行架構定義，你需要確信自己的技術選型是正確的。同樣地，為一個新系統開展評估技術與向現有系統引入新技術有著很大的區別。

 

④架構評估

如果讓你來設計軟件，需要問自己：我的架構能否工作?

對于我來說，這樣的架構可以工作：滿足非功能需求，為其他部分的代碼提供了必要的 基礎設施，為解決底層業務的問題提供了一個平臺。

軟件最大的問題之一就是復雜性和抽象，很難從 UML 圖或代碼去想象出軟件運行時的特點。

在軟件開發的過程中，會采用多種測試技術確保交付的系統在上線之后能正常工作。為什么不對架構設計采用同樣的方式呢?

如果可以測試架構，就可以證明該架構可以正常工作。這項工作做得越早，就越能減少項目失敗的風險。而不是簡單寄希望于它能正常工作。

 

⑤架構協作

與世隔絕的軟件系統很少見，大部分軟件系統都是需要靠人來理解。開發人員需要理解后按照架構實現;需求方出于安全、數據庫、運維、支持等角度，也可能對架構實現感興趣。

軟件要成功，就需要與這些需求方緊密合作，保證架構能夠和環境成功集成。不幸的是，即便在開發組內架構協作都很少發生，更遑論外部的需求方了。

 

3、軟件架構的交付

架構交付的部分也是類似，軟件架構的角色會隨著參與度不同而有所區別。

 

①擁有更大的視野

要確保架構成功落地，必須得有人在軟件開發的整個生命周期內擁有更大的視野，向大家描繪遠景。如有必要跟隨項目一起演進，承擔將交付責任。

如果你定義了一個架構，那始終保持對架構的參與和演進是很有意義的，而不是將它交給 “實現團隊”。

 

②領導力

把控大圖是技術領導力的一部分，但在軟件項目交付期間還有其它一些事情要做，包括向大家介紹任務的重要性、提供技術規范、做技術決策，以及具備決策權威。

作為架構師，你需要承擔技術領導力，保證所有的事情都考慮到了而且團隊走在正確的道路上。

軟件架構師的位置天然與領導力有關。雖然聽起來顯而易見，但很多團隊中的架構師可能會認為，成功交付并不是他們需要考慮的問題，進而喪失了必要的技術領導力。

 

③培訓與指導

培訓團隊和指導下屬是大部分軟件開發項目中容易被忽視的一項活動，導致的后果：一些團隊成員并沒有得到他們應該得到的幫助。

雖然技術領導力是關于對項目整體進行掌舵，但也有一些時候個人需要幫助。而且，培訓團隊和指導下屬提供了一種增強隊員技能和提升他們職業生涯的方式。

這是架構師職責的一部分，而且很顯然，為團隊培訓架構和設計技能與助他們解決代碼問題之間有著顯著的區別。

 

④質量保障

如果交付工作做的太差的話，即使擁有世界上最好的架構和最強的領導力，項目仍然會失敗。

質量保障是架構師角色中的很大一部分工作，但并非僅僅是代碼審核。例如，需要提供基準性能指標時，意味著需要引入標準和工作守則。

從軟件開發的角度講，這包括編碼標準、設計原則、源代碼分析工具等。

可以肯定地說，大部分項目的質量保障做的并不夠。因此你需要辨別出哪些是重要的，并優先保證這些部分被執行。

對我來說，一切對架構有重要影響的、對業務非常關鍵的、復雜的或能夠可視化的東西都是重要的。

這需要腳踏實地，意識到你無法保障所有方面，但實際做一些工作總比什么都不做好。

 

⑤設計、開發與測試

軟件架構師角色的最后任務就是設計、開發和測試。作為一名工作在一線的架構師，并不意著你必須參與每天的寫代碼任務。而是持續參與到項目中，積極主動地去幫助打造軟件并實現交付。

話已至此，我們不禁要說，為什么每天寫代碼不應該成為架構師角色的一部分呢?

大部分架構師都是經驗豐富的程序員，因此保持這項技能的狀態是有意義的。

除此之外，架構師還能經歷團隊成員都會經歷的痛苦，在此過程中可以幫助他們從開發的角度理解他們設計出來的架構。

一些公司明令禁止架構師參與編碼工作，因為覺得架構師太寶貴了，不應該從事編碼這樣普通的工作。

顯然，這種態度是錯誤的。如果不讓他們參與成功交付的過程，那又為什么讓他們花費精力設計架構呢?

當然，有些情況下讓架構師參與寫代碼確實不太可行。例如一個大型項目通常意味著需要思考的架構很大，不一定有時間參與到實現過程。

但通常來說，寫代碼的架構師只會比只會旁觀的架構師更加高效和快樂。

 

4、你是一名軟件架構師嗎?

不論軟件開發和軟件架構之間的那條線是神話還是鴻溝，本文討論的內容都說明了軟件架構師這個角色，經驗隨著實際參與項目的程度以及對待架構師角色的認真程度不同而不同。

大部分開發者都不會周一早上醒來就能宣稱自己是一名軟件架構師。我自己當然不是這樣，成為架構師的過程是一個演進的過程。

其實，一部分開發者可能已經在承擔部分軟件架構師的角色了，雖然他們的職位并沒有體現出這一點。

參與一個軟件系統的架構和親自設計一個軟件架構有很大不同。持續精進技能、知識和跨多領域的經驗成就了軟件架構師的角色。

跨越軟件工程師和軟件架構師的主動權在自己手上。而首先要做的，就是了解目前自己的經驗所處的層次。

作者：arthurchiao，本文翻譯自 2019 年的一篇英文博客 "Are You A Software Architect?"

編輯：陶家龍

出處：arthurchiao.art/blog/are-you-a-software-architect-zh/