不久前，高級(jí)架構(gòu)師 Justin Miller 在 GitHub 上創(chuàng)建項(xiàng)目，介紹自己關(guān)于如何成為更好的軟件架構(gòu)師的想法。該項(xiàng)目發(fā)布一天即獲得 1.4K star，現(xiàn)在已有近 5K star 量。 

[[314313]] 

圖片來(lái)自 Pexels 

幾年前有人問(wèn)我：你是怎么成為一名軟件架構(gòu)師的?我們就此探討了必備技能、經(jīng)驗(yàn)，以及儲(chǔ)備相關(guān)知識(shí)所需的時(shí)間和精力。

除此之外，我也回顧了自己走過(guò)的路、使用或嘗試過(guò)的技術(shù)，以及我從那些五花八門(mén)的工作中學(xué)到的東西。

 

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

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

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

• 軟件架構(gòu)師是指那些制定高級(jí)設(shè)計(jì)決策，并確定技術(shù)標(biāo)準(zhǔn)(包括軟件編程標(biāo)準(zhǔn)、工具和平臺(tái))的軟件專家。這之中的首席專家就是總架構(gòu)師。
• 軟件架構(gòu)是系統(tǒng)的基本組織構(gòu)成，這種組織主要體現(xiàn)在其組件、組件之間的關(guān)系、組件與環(huán)境之間的關(guān)系，以及決定系統(tǒng)設(shè)計(jì)與演化的原則。

架構(gòu)的“層級(jí)”

架構(gòu)主要可以抽象成以下幾個(gè)層級(jí)。不同層級(jí)所需的技能也不同。

盡管對(duì)層級(jí)的分類有很多種標(biāo)準(zhǔn)，但是我最喜歡把架構(gòu)分成三個(gè)層級(jí)：

• 應(yīng)用級(jí)：最低層級(jí)的架構(gòu)。只關(guān)注單一的應(yīng)用。層級(jí)低，但是很詳細(xì)。這方面的交流一般是在一個(gè)開(kāi)發(fā)團(tuán)隊(duì)內(nèi)展開(kāi)。
• 解決方案級(jí)：架構(gòu)的中間層。關(guān)注一或多個(gè)滿足業(yè)務(wù)需求的應(yīng)用(也就是商業(yè)方案)。這之中有些設(shè)計(jì)是高層次的，但大部分還是低層次的設(shè)計(jì)。這種層級(jí)架構(gòu)的交流就開(kāi)始涉及多個(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)行溝通了。

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

• 橫向：在業(yè)務(wù)部和開(kāi)發(fā)人員或是不同的開(kāi)發(fā)團(tuán)隊(duì)之間架起溝通的橋梁。
• 縱向：在管理者和開(kāi)發(fā)人員之間架起橋梁。
• 技術(shù)：將不同的技術(shù)或應(yīng)用整合在一起。

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

要了解架構(gòu)師的必備技能，我們得先知道架構(gòu)師主要做什么。

我認(rèn)為架構(gòu)師最重要的活動(dòng)包括：

• 定義和確定所需的開(kāi)發(fā)技術(shù)與平臺(tái)。
• 定義開(kā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í)施。
• 與其他部門(mén)和架構(gòu)師合作。
• 對(duì)開(kāi)發(fā)人員的引導(dǎo)及咨詢。
• 將高級(jí)設(shè)計(jì)細(xì)化，并轉(zhuǎn)化為較低級(jí)的設(shè)計(jì)。

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

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

為了支撐上述工作需要很多重要的能力。就我個(gè)人的經(jīng)驗(yàn)，每個(gè)軟件架構(gòu)師應(yīng)該具備如下十項(xiàng)技能:

• 設(shè)計(jì)能力
• 決策能力
• 化繁為簡(jiǎn)能力
• 編碼能力
• 文檔架構(gòu)能力
• 溝通能力
• 評(píng)估能力
• 平衡能力
• 指導(dǎo)、答疑能力
• 營(yíng)銷能力

設(shè)計(jì)能力

什么是好的設(shè)計(jì)?這可能是最重要和最具挑戰(zhàn)性的問(wèn)題。要把理論和實(shí)踐區(qū)別開(kāi)來(lái)。

根據(jù)我的經(jīng)驗(yàn)，兩者兼而有之是最有價(jià)值的。讓我們從理論開(kāi)始：

①了解基本的設(shè)計(jì)模式：設(shè)計(jì)模式是架構(gòu)師設(shè)計(jì)開(kāi)發(fā)可維護(hù)、可擴(kuò)展系統(tǒng)的一項(xiàng)最重要工具。

通過(guò)設(shè)計(jì)模式你可以設(shè)計(jì)解決通用問(wèn)題的可重用方案。由 John Vlissides，Ralph Johnson，Richard Helm，Erich Gamma 撰寫(xiě)的《設(shè)計(jì)模式：可重用面向?qū)ο筌浖囊亍芬粫?shū)，每個(gè)從事軟件開(kāi)發(fā)的人都有必要閱讀一番。

盡管上述模式發(fā)布于 20 多年前，其仍然是現(xiàn)代軟件架構(gòu)的重要基礎(chǔ)。例如，本書(shū)描述了模型-視圖-控制器(MVC)模式，該模式應(yīng)用于許多領(lǐng)域，也是一些新模式(如 MVVM)的基礎(chǔ)。

②深耕模式和反模式：如果你已經(jīng)知道了所有的基本 GoF 模式，那么可以用更多的軟件設(shè)計(jì)模式擴(kuò)展你的知識(shí)或者深入你感興趣的領(lǐng)域。

我最喜歡的應(yīng)用程序集成相關(guān)的內(nèi)容之一是 Gregor Hohpe 編寫(xiě)的《企業(yè)集成模式》一書(shū)。

本書(shū)適用于兩個(gè)不同環(huán)境的應(yīng)用程序需要交換數(shù)據(jù)時(shí)，無(wú)論是一些傳統(tǒng)系統(tǒng)的舊式文件交換還是現(xiàn)代微服務(wù)體系結(jié)構(gòu)。

③了解質(zhì)量測(cè)量：定義架構(gòu)遠(yuǎn)不是終點(diǎn)。指引手冊(cè)和編碼標(biāo)準(zhǔn)的定義、應(yīng)用和管理是有原因的，這么做是因?yàn)橘|(zhì)量和非功能性需求。

你想擁有一個(gè)可維護(hù)、可靠、可適應(yīng)、安全、可測(cè)試、可擴(kuò)展、可用等的系統(tǒng)，而實(shí)現(xiàn)所有這些質(zhì)量屬性的一個(gè)方法就是應(yīng)用好的架構(gòu)工作。

你可以在維基百科上了解更多關(guān)于質(zhì)量衡量的信息。理論很重要。如果你不想成為一名站在空中樓閣上的架構(gòu)師，那么實(shí)踐同樣重要，甚至更重要。

④?chē)L試了解不同的技術(shù)棧：這是成為一個(gè)更好的架構(gòu)師的一項(xiàng)重要工作。嘗試新的技術(shù)棧并至上而下的學(xué)習(xí)他們。

不同的技術(shù)可以給你帶來(lái)不同的設(shè)計(jì)理念和模式。對(duì)新技術(shù)的學(xué)習(xí)最好不要浮于表面，應(yīng)該去多實(shí)踐深入感受解決的痛點(diǎn)和其存在的問(wèn)題。

架構(gòu)師不僅需要涉獵廣泛，在某些領(lǐng)域也要有深厚的知識(shí)。當(dāng)然并不需要掌握所有的技術(shù)，你需要對(duì)你所在領(lǐng)域最核心的技術(shù)有扎實(shí)的了解。

你也可以嘗試其他領(lǐng)域的技術(shù)，例如，如果你深入 SAP R/3，你就應(yīng)該也去嘗試一下 JavaScript，反正亦然。時(shí)刻保持好奇心并付諸實(shí)踐。還可以去試一些你討厭了很多年的技術(shù)。

⑤分析和理解應(yīng)用模式：看一下當(dāng)前的任一比較流行的框架，例如 Angular。可以在實(shí)踐中研究很多模式，例如“觀察者模式”。

嘗試了解它如何在框架中應(yīng)用，為什么要這樣做。如果真的很有時(shí)間且認(rèn)真，可以更深入地了解代碼并了解其實(shí)現(xiàn)方式.

⑥加入一些用戶組，例如 Meetup。

決策能力

架構(gòu)師需要能夠做出決策并將項(xiàng)目或整個(gè)組織引導(dǎo)到正確的方向。

①知道重點(diǎn)：不要把時(shí)間浪費(fèi)在不重要的決定或者行為上。學(xué)會(huì)抓住重點(diǎn)。據(jù)我所知，目前還沒(méi)有一本書(shū)講這方面的內(nèi)容。

個(gè)人評(píng)估某件事是否重要，通?？紤]如下兩點(diǎn)：

概念完整性：即使您決定以一種方式做到這一點(diǎn)，堅(jiān)持下去，即使有時(shí)以其他方式更好地做到這一點(diǎn)也是如此。通常，這會(huì)讓概念整體上更簡(jiǎn)單，簡(jiǎn)化可理解性并簡(jiǎn)化維護(hù)性。

一致性：例如，如果您定義并應(yīng)用命名約定，它就無(wú)關(guān)于大小寫(xiě)，而是以相同的方式在任何地方應(yīng)用它。

②優(yōu)先級(jí)：有些決定是非常關(guān)鍵的。如果不盡早決策，會(huì)產(chǎn)生很多冗余到后期不太能刪除的方案，導(dǎo)致維護(hù)困難，甚至于導(dǎo)致開(kāi)發(fā)人員無(wú)法繼續(xù)開(kāi)發(fā)，直到給出決策。

這種時(shí)候，往往給出壞的決定好于沒(méi)有決定。當(dāng)然，遇到這種情況時(shí)優(yōu)先選擇當(dāng)前方案中的最優(yōu)解。

這里我建議看看在敏捷軟件開(kāi)發(fā)中廣泛使用的加權(quán)最短作業(yè)優(yōu)先(WSJF)模型。尤其是時(shí)間關(guān)鍵性和風(fēng)險(xiǎn)降低是評(píng)估體系結(jié)構(gòu)決策優(yōu)先級(jí)的關(guān)鍵。

③明確自己的職責(zé)：不要決策在你能力或者職責(zé)范圍之外的事情。這是至關(guān)重要的，如果不考慮的話，它可能會(huì)嚴(yán)重破壞你架構(gòu)師的地位。

為了避免這種情況，一定要與你的伙伴們明確你承擔(dān)的責(zé)任及角色。如果架構(gòu)師不止一個(gè)，那么你應(yīng)該尊重當(dāng)前的組織架構(gòu)。

作為級(jí)別低的一方，最好是給出建議不是決策。此外，我建議始終和同伴一起評(píng)審關(guān)鍵決策。

④評(píng)估多個(gè)選項(xiàng)：在決策時(shí)，一定要有一個(gè)以上的選擇。在我參與的大多數(shù)案例中，有不止一個(gè)(好的)選擇。

只有一個(gè)選擇是不好的，兩個(gè)方面：首先，似乎你沒(méi)有做好你的工作，其次，它阻礙了做出正確的決定。

通過(guò)定義度量標(biāo)準(zhǔn)，可以基于事實(shí)而不是直覺(jué)(例如許可證成本或成熟度)比較選項(xiàng)。這通常會(huì)導(dǎo)致更好、更可持續(xù)的決策。

此外，向不同的利益相關(guān)者推銷決策也更容易。此外，如果沒(méi)有正確評(píng)估選項(xiàng)，則在討論時(shí)可能會(huì)遺漏一些因素。

化繁為簡(jiǎn)能力

請(qǐng)記住 Occam 剃刀的解決問(wèn)題的原則，它表示更喜歡簡(jiǎn)單。

我把這個(gè)原則解釋為：如果你對(duì)這個(gè)問(wèn)題有太多的假設(shè)要解決，那么你的解決方案可能是錯(cuò)誤的，或者導(dǎo)致不必要的復(fù)雜解決方案。為了得到一個(gè)好的解決方案，應(yīng)該減少(簡(jiǎn)化)假設(shè)。

①方案規(guī)整：為了簡(jiǎn)化解決方案，從不同的位置角度評(píng)估它們通常有助于清理、規(guī)整解決方案。嘗試通過(guò)自上而下和自下而上的思考來(lái)形成解決方案。

如果您有一個(gè)數(shù)據(jù)流或進(jìn)程，那么首先考慮從左到右，再?gòu)挠业阶??？梢蕴岢鲆恍﹩?wèn)題，比如：在一個(gè)完美的世界里，你的解決方案會(huì)怎么樣?或者：“X 公司/個(gè)人會(huì)怎么做?

其中 X 可能不是你的競(jìng)爭(zhēng)對(duì)手，而是 BAT(百度、阿里、騰訊)之一。這兩個(gè)問(wèn)題都迫使你減少 Occam 的 Razor 建議的假設(shè)。

②退一步：經(jīng)過(guò)激烈和長(zhǎng)時(shí)間的討論，得出的結(jié)果往往是高度復(fù)雜的草案。你永遠(yuǎn)不應(yīng)該把這些看作是最終的結(jié)果。

退一步：再看一眼大局(抽象層面)。還是有意義的嗎?然后在抽象的層次上再進(jìn)行一次重構(gòu)。

有時(shí)，停止討論并在第二天繼續(xù)討論會(huì)有幫助。至少我的大腦需要一些時(shí)間來(lái)處理和想出更好、更優(yōu)雅和更簡(jiǎn)單的解決方案。

③分而治之：把問(wèn)題分成小塊來(lái)簡(jiǎn)化。然后獨(dú)立解決。然后驗(yàn)證這些小塊是否匹配在一起。退一步看一下這個(gè)的整體情況。

④重構(gòu)不是壞事：如果找不到更好的主意，從更復(fù)雜的解決方案開(kāi)始完全可以。如果解決方案遇到麻煩，您可以稍后重新考慮解決方案并應(yīng)用您的學(xué)習(xí)。

重構(gòu)不是邪惡的，但是在開(kāi)始重構(gòu)之前，請(qǐng)記住要進(jìn)行以下工作：

• 進(jìn)行足夠的自動(dòng)化測(cè)試，以確保系統(tǒng)的正確功能。
• 從利益相關(guān)者得到的支持。要了解有關(guān)重構(gòu)的更多信息，建議閱讀《重構(gòu) 改進(jìn)現(xiàn)有代碼的設(shè)計(jì)》，作者是 Martin Fowler。

編碼能力

即使作為一個(gè)企業(yè)級(jí)架構(gòu)師，最抽象的架構(gòu)層次，你仍然應(yīng)該知道開(kāi)發(fā)人員每天都在做什么。

如果你不明白這是怎么做到的，你可能會(huì)面臨兩大問(wèn)題：

• 開(kāi)發(fā)者不會(huì)接受你的嘴炮。
• 不了解開(kāi)發(fā)人員的實(shí)踐需求和面臨的困難。

①有一個(gè)輔助項(xiàng)目：這樣做的目的是嘗試新技術(shù)和工具，以了解當(dāng)今和未來(lái)的開(kāi)發(fā)方式。

經(jīng)驗(yàn)是觀察，情感和假設(shè)的結(jié)合(Kurt Schneider 的“軟件工程中的經(jīng)驗(yàn)和知識(shí)管理”)。

閱讀教程或一些利弊是好的。但這僅僅是“書(shū)籍知識(shí)”。僅當(dāng)你自己嘗試事物時(shí)，才能體驗(yàn)到情緒并建立關(guān)于事物好壞的假設(shè)。

而且，使用某項(xiàng)技術(shù)的時(shí)間越長(zhǎng)，你的評(píng)估就會(huì)越準(zhǔn)確。這將幫助您在日常工作中做出更好的決定。

當(dāng)我開(kāi)始編程時(shí)，我沒(méi)有代碼完成，只有一些實(shí)用程序庫(kù)可以加快開(kāi)發(fā)速度。顯然，在這種背景下，我今天會(huì)做出錯(cuò)誤的決定。

今天，我們擁有大量的編程語(yǔ)言，框架，工具，過(guò)程和實(shí)踐。只有您對(duì)主要趨勢(shì)有一定的經(jīng)驗(yàn)和粗略的了解，才能參與對(duì)話并引導(dǎo)開(kāi)發(fā)朝正確的方向發(fā)展。

②找到合適的東西去嘗試：您無(wú)法嘗試所有內(nèi)容。這根本是不可能的。您需要一種更有條理的方法。

我最近發(fā)現(xiàn)的一種來(lái)源是 ThoughtWorks 的 Technology Radar。他們將技術(shù)，工具，平臺(tái)，語(yǔ)言和框架分為四類：采用，試用，評(píng)估和保留。

通過(guò)這種分類，更容易獲得新事物的概述及其準(zhǔn)備情況，以更好地評(píng)估下一步要探索的趨勢(shì)：

• 采用：已經(jīng)準(zhǔn)備好提供企業(yè)級(jí)服務(wù)。
• 試用：能夠在一個(gè)承擔(dān)一定風(fēng)險(xiǎn)的項(xiàng)目中嘗試。
• 評(píng)估：還需進(jìn)一步評(píng)估其對(duì)業(yè)務(wù)的影響。
• 保留：謹(jǐn)慎處理。

文檔架構(gòu)能力

架構(gòu)文檔有時(shí)更重要，有時(shí)則不重要。重要的文檔例如體系結(jié)構(gòu)決策或代碼指南。

在開(kāi)始編碼之前通常需要初始文檔，并且需要不斷改進(jìn)。其他文檔可以自動(dòng)生成，因?yàn)榇a也可以是文檔，例如 UML 類圖。

①代碼整潔：如果做對(duì)的話，代碼是最好的文檔。一個(gè)好的架構(gòu)師應(yīng)該能夠區(qū)分好的代碼和壞的代碼。

羅伯特·C·馬丁(Robert C. Martin)所著的《代碼整潔之道》一書(shū)是了解更多關(guān)于好壞代碼的寶貴資源。

②盡可能生成文檔：系統(tǒng)變化很快，很難更新文檔。無(wú)論是關(guān)于 API 還是以 CMDBs(配置管理數(shù)據(jù)庫(kù))形式出現(xiàn)的系統(tǒng)環(huán)境：底層信息通常變化太快，無(wú)法手動(dòng)更新相應(yīng)的文檔。

例如：對(duì)于 API，如果您是模型驅(qū)動(dòng)的，則可以基于定義文件自動(dòng)生成文檔，或者直接從源代碼生成文檔。有很多工具存在，比如 Swagger 和 RAML 是一些不錯(cuò)的初始選擇。

③必要而精簡(jiǎn)：無(wú)論您需要記錄什么文件(例如決策文件)，都應(yīng)嘗試一次只關(guān)注一件事，并且僅包含關(guān)于這件事的必要信息。大量的文檔很難閱讀和理解。附加信息應(yīng)存儲(chǔ)在附錄中。

特別是對(duì)于決策文件，講一個(gè)有說(shuō)服力的故事而不是僅僅發(fā)表大量論據(jù)，更為重要。此外，這為您和您的同事節(jié)省了很多時(shí)間，而后者需要閱讀。

看看您過(guò)去做過(guò)的一些文檔(源代碼，模型，決策文件等)，然后問(wèn)自己以下問(wèn)題：“是否包含所有必要的信息才能理解它?”，“確實(shí)需要哪些信息，并且可以省略嗎?”和“文檔中是否有紅線?”。

了解有關(guān)架構(gòu)框架的更多信息: 該點(diǎn)也可以應(yīng)用于所有其他“技術(shù)”點(diǎn)。我把它放在這里，是因?yàn)?TOGAF 或 Zachmann 之類的框架正在提供“工具”。

這些工具在文檔站點(diǎn)上感覺(jué)很沉重，盡管它們的附加值并不限于文檔。在這樣的框架中獲得認(rèn)證可以教會(huì)您更系統(tǒng)地解決體系結(jié)構(gòu)。

溝通能力

根據(jù)我的觀察，這是最被低估的技能之一。如果你在設(shè)計(jì)上很聰明，但不能傳達(dá)你的想法，你的想法可能會(huì)影響較小，甚至無(wú)法成功。

①學(xué)習(xí)如何傳達(dá)你的想法：在會(huì)議上進(jìn)行協(xié)作時(shí)，知道如何正確的溝通傳達(dá)你的想法，將其同步到你的同行是至關(guān)重要的。

我發(fā)現(xiàn)《 UZMO-用筆思考》是提高我在這一領(lǐng)域技能的好資源。作為架構(gòu)師，你通常不僅會(huì)參加會(huì)議，而且通常需要主持并主導(dǎo)會(huì)議。

②大型的演講：將你的想法呈現(xiàn)給小型或大型團(tuán)體應(yīng)該對(duì)您來(lái)說(shuō)可行。如果對(duì)此感到不舒服，請(qǐng)開(kāi)始向你最好的朋友介紹。

慢慢擴(kuò)大小組。這是你只能通過(guò)離開(kāi)自己的舒適區(qū)來(lái)學(xué)習(xí)的東西。請(qǐng)耐心等待，此過(guò)程可能需要一些時(shí)間。

③找到合適的溝通方式：不同的利益相關(guān)者有不同的利益和觀點(diǎn)。它們需要在各自的層面上用不同的方式單獨(dú)解決。

在你交流之前，退后一步，檢查你想分享的信息是否有正確的層次，關(guān)于抽象性、內(nèi)容、目標(biāo)、動(dòng)機(jī)等。

例如：開(kāi)發(fā)人員通常對(duì)解決方案的非常小的細(xì)節(jié)感興趣，而經(jīng)理則更喜歡知道哪個(gè)選項(xiàng)能節(jié)省最多的錢(qián)。

④經(jīng)常溝通：如果沒(méi)有人知道，再香的架構(gòu)也是毫無(wú)意義的。定期在每個(gè)組織級(jí)別上分發(fā)目標(biāo)體系結(jié)構(gòu)及其背后的思想。

安排與開(kāi)發(fā)人員、架構(gòu)師和管理人員的會(huì)議，向他們展示所需或定義的方式。

⑤透明：定期交流只能部分緩解缺少的透明度。您需要使決策背后的原因透明化。

特別是，如果人們不參與決策過(guò)程，則很難理解和遵循其背后的決策和理由。

⑥隨時(shí)準(zhǔn)備發(fā)表演講：總有人有疑問(wèn)，你想馬上給出正確的答案。盡量把最重要的幻燈片放在一個(gè)統(tǒng)一的集合里，你可以展示和解釋。它為你節(jié)省了很多時(shí)間，也給你自己帶來(lái)了安全感。

評(píng)估能力

①了解基本項(xiàng)目管理原則：作為架構(gòu)師或首席開(kāi)發(fā)人員，您經(jīng)常被要求估算實(shí)現(xiàn)您的想法：多長(zhǎng)時(shí)間、多少人、哪些技能等。

當(dāng)然，如果你計(jì)劃引入新的工具或框架，你需要對(duì)這些“管理”問(wèn)題有一個(gè)答案。最初，你應(yīng)該能夠給出一個(gè)粗略的估計(jì)，如天，月或年。

別忘了，它不僅僅是關(guān)于實(shí)現(xiàn)，還有更多的因素要考慮，比如需求管理、測(cè)試和 Bugfix。

因此，您應(yīng)該了解所使用的軟件開(kāi)發(fā)過(guò)程中的工作。通過(guò)過(guò)去的使用數(shù)據(jù)，你可以得到更好的評(píng)估，并從中得出你的預(yù)測(cè)。

如果你沒(méi)有過(guò)去的數(shù)據(jù)，你也可以嘗試一些方法，如巴里 W 鮑姆的 COCOMO。

如果你被分配在一個(gè)敏捷項(xiàng)目中，學(xué)習(xí)如何正確地進(jìn)行評(píng)估和計(jì)劃：Mike Cohn 的《敏捷評(píng)估和計(jì)劃》一書(shū)提供了這個(gè)領(lǐng)域的一個(gè)堅(jiān)實(shí)的概述。

②評(píng)估“未知”架構(gòu)：作為架構(gòu)師，您還應(yīng)該能夠評(píng)估體系結(jié)構(gòu)對(duì)于當(dāng)前或未來(lái)上下文的適用性。

這不是一項(xiàng)簡(jiǎn)單的任務(wù)，但是您可以通過(guò)手頭的一組問(wèn)題來(lái)準(zhǔn)備，這些問(wèn)題對(duì)于每個(gè)架構(gòu)都是常見(jiàn)的。

它不僅關(guān)乎體系結(jié)構(gòu)，還關(guān)乎系統(tǒng)的管理方式，因?yàn)檫@也讓您了解了系統(tǒng)的質(zhì)量。

我建議總是準(zhǔn)備好一些問(wèn)題并準(zhǔn)備好使用。一般問(wèn)題的一些想法：

• 設(shè)計(jì)實(shí)踐：架構(gòu)遵循哪些模式?它們是否得到正確使用?設(shè)計(jì)是否遵循紅線或是否存在不受控制的增長(zhǎng)?是否有明確的結(jié)構(gòu)和關(guān)注點(diǎn)的分離?
• 開(kāi)發(fā)實(shí)踐：制定并遵守規(guī)范指南?代碼的版本是怎樣的?部署實(shí)踐?
• 質(zhì)量保證：測(cè)試自動(dòng)化覆蓋范圍?靜態(tài)代碼分析到位且效果良好?同行評(píng)議到位?
• 安全性：有哪些安全概念?內(nèi)置安全?滲透測(cè)試或自動(dòng)安全分析工具到位并定期使用?

平衡能力

①質(zhì)量是有代價(jià)的：早些時(shí)候我談到了質(zhì)量和非功能性需求。如果過(guò)度使用架構(gòu)，將會(huì)增加成本，并可能降低開(kāi)發(fā)速度。你需要平衡架構(gòu)和功能需求。應(yīng)避免過(guò)度設(shè)計(jì)。

②解決矛盾目標(biāo)：矛盾目標(biāo)的典型例子是短期和長(zhǎng)期目標(biāo)。項(xiàng)目往往傾向于構(gòu)建最簡(jiǎn)單的解決方案，而架構(gòu)師考慮的是長(zhǎng)期的遠(yuǎn)景。

通常，簡(jiǎn)單的解決方案不適合長(zhǎng)期的解決方案，并且有可能在以后被丟棄(沉沒(méi)成本)。

為了避免實(shí)施方向錯(cuò)誤，需要考慮兩件事：

• 開(kāi)發(fā)人員和業(yè)務(wù)部門(mén)需要了解長(zhǎng)期愿景及其好處，以便調(diào)整其解決方案。
• 負(fù)責(zé)預(yù)算的經(jīng)理需要參與進(jìn)來(lái)，以了解財(cái)務(wù)影響。不一定要把 100% 的長(zhǎng)遠(yuǎn)眼光直接放在適當(dāng)?shù)奈恢?，但開(kāi)發(fā)出來(lái)的成本大體在預(yù)算范圍內(nèi)。

③沖突管理：架構(gòu)師往往是不同背景的多個(gè)群體之間的粘合劑。這可能會(huì)導(dǎo)致不同層次的溝通沖突。

為了找到一個(gè)平衡的解決方案，同時(shí)也反映長(zhǎng)期的戰(zhàn)略目標(biāo)，架構(gòu)師的角色往往是幫助克服沖突。

關(guān)于傳播理論的起點(diǎn)是舒爾茨·馮·圖恩的“四耳模型”?；诖四Ｐ?，可以顯示并推論很多。但是，該理論需要一些實(shí)踐，在交流研討會(huì)上應(yīng)該有經(jīng)驗(yàn)。

指導(dǎo)、答疑能力

在咨詢和輔導(dǎo)方面，積極主動(dòng)可能是最好的選擇。如果有人問(wèn)你，那就太晚了。架構(gòu)重構(gòu)是盡量要避免的。

你需要以某種方式預(yù)見(jiàn)未來(lái)幾周、幾個(gè)月甚至幾年，并為下一步做好準(zhǔn)備：

①有遠(yuǎn)見(jiàn)：如果你參與在一個(gè)項(xiàng)目中，無(wú)論是傳統(tǒng)的瀑布式方法還是敏捷方法，你始終需要對(duì)要實(shí)現(xiàn)的中長(zhǎng)期目標(biāo)有一個(gè)愿景。

這不是一個(gè)詳細(xì)的概念，而是針對(duì)每個(gè)人都可以落地的路線圖。由于無(wú)法一次完成所有工作(這是一段旅程)，因此我更喜歡使用成熟度模型。

它們給出了易于使用的清晰結(jié)構(gòu)，并且每次都給出了當(dāng)前的進(jìn)度狀態(tài)。對(duì)于不同的方面，我使用不同的模型，例如開(kāi)發(fā)實(shí)踐或持續(xù)交付。

成熟度模型中的每個(gè)級(jí)別都有明確的要求，這些要求遵循 SMART 準(zhǔn)則，以便輕松衡量是否已達(dá)到要求。我發(fā)現(xiàn)一個(gè)很好的例子是持續(xù)交付。

②建立實(shí)踐社區(qū)(CoP)：在一個(gè)共同興趣小組之間交流經(jīng)驗(yàn)和知識(shí)有助于分發(fā)思想和標(biāo)準(zhǔn)化方法。

例如，你可以每三個(gè)月左右將所有 JavaScript 開(kāi)發(fā)人員和架構(gòu)師聚集在一個(gè)房間中，討論過(guò)去和當(dāng)前的挑戰(zhàn)以及如何解決它們或采用新的方法論和方法。架構(gòu)師可以共享，討論和調(diào)整其愿景，開(kāi)發(fā)人員可以共享經(jīng)驗(yàn)并向同行學(xué)習(xí)。

這樣的交流不僅可以為企業(yè)帶來(lái)極大的好處，而且對(duì)個(gè)人本身也非常有利，因?yàn)樗兄诮⒏鼜?qiáng)大的網(wǎng)絡(luò)并傳播思想。

還可以查看 SAFe 框架中的文章實(shí)踐社區(qū)，該文章在敏捷環(huán)境中解釋了 CoP 概念。

③進(jìn)行公開(kāi)會(huì)議：誤解或模棱兩可的一個(gè)原因是缺乏溝通。在固定的時(shí)間段內(nèi)，例如每周 30 分鐘，與同事交流熱門(mén)話題。

這次會(huì)議沒(méi)有議程，一切都可以討論。盡量當(dāng)場(chǎng)解決小事。安排對(duì)更復(fù)雜主題的跟進(jìn)。

營(yíng)銷推廣

你的想法很好，你已經(jīng)很好地溝通了，但是仍然沒(méi)有人愿意追隨?那么你可能缺乏營(yíng)銷技巧。

①激勵(lì)和說(shuō)服：公司如何說(shuō)服你購(gòu)買(mǎi)產(chǎn)品?他們證明了它的價(jià)值和好處。但不止如此。他們包裝得很好，并使其盡可能容易消化：

• 原型：展示你想法的原型。有很多創(chuàng)建原型的工具。在喜歡 SAP 的企業(yè)背景下，可以查看 build.me，在其中您可以快速輕松地創(chuàng)建漂亮且可點(diǎn)擊的 UI5 應(yīng)用程序。
• 視頻：與“無(wú)聊的 PPT”不同的是，你還可以播放一段視頻，展示你的想法或至少方向。

但請(qǐng)不要過(guò)度營(yíng)銷，從長(zhǎng)遠(yuǎn)來(lái)看，內(nèi)容是王道。如果你的話沒(méi)有實(shí)現(xiàn)，從長(zhǎng)遠(yuǎn)來(lái)看，這將損害你的聲譽(yù)。

②堅(jiān)持自己的想法：有些時(shí)候人們不喜歡你的想法，或者他們太懶了，不喜歡你的想法。

如果你真的被自己的想法所說(shuō)服，你就應(yīng)該不斷地去追求它們，并“戰(zhàn)斗”。有時(shí)這是必要的。

具有長(zhǎng)期目標(biāo)的架構(gòu)決策通常不是最簡(jiǎn)單的：開(kāi)發(fā)人員不喜歡它們，因?yàn)樗鼈兏鼜?fù)雜。

經(jīng)理們不喜歡他們，因?yàn)樗麄冊(cè)诙唐趦?nèi)更貴。這是你的工作，你要堅(jiān)持和談判。

③尋找盟友：建立或執(zhí)行你自己的想法可能是困難的，甚至是不可能的。努力尋找能夠支持和幫助說(shuō)服他人的盟友。使用你的網(wǎng)絡(luò)。

如果你還沒(méi)有，現(xiàn)在就開(kāi)始建造它。你可以先和你的(思想開(kāi)放的)同齡人談?wù)勀愕南敕ā?/p>

如果他們喜歡，或者至少部分喜歡，如果別人問(wèn)他們，他們很可能會(huì)支持你的想法(“X 的想法很有趣。”)。

如果他們不喜歡，問(wèn)為什么：也許你錯(cuò)過(guò)了什么?或者你的故事不夠有說(shuō)服力?下一步是找到有決策權(quán)的盟友。

要求開(kāi)誠(chéng)布公的討論。如果你害怕討論，記住有時(shí)候你需要離開(kāi)你的舒適區(qū)。

④重復(fù)一遍，相信它：“ 研究表明，反復(fù)接觸某個(gè)觀點(diǎn)會(huì)使人們相信該觀點(diǎn)更為普遍，即使該觀點(diǎn)僅來(lái)自一個(gè)人也是如此。”(來(lái)源：《金融品牌》)如果您經(jīng)常發(fā)布很少的信息，則可以幫助您說(shuō)服人們更容易。

但請(qǐng)注意：從我的角度來(lái)看，應(yīng)該明智地使用這種策略，因?yàn)樗赡苓m得其反，成為糟糕的營(yíng)銷技巧。

相關(guān)書(shū)籍：

• Refactoring. Improving the Design of Existing Code by Martin Fowler
• Enterprise Integration Patterns written by Gregor Hohpe
• Design Patterns: Elements of Reusable Object-Oriented Software by John Vlissides, Ralph Johnson, Richard Helm, Erich Gamma
• Experience and Knowledge Management in Software Engineering by Kurt Schneider
• Clean Code by Robert C. Martin
• UZMO — Thinking With Your Pen
• Agile Estimating and Planning by Mike Cohn

作者：Justin Miller

編輯：陶家龍、孫淑娟

出處：https://github.com/gamedilong/SoftwareArchitect-CN

原文：https://github.com/justinamiller/SoftwareArchitect