[[313595]]

幾年前有人問我：「你是怎么成為一名軟件架構(gòu)師的？」我們就此探討了必備技能、經(jīng)驗(yàn)，以及儲(chǔ)備相關(guān)知識(shí)所需的時(shí)間和精力。除此之外，我也回顧了自己走過的路、使用或嘗試過的技術(shù)，以及我從那些五花八門的工作中學(xué)到的東西。

架構(gòu)師技術(shù)路線圖。

軟件架構(gòu)師是什么？

在進(jìn)行深層次的探討之前，我們先來看兩個(gè)定義：

• 軟件架構(gòu)師是指那些制定高級(jí)設(shè)計(jì)決策，并確定技術(shù)標(biāo)準(zhǔn)（包括軟件編程標(biāo)準(zhǔn)、工具和平臺(tái)）的軟件專家。這之中的首席專家就是總架構(gòu)師。（來源：Wikipedia: Software Architect）

• 軟件架構(gòu)是系統(tǒng)的基本組織構(gòu)成，這種組織主要體現(xiàn)在其組件、組件之間的關(guān)系、組件與環(huán)境之間的關(guān)系，以及決定系統(tǒng)設(shè)計(jì)與演化的原則。（來源：Wikipedia: Software Architecture）

架構(gòu)的「層級(jí)」

架構(gòu)主要可以抽象成以下幾個(gè)「層級(jí)」。不同層級(jí)所需的技能也不同。盡管對(duì)層級(jí)的分類有很多種標(biāo)準(zhǔn)，但是我最喜歡把架構(gòu)分成 3 個(gè)層級(jí)：

• 應(yīng)用級(jí)：最低層級(jí)的架構(gòu)。只關(guān)注單一的應(yīng)用。層級(jí)低，但是很詳細(xì)。這方面的交流一般是在一個(gè)開發(fā)團(tuán)隊(duì)內(nèi)展開；

• 解決方案級(jí)：架構(gòu)的中間層。關(guān)注一或多個(gè)滿足業(yè)務(wù)需求的應(yīng)用（也就是商業(yè)方案）。這之中有些設(shè)計(jì)是高層次的，但大部分還是低層次的設(shè)計(jì)。這種層級(jí)架構(gòu)的交流就開始涉及多個(gè)團(tuán)隊(duì)了；

• 企業(yè)級(jí)：架構(gòu)的最高層級(jí)。關(guān)注多個(gè)方案。這種架構(gòu)的設(shè)計(jì)層次高且抽象，因此也需要方案級(jí)和應(yīng)用級(jí)的架構(gòu)師對(duì)此進(jìn)行細(xì)化。這種層次的架構(gòu)就需要多個(gè)組織進(jìn)行溝通了。如果你想了解更多，可以參閱這個(gè)鏈接：https://github.com/justinamiller/EnterpriseArchitecture。

有時(shí)候，架構(gòu)師也被看做不同工作組之間的粘合劑。以下是三個(gè)例子：

• 橫向：在業(yè)務(wù)部和開發(fā)人員或是不同的開發(fā)團(tuán)隊(duì)之間架起溝通的橋梁；

• 縱向：在管理者和開發(fā)人員之間架起橋梁；

• 技術(shù)：將不同的技術(shù)或應(yīng)用整合在一起。

軟件架構(gòu)師的日常

要了解架構(gòu)師的必備技能，我們得先知道架構(gòu)師主要做什么。我認(rèn)為架構(gòu)師最重要的活動(dòng)包括：

• 定義和確定所需的開發(fā)技術(shù)與平臺(tái)；

• 定義開發(fā)標(biāo)準(zhǔn)，如編程標(biāo)準(zhǔn)、工具、審核流程、測(cè)試方法等；

• 對(duì)確定和理解業(yè)務(wù)需求提供支持；

• 設(shè)計(jì)系統(tǒng)并根據(jù)需求做出決策；

• 對(duì)架構(gòu)定義、設(shè)計(jì)和決策進(jìn)行討論記錄；

• 檢查并審核架構(gòu)與代碼，比如檢查前期確定的模式與編程標(biāo)準(zhǔn)是否被正確實(shí)施；

• 與其他部門和架構(gòu)師合作；

• 對(duì)開發(fā)人員的引導(dǎo)及咨詢；

• 將高級(jí)設(shè)計(jì)細(xì)化，并轉(zhuǎn)化為較低級(jí)的設(shè)計(jì)。

注意： 架構(gòu)設(shè)計(jì)是一項(xiàng)持續(xù)性的工作，尤其是在敏捷軟件開發(fā)過程中。 因此，我們會(huì)一遍又一遍地重復(fù)這些工作 。

軟件架構(gòu)師必備技能

為了完成上面說的那些工作，架構(gòu)師需要具備一些特定的技能。從我的個(gè)人經(jīng)驗(yàn)、相關(guān)書籍和討論中，我們可以將其總結(jié)為以下 10 項(xiàng)技能： 設(shè)計(jì)、決策、簡(jiǎn)化、編程、記錄、溝通、估算、平衡、咨詢、市場(chǎng) 。

接下來我將逐一介紹這些技能。

設(shè)計(jì)

首先最重要也最難回答的問題就是「什么是好的設(shè)計(jì)」。我將從理論和實(shí)踐兩個(gè)層面進(jìn)行闡述。就我的經(jīng)驗(yàn)來說，兩者兼?zhèn)洳攀亲詈玫摹Ｄ俏覀兿日f一下理論層面吧：

• 了解基本的設(shè)計(jì)模式：模式是架構(gòu)師開發(fā)可維護(hù)系統(tǒng)所需的最重要工具之一。基于這些模式，你可以把一些已經(jīng)在其他問題上奏效的方案遷移到一些模式相同的新問題上。「Gang of Four」(GoF) 所著《Design Patterns: Elements of Reusable Object-Oriented Software》是所有從事軟件開發(fā)的人的必讀書。盡管這些模式發(fā)布于 20 多年前，它們?nèi)允乾F(xiàn)代軟件體系結(jié)構(gòu)的基礎(chǔ)。例如書中的模型-視圖-控制器（Model-View-Controller，MVC）模式就被應(yīng)用于許多領(lǐng)域，它同時(shí)也是一些新模式（如 MVVM）的基礎(chǔ)；

• 再挖深一點(diǎn)，研究一下模式與反模式（anti-pattern）：如果你對(duì) GoF 所寫的模式具備全面的了解，那么你就可以學(xué)習(xí)更多的軟件設(shè)計(jì)模式了，或者深挖你感興趣的領(lǐng)域。在應(yīng)用集成領(lǐng)域，我最喜歡的一本書是 Gregor Hohpe 編寫的《企業(yè)集成模式》。當(dāng)兩個(gè)應(yīng)用需要交換數(shù)據(jù)時(shí)，無論是來自一些遺留系統(tǒng)的老式文件交換還是現(xiàn)代微服務(wù)體系結(jié)構(gòu)，這本書的內(nèi)容都適用；

• 了解質(zhì)量度量：定義架構(gòu)還不算完，還要解釋為什么要定義、應(yīng)用并控制這些準(zhǔn)則和編程標(biāo)準(zhǔn)。這樣做是因?yàn)樾枰刂瀑|(zhì)量，滿足一些非功能需求。我們想要的是一個(gè)可維護(hù)、可靠、可適應(yīng)、安全、可測(cè)試、可擴(kuò)展、可用的系統(tǒng)。而實(shí)現(xiàn)所有這些要求的方法就是有一個(gè)好的架構(gòu)設(shè)計(jì)方法。你可以在維基百科上了解更多關(guān)于質(zhì)量度量的信息。理論很重要，但是如果你不想成為一名活在象牙塔里的架構(gòu)師，實(shí)踐也同樣重要，甚至更加重要；

• 嘗試并理解不同的技術(shù)棧：我認(rèn)為這是你成為更好架構(gòu)師之路上最重要的一步。嘗試新的技術(shù)棧，并了解其發(fā)展歷程。這些不同的技術(shù)具有不同的設(shè)計(jì)理念和模式。只瀏覽 PPT 學(xué)不到太多東西，你需要自己去嘗試并感受這項(xiàng)技術(shù)的喜與悲。架構(gòu)師不僅要有廣博的知識(shí)面，還要在一些領(lǐng)域有深厚的積累。重點(diǎn)不在于掌握所有的技術(shù)棧，而是對(duì)你所在領(lǐng)域最重要的技術(shù)有堅(jiān)實(shí)的理解。你還可以嘗試一些領(lǐng)域外的技術(shù)，例如，如果你對(duì) SAP R/3 有很深的了解，你應(yīng)該嘗試一下 JavaScript，反之亦然。盡管如此，雙方都會(huì)對(duì) SAP S/4 Hana 的最新進(jìn)展感到驚訝。例如，你可以自己嘗試并免費(fèi)參加 openSAP 的課程。保持好奇心，多嘗試新事物，也可以嘗試一些幾年前不喜歡的東西；

• 分析和理解應(yīng)用模式：查看任意當(dāng)前框架（如 Angular）。你可以在實(shí)踐中學(xué)習(xí)到很多模式（如 Observables），你還應(yīng)該試著理解它是如何在框架中應(yīng)用的，為什么要這樣做。如果你是真正的專業(yè)人士，你還需要更深入地研究代碼并了解它是如何實(shí)現(xiàn)的；

• 保持好奇心，關(guān)注用戶群。

決策

架構(gòu)師需要制定決策，指引項(xiàng)目甚至整個(gè)公司的正確方向。

• 分清主次：不要在不重要的決策和工作上浪費(fèi)時(shí)間，要學(xué)會(huì)分清主次。就我個(gè)人來說，我比較喜歡通過以下兩個(gè)特征來判斷一件事是否重要：

• a. 概念完整性：如果你一開始決定了一個(gè)理念，堅(jiān)持下去，即使有時(shí)候用不同的方法做會(huì)更好。這樣整體概念就更清晰明確，提升了可理解性，也簡(jiǎn)化了維護(hù)過程。

• b. 一致性：例如，如果你定義并應(yīng)用了命名約定，那么它不是關(guān)于大寫或小寫的，而是以相同的方式應(yīng)用于所有地方。

• 優(yōu)先級(jí)：有些決定非常關(guān)鍵，如果沒有及早采取合適的解決方案，很有可能給日后造成無法解決的問題。這對(duì)維護(hù)人員來說來說是一場(chǎng)噩夢(mèng)，或者更糟的，開發(fā)人員在這個(gè)決策制定之前無法繼續(xù)工作。在這種情況下，先做一個(gè)「糟糕」的決定甚至比沒有決定更好。但是在這種情況發(fā)生之前，你要知道哪些決定是應(yīng)該被優(yōu)先處理的。有很多方法可以做到這一點(diǎn)。我建議先看看加權(quán)最短作業(yè)優(yōu)先（WSJF）模型，它在敏捷軟件開發(fā)中被廣泛使用。尤其是時(shí)間臨界和風(fēng)險(xiǎn)降低，對(duì)這二者的度量是評(píng)估架構(gòu)決策優(yōu)先級(jí)的關(guān)鍵；

• 認(rèn)清自己的能力：不要在能力范圍之外的事情上做決定。這很重要，因?yàn)槿绻患右钥紤]，它可能會(huì)嚴(yán)重破壞你作為架構(gòu)師的地位。為了避免這種情況，你應(yīng)該和同事明確自己的職責(zé)和角色。如果有不止一個(gè)架構(gòu)師，那么你應(yīng)當(dāng)只負(fù)責(zé)當(dāng)前負(fù)責(zé)的架構(gòu)層級(jí)。作為一個(gè)較低層級(jí)的架構(gòu)師，你應(yīng)該為更高層級(jí)的架構(gòu)提出建議，而不是做出決策。此外，我建議你經(jīng)常和同事一起檢查重要的決定；

• 評(píng)估多種選擇：在做決定時(shí)，總是要列出多個(gè)選項(xiàng)。在我參與的大多數(shù)案例中，都有不止一個(gè)可能的（優(yōu)秀）選擇。不好的選擇主要有這兩個(gè)特點(diǎn)：（1）看起來你沒有完成好自己的工作；（2）有礙于作出正確的決定。定義度量后，你就可以根據(jù)事實(shí)（如許可證成本或成熟度）來比較各種選擇，而不是通過直覺。這通常會(huì)讓你做出更好、更可持續(xù)的決策。此外，將該決策推廣到其他部門也會(huì)更容易。但是如果你沒有正確評(píng)估選項(xiàng)，在最終討論時(shí)你可能會(huì)失去一個(gè)重要的論據(jù)。

簡(jiǎn)化

時(shí)刻記住奧卡姆剃刀原則，也就是簡(jiǎn)單即正義。我對(duì)這個(gè)原則的理解是這樣的：如果你的解決方案是在做了很多假設(shè)的基礎(chǔ)上提出來的，那么你的方案很可能是錯(cuò)的，也很可能會(huì)變得極其復(fù)雜。這個(gè)時(shí)候你就應(yīng)該減少（簡(jiǎn)化）一些假設(shè)，以獲得更好的解決方案。

• 多方位觀察解決方案：為了簡(jiǎn)化解決方案，經(jīng)常需要你調(diào)整對(duì)解決方案的觀察角度。比如，你可以嘗試通過自頂向下和自底向上的思考來獲取解決方案。如果你有一個(gè)數(shù)據(jù)流或流程，那么首先考慮從左到右，然后再考慮從右到左。在簡(jiǎn)化過程中詢問自己：「在完美的世界里，你的解決方案需要做什么修正嗎？」，或者「某公司/某人會(huì)怎么做？」。這兩個(gè)問題都可以幫助你按照奧卡姆剃刀原則來簡(jiǎn)化假設(shè)；

• 退一步：經(jīng)過激烈而漫長(zhǎng)的討論后，常常會(huì)得到一些極其復(fù)雜的方案。永遠(yuǎn)不要把它們當(dāng)做最終的結(jié)果。「退一步」的意思就是：再次從宏觀角度看一下這個(gè)問題，當(dāng)下的方案還說的通嗎？然后再在抽象層面對(duì)方案進(jìn)行重構(gòu)。有時(shí)候暫停討論第二天再繼續(xù)是個(gè)不錯(cuò)的選擇。至少對(duì)于我來說，我的大腦需要一些時(shí)間來處理信息，想出更好、更優(yōu)雅和更簡(jiǎn)單的解決方案；

• 分而治之：把大問題分解成更小的問題，然后分別解決小問題，并驗(yàn)證這些小方案是否匹配。最后再退一步來看一下總體情況；

• 重構(gòu)并非壞事：如果找不到更好的解決方案，那么修正一個(gè)復(fù)雜的解決方案也是不錯(cuò)的選擇。如果某個(gè)解決方案問題很多，你可以稍后重新思考該方案，再將想到的新東西應(yīng)用到該方案中。重構(gòu)并非壞事，但是在你開始重構(gòu)之前，請(qǐng)記住：（1）準(zhǔn)備好足夠的自動(dòng)化測(cè)試，以確保系統(tǒng)的正常功能；（2）獲得利益相關(guān)者的支持。要了解更多關(guān)于重構(gòu)的知識(shí)，我建議閱讀 Martin Fowler 寫的《Refactoring. Improving the Design of Existing Code》。

編程

即使作為企業(yè)級(jí)架構(gòu)師（最抽象的架構(gòu)層級(jí)），你仍然應(yīng)該了解開發(fā)人員的日常工作。如果你不了解開發(fā)如何完成的，那你可能會(huì)面臨兩個(gè)主要問題：

1. 開發(fā)人員不接受你的說法；

2. 你不了解開發(fā)人員的挑戰(zhàn)和需求。

• 開展副項(xiàng)目：做副項(xiàng)目的目的是嘗試新技術(shù)和工具，從而發(fā)現(xiàn)目前和未來的開發(fā)方式。經(jīng)驗(yàn)是觀察、情感和假設(shè)的結(jié)合 (《Experience and Knowledge Management in Software Engineering》，Kurt Schneider 著)。閱讀教程或?qū)椎慕榻B當(dāng)然好，但這只是「書本知識(shí)」。只有當(dāng)你自己嘗試時(shí)，你才能體驗(yàn)到開發(fā)人員的情緒，才能對(duì)事情好壞背后的原因做出假設(shè)。使用一種技術(shù)的時(shí)間越長(zhǎng)，你做出的假設(shè)就會(huì)越好。這會(huì)幫助你在日常工作中做出更好的決定。我剛開始編程時(shí)，并沒有代碼補(bǔ)全功能，只有一些可以加速開發(fā)的實(shí)用程序庫(kù)。顯然，把那時(shí)候的背景知識(shí)用在今天，我會(huì)做出錯(cuò)誤的決定。現(xiàn)在我們有大量的編程語(yǔ)言、框架、工具、流程和實(shí)踐。只有當(dāng)你有經(jīng)驗(yàn)，對(duì)主要趨勢(shì)有粗略的了解時(shí)，你才能參與到討論中來，并將開發(fā)引向正確的方向；

• 只嘗試需要嘗試的事情：你不可能嘗試所有的事情，這根本是不可能的。你需要一個(gè)更結(jié)構(gòu)化的方法。我最近發(fā)現(xiàn)了一個(gè)資源：ThoughtWorks 的技術(shù)雷達(dá)，他們將技術(shù)、工具、平臺(tái)、語(yǔ)言和框架分為四類：采納、試驗(yàn)、評(píng)估和暫緩。采納表示「強(qiáng)烈建議業(yè)界采用這些技術(shù)」，試驗(yàn)表示「企業(yè)應(yīng)當(dāng)在風(fēng)險(xiǎn)可控的前提下在項(xiàng)目中嘗試應(yīng)用此項(xiàng)技術(shù)」，評(píng)估表示「它對(duì)企業(yè)的影響還需探索」，暫緩表示「謹(jǐn)慎行事」。有了這種分類方法，我們更容易獲得新事物的概況，并更好地評(píng)估下一步要探索的趨勢(shì)。

記錄

架構(gòu)文檔有時(shí)很重要，有時(shí)卻不那么重要。例如，架構(gòu)決策或代碼指南是重要文檔。在開始編程之前，通常需要初始文檔，并且對(duì)此不斷細(xì)化。因?yàn)榇a也可以作為文檔（如 UML 類圖），所以有些文檔可以自動(dòng)生成。

• 代碼整潔：好的代碼本身就是最好的文檔。好的架構(gòu)師應(yīng)該擁有辨別好壞代碼的能力。Robert C. Martin 寫的《Clean Code》就是這方面很好的學(xué)習(xí)資料。

• 在可能的情況下生成文檔：系統(tǒng)變化很快，因此文檔很難及時(shí)更新。無論是 API 還是以 CMDB 形式出現(xiàn)的系統(tǒng)環(huán)境：底層信息的變化往往太快，因此無法手動(dòng)更新相應(yīng)的文檔。例如：如果你的 API 是模型驅(qū)動(dòng)的，你就可以根據(jù)定義文件自動(dòng)生成文檔，或者直接從源代碼生成文檔。有很多工具可以幫你完成這項(xiàng)工作，我認(rèn)為 Swagger 和 RAML 是很好的起點(diǎn)。

• 盡可能多記必需的東西，內(nèi)容盡可能少：不管你需要記錄什么（如決策文件），試著一次只關(guān)注一件事，只記錄這件事的必要信息。豐富的文檔很難閱讀和理解，附加信息應(yīng)保存在附錄中。特別是決策文件，更重要的是要講一個(gè)有說服力的故事，而不是拋出大量的論據(jù)。此外，這還能為你和你的同事節(jié)省大量時(shí)間，因?yàn)槟銈儽仨氶喿x這些文檔。看看你過去做過的一些文檔（源代碼、模型、決策文件等），然后問自己以下問題：「用于理解該文件的所有必要信息都包括在內(nèi)了嗎？」、「哪些信息是真正需要的，哪些可以省略？」、「文檔有紅線嗎？」

• 更多地了解架構(gòu)框架：這一點(diǎn)也適用于所有其他「技術(shù)」類建議。我之所以把它放在這里，是因?yàn)橄?TOGAF 或 Zachmann 這樣的框架提供了「工具」，這些工具在文檔站點(diǎn)上很重要，盡管它們的附加價(jià)值并不局限于文檔。深入了解此類框架將教會(huì)你更系統(tǒng)地處理架構(gòu)。

參考鏈接： https://github.com/justinamiller/SoftwareArchitect