[[313595]]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

設(shè)計

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

• 了解基本的設(shè)計模式：模式是架構(gòu)師開發(fā)可維護(hù)系統(tǒng)所需的最重要工具之一?；谶@些模式，你可以把一些已經(jīng)在其他問題上奏效的方案遷移到一些模式相同的新問題上?！窯ang 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)域，它同時也是一些新模式（如 MVVM）的基礎(chǔ)；

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

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

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

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

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

決策

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

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

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

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

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

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

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

簡化

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

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

• 退一步：經(jīng)過激烈而漫長的討論后，常常會得到一些極其復(fù)雜的方案。永遠(yuǎn)不要把它們當(dāng)做最終的結(jié)果?！竿艘徊健沟囊馑季褪牵涸俅螐暮暧^角度看一下這個問題，當(dāng)下的方案還說的通嗎？然后再在抽象層面對方案進(jìn)行重構(gòu)。有時候暫停討論第二天再繼續(xù)是個不錯的選擇。至少對于我來說，我的大腦需要一些時間來處理信息，想出更好、更優(yōu)雅和更簡單的解決方案；

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

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

編程

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

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

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

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

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

記錄

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

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

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

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

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

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