軟件開(kāi)發(fā)和軟件架構(gòu)之間有一條微妙的線。有人會(huì)說(shuō)，這條線根本不存在，架構(gòu)只是開(kāi)發(fā)者設(shè)計(jì)過(guò)程的簡(jiǎn)單延伸。

[[350961]]

圖片來(lái)自 Pexels 

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

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

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

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

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

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

1、經(jīng)驗(yàn)

盡管經(jīng)驗(yàn)是一個(gè)很好的衡量指標(biāo)，但你應(yīng)該看得更深。

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

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

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

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

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

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

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

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

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

①非功能性需求的管理

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

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

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

畢竟，你見(jiàn)過(guò)多少真正需要 7x24 小時(shí)運(yùn)行的系統(tǒng)呢?

②架構(gòu)定義

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

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

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

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

③技術(shù)選型

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

這些因素綜合起來(lái)，經(jīng)常會(huì)把一個(gè)簡(jiǎn)單的選擇某些東西，例如設(shè)計(jì)一個(gè)功能豐富的客戶端，變成一場(chǎng)噩夢(mèng)。

接下來(lái)還有另一個(gè)問(wèn)題：這些技術(shù)能否像期望的那樣運(yùn)行。

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

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

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

④架構(gòu)評(píng)估

如果讓你來(lái)設(shè)計(jì)軟件，需要問(wèn)自己：我的架構(gòu)能否工作?

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

軟件最大的問(wèn)題之一就是復(fù)雜性和抽象，很難從 UML 圖或代碼去想象出軟件運(yùn)行時(shí)的特點(diǎn)。

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

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

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

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

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

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

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

①擁有更大的視野

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

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

②領(lǐng)導(dǎo)力

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

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

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

③培訓(xùn)與指導(dǎo)

培訓(xùn)團(tuán)隊(duì)和指導(dǎo)下屬是大部分軟件開(kāi)發(fā)項(xiàng)目中容易被忽視的一項(xiàng)活動(dòng)，導(dǎo)致的后果：一些團(tuán)隊(duì)成員并沒(méi)有得到他們應(yīng)該得到的幫助。

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

這是架構(gòu)師職責(zé)的一部分，而且很顯然，為團(tuán)隊(duì)培訓(xùn)架構(gòu)和設(shè)計(jì)技能與助他們解決代碼問(wèn)題之間有著顯著的區(qū)別。

④質(zhì)量保障

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

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

從軟件開(kāi)發(fā)的角度講，這包括編碼標(biāo)準(zhǔn)、設(shè)計(jì)原則、源代碼分析工具等。

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

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

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

⑤設(shè)計(jì)、開(kāi)發(fā)與測(cè)試

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

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

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

除此之外，架構(gòu)師還能經(jīng)歷團(tuán)隊(duì)成員都會(huì)經(jīng)歷的痛苦，在此過(guò)程中可以幫助他們從開(kāi)發(fā)的角度理解他們?cè)O(shè)計(jì)出來(lái)的架構(gòu)。

一些公司明令禁止架構(gòu)師參與編碼工作，因?yàn)橛X(jué)得架構(gòu)師太寶貴了，不應(yīng)該從事編碼這樣普通的工作。

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

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

但通常來(lái)說(shuō)，寫代碼的架構(gòu)師只會(huì)比只會(huì)旁觀的架構(gòu)師更加高效和快樂(lè)。

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

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

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

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

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

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

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

編輯：陶家龍

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