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

[[314313]] 

圖片來自 Pexels 

幾年前有人問我：你是怎么成為一名軟件架構(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)師。
• 軟件架構(gòu)是系統(tǒng)的基本組織構(gòu)成，這種組織主要體現(xiàn)在其組件、組件之間的關(guān)系、組件與環(huán)境之間的關(guān)系，以及決定系統(tǒng)設(shè)計與演化的原則。

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

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

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

• 應(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)行溝通了。

有時候，架構(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è)計。

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

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

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

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

設(shè)計能力

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

⑤分析和理解應(yīng)用模式：看一下當(dāng)前的任一比較流行的框架，例如 Angular?？梢栽趯嵺`中研究很多模式，例如“觀察者模式”。

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

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

決策能力

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

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

個人評估某件事是否重要，通常考慮如下兩點：

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

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

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

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

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

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

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

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

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

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

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

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

化繁為簡能力

請記住 Occam 剃刀的解決問題的原則，它表示更喜歡簡單。

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

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

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

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

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

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

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

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

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

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

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

編碼能力

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

如果你不明白這是怎么做到的，你可能會面臨兩大問題：

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

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

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

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

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

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

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

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

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

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

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

文檔架構(gòu)能力

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

在開始編碼之前通常需要初始文檔，并且需要不斷改進(jìn)。其他文檔可以自動生成，因為代碼也可以是文檔，例如 UML 類圖。

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

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

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

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

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

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

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

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

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

溝通能力

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

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

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

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

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

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

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

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

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

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

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

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

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

評估能力

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

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

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

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

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

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

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

這不是一項簡單的任務(wù)，但是您可以通過手頭的一組問題來準(zhǔn)備，這些問題對于每個架構(gòu)都是常見的。

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

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

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

平衡能力

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

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

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

為了避免實施方向錯誤，需要考慮兩件事：

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

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

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

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

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

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

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

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

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

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

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

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

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

這樣的交流不僅可以為企業(yè)帶來極大的好處，而且對個人本身也非常有利，因為它有助于建立更強(qiáng)大的網(wǎng)絡(luò)并傳播思想。

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

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

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

營銷推廣

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

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

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

但請不要過度營銷，從長遠(yuǎn)來看，內(nèi)容是王道。如果你的話沒有實現(xiàn)，從長遠(yuǎn)來看，這將損害你的聲譽(yù)。

②堅持自己的想法：有些時候人們不喜歡你的想法，或者他們太懶了，不喜歡你的想法。

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

具有長期目標(biāo)的架構(gòu)決策通常不是最簡單的：開發(fā)人員不喜歡它們，因為它們更復(fù)雜。

經(jīng)理們不喜歡他們，因為他們在短期內(nèi)更貴。這是你的工作，你要堅持和談判。

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

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

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

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

要求開誠布公的討論。如果你害怕討論，記住有時候你需要離開你的舒適區(qū)。

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

但請注意：從我的角度來看，應(yīng)該明智地使用這種策略，因為它可能適得其反，成為糟糕的營銷技巧。

相關(guān)書籍：

• 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