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

[[350961]]

圖片來自 Pexels 

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

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

將軟件架構(gòu)從軟件設計和開發(fā)中區(qū)分開來的關(guān)鍵因素包括：規(guī)模的上升、抽象層次的上升， 以及做出正確的設計決策帶來的影響的上升等等。

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

這些因素對區(qū)分軟件開發(fā)和軟件架構(gòu)也許有幫助，但還是無法解釋一些人如何從開發(fā)轉(zhuǎn)到了架構(gòu)。

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

1、經(jīng)驗

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

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

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

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

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

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

2、軟件架構(gòu)的定義

架構(gòu)的定義過程似乎相當直接：確定需求，然后設計一個滿足這些需求的系統(tǒng)。

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

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

 

①非功能性需求的管理

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

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

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

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

 

②架構(gòu)定義

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

我們可以說每個軟件系統(tǒng)都有架構(gòu)，但不是每個軟件系統(tǒng)都有現(xiàn)成的架構(gòu)。這才是關(guān)鍵點。

軟件定義過程需要思考如何在給定的限制下滿足提出的需求，進而解決問題。架構(gòu)定義過程是在項目的技術(shù)方面引入結(jié)構(gòu)、規(guī)范、原則和領(lǐng)導力的過程。

定義架構(gòu)軟件架構(gòu)師的工作，但從頭設計一個軟件系統(tǒng)與擴展一個現(xiàn)有系統(tǒng)還是有很大的差別。

 

③技術(shù)選型

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

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

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

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

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

如果正在進行架構(gòu)定義，你需要確信自己的技術(shù)選型是正確的。同樣地，為一個新系統(tǒng)開展評估技術(shù)與向現(xiàn)有系統(tǒng)引入新技術(shù)有著很大的區(qū)別。

 

④架構(gòu)評估

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

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

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

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

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

 

⑤架構(gòu)協(xié)作

與世隔絕的軟件系統(tǒng)很少見，大部分軟件系統(tǒng)都是需要靠人來理解。開發(fā)人員需要理解后按照架構(gòu)實現(xiàn);需求方出于安全、數(shù)據(jù)庫、運維、支持等角度，也可能對架構(gòu)實現(xiàn)感興趣。

軟件要成功，就需要與這些需求方緊密合作，保證架構(gòu)能夠和環(huán)境成功集成。不幸的是，即便在開發(fā)組內(nèi)架構(gòu)協(xié)作都很少發(fā)生，更遑論外部的需求方了。

 

3、軟件架構(gòu)的交付

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

 

①擁有更大的視野

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

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

 

②領(lǐng)導力

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

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

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

 

③培訓與指導

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

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

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

 

④質(zhì)量保障

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

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

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

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

對我來說，一切對架構(gòu)有重要影響的、對業(yè)務非常關(guān)鍵的、復雜的或能夠可視化的東西都是重要的。

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

 

⑤設計、開發(fā)與測試

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

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

大部分架構(gòu)師都是經(jīng)驗豐富的程序員，因此保持這項技能的狀態(tài)是有意義的。

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

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

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

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

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

 

4、你是一名軟件架構(gòu)師嗎?

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

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

其實，一部分開發(fā)者可能已經(jīng)在承擔部分軟件架構(gòu)師的角色了，雖然他們的職位并沒有體現(xiàn)出這一點。

參與一個軟件系統(tǒng)的架構(gòu)和親自設計一個軟件架構(gòu)有很大不同。持續(xù)精進技能、知識和跨多領(lǐng)域的經(jīng)驗成就了軟件架構(gòu)師的角色。

跨越軟件工程師和軟件架構(gòu)師的主動權(quán)在自己手上。而首先要做的，就是了解目前自己的經(jīng)驗所處的層次。

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

編輯：陶家龍

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