架構(gòu)師必備的37項技能清單-魔扣目錄

幾年前，我被問到“你是如何變成一名架構(gòu)師的？”。基于這個話題，我們討論了很多，比如必要的技術(shù)、經(jīng)驗以及所需要的知識儲備等。這一次討論促使我開始思考要成為一名架構(gòu)師應(yīng)該具備和學(xué)習(xí)的東西有哪些，成為一個優(yōu)秀的架構(gòu)師應(yīng)該具備哪些能力和做哪些事情。為此我查閱資料，走訪各位大佬，當(dāng)然也結(jié)合自己的經(jīng)歷，最終我輸出了今天這樣一篇文章，希望通過閱讀此文，你可以從此知道自己的架構(gòu)師之路該怎么走。

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

在開始具體的細(xì)節(jié)之前，我們先來理清兩個定義。

A software architect is a software expert who makes high-level design choices and dictates technical standards, including software coding standards, tools, and platforms. The leading expert is referred to as the chief architect.

軟件架構(gòu)師是一個軟件專家，他（她）負(fù)責(zé)做出高階設(shè)計選擇和輸出技術(shù)標(biāo)準(zhǔn)，包括軟件編碼標(biāo)準(zhǔn)、工具和平臺（框架）。首席專家（leading expert）也被稱為首席架構(gòu)師（chief architect）。

(來源: Wikipedia: Software Architect)

Software architecture is the fundamental organization of a system, represented by its components, their relationships to each other and to the environment, and the principles that determine the design and evolution of the system.

軟件架構(gòu)是一個系統(tǒng)的基本（基礎(chǔ)）組織。包含組件，他們之間的關(guān)系以及與周邊的關(guān)系，設(shè)計原則，以及系統(tǒng)演進(jìn)。

(來源: Handbook of Software Architecture)

架構(gòu)的級別

架構(gòu)可以被抽象為幾個級別（level）。級別決定了要選擇哪些對應(yīng)的技術(shù)。市面上有多種分類方式，我個人喜歡把它分為三個級別：

應(yīng)用級別（Application Level）: 架構(gòu)最下層級別（lowest level）。只關(guān)注一個單一的應(yīng)用。非常的關(guān)注細(xì)節(jié)，關(guān)注底層設(shè)計（ Very detAIled, low level design）。溝通往往只限于開發(fā)團(tuán)隊內(nèi)部。
解決方案級別（Solution Level）: 架構(gòu)的中間級別（mid-level）。關(guān)注的是一個或多個應(yīng)用，從而滿足某個業(yè)務(wù)需求 (業(yè)務(wù)解決方案)。有點高，但主要還是low-level設(shè)計。溝通跨多個開發(fā)團(tuán)隊。
企業(yè)級別（Enterprise Level）: 架構(gòu)最高級別。關(guān)注多個解決方案（solution）。高級（High level）, 抽象設(shè)計（abstract design）, 需要總覽全局，總覽多個解決方案和多個應(yīng)用架構(gòu)師。溝通橫跨整個組織。

有時候，架構(gòu)師是也被戲稱為“膠水（粘合劑）”，不同利益相關(guān)者之間的膠水，舉三個例子：

水平: 業(yè)務(wù)、開發(fā)人員或不同開發(fā)團(tuán)隊之間的溝通橋梁。
垂直: 開發(fā)人員和管理人員之間的溝通橋梁。
技術(shù): 不同技術(shù)或項目（產(chǎn)品）之間的集成橋梁。

軟件架構(gòu)師要做的幾個典型活動

在搞清楚要使用的技術(shù)之前，我們先要明白軟件架構(gòu)師要做的幾個典型的活動。以下是我梳理的幾個典型的活動：

確定和決定要使用的開發(fā)技術(shù)和平臺。
定義開發(fā)標(biāo)準(zhǔn)。比如，編碼標(biāo)準(zhǔn)，工具，代碼review流程，測試方法等。
協(xié)助識別和理清業(yè)務(wù)需求。
設(shè)計系統(tǒng)和基于需求做出決策。
記錄和溝通架構(gòu)定義、設(shè)計和決策（Document and communicate architectural definitions, design and decisions）。
檢查和review架構(gòu)和代碼。比如，檢查確定的模式和編碼標(biāo)準(zhǔn)的實現(xiàn)是否合理。
與其他的架構(gòu)師和利益相關(guān)者協(xié)作。
開發(fā)人員的教練和顧問。
細(xì)化并把high level的設(shè)計具體到low level設(shè)計。

注意：架構(gòu)是一個持續(xù)的活動，尤其是在敏捷開發(fā)團(tuán)隊中。因此，這些活動得一遍一遍的重復(fù)迭代， over and over again。

軟件架構(gòu)師要掌握的重要技能

為了能夠支撐上面列出的活動，軟件架構(gòu)師需要一些必備的技能。根據(jù)我過往的經(jīng)歷，以及翻閱資料以及與大佬們進(jìn)行討論，最后得出了如下軟件架構(gòu)師必備的10個重要技能：設(shè)計，決策，簡化，代碼，文檔，溝通，評估，權(quán)衡，顧問，營銷。

接下來我們一個個說。對于每種技能，我都提出了一些行動或見解，你可以根據(jù)這些來改進(jìn)你的工作。

1、設(shè)計

什么是好的設(shè)計？這個可能是一個非常重要同時又要挑戰(zhàn)性的問題。分為理論和實踐。就我的經(jīng)驗，二者的結(jié)合是最有價值的。

1）知道基礎(chǔ)的設(shè)計模式：模式是一個非常重要的工具，是架構(gòu)師開發(fā)可維護(hù)系統(tǒng)的重要工具之一。記住，你要想開發(fā)出可維護(hù)的系統(tǒng)，請記得適當(dāng)?shù)剡\用設(shè)計模式。通過模式你可以重用那些已經(jīng)被證明可以解決常見問題的設(shè)計思路。去看看GoF（Gang of Four）寫的有關(guān)設(shè)計模式的書吧，盡管這些模式已經(jīng)20多年了，但依然是現(xiàn)代軟件架構(gòu)的基礎(chǔ)。比如Model-View-Controller (MVC) 模式就可以用于多個領(lǐng)域，甚至是一些更新的模式的基礎(chǔ)，比如MVVM。

2）對模式和反模式進(jìn)一步鉆研：如果你已經(jīng)知道了所有基礎(chǔ)的GoF設(shè)計模式，接下來可以擴展自己的知識儲備去學(xué)習(xí)更多的軟件設(shè)計模式，或?qū)δ愀信d趣的領(lǐng)域進(jìn)行垂直鉆研。我個人比較喜歡Gregor Hohpe寫的一本書叫：Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions。這本書主要的內(nèi)容是系統(tǒng)之間的數(shù)據(jù)交換（應(yīng)用集成方面）。

3）知道質(zhì)量度量（quality measures）：確定和定義架構(gòu)不是終點。你還需要讓你的系統(tǒng)可維護(hù)、可靠、適應(yīng)性好、安全、可測試、可擴展、可重用等。所有這些都滿足了，才算是一個好的架構(gòu)。你可以去百科上去看看有關(guān)quality measures的內(nèi)容。不過理論固然重要，但實戰(zhàn)同樣重要，甚至更重要。千萬不要變成“象牙塔架構(gòu)師”（http://www.gitshah.com/2011/01/ivory-tower-architect.html）。

4）嘗試并了解不同的技術(shù)棧：我認(rèn)為這是非常重要的，如果你想變成一個更好的架構(gòu)師的話。嘗試去了解新的技術(shù)棧，然后學(xué)習(xí)下這些技術(shù)是怎么實現(xiàn)的。不同的新的技術(shù)一般是使用不同的設(shè)計思路和模式。簡單地去看看PPT之類的你可能并不能學(xué)到什么，你只有親自去實踐了，才會感受到痛苦和甜蜜。一個架構(gòu)師不能只是面廣，在某些領(lǐng)域還要扎得深。也許hold住所有的技術(shù)棧不是最重要的，但你需要在你的某個最重要的領(lǐng)域要有獨到和扎實的見解。同時你也學(xué)習(xí)一下不屬于你領(lǐng)域的技術(shù)，比如你是JAVA，那么你也要學(xué)習(xí)一下JavaScript等前端語言或技術(shù)，反之亦然。

5）分析和了解框架中應(yīng)用的設(shè)計模式：你可以去研究當(dāng)前任何開源的或正在使用的框架，比如Angular. 你可以學(xué)習(xí)到在實踐中的很多設(shè)計模式，比如Observables。嘗試去搞懂該模式在這個框架中是如何被使用的，為什么它這么做。如果你真的狂熱，也可以看看源碼并且搞懂它是如何實現(xiàn)的。

6）保持好奇并去參加各種技術(shù)聚會：在德國，我們有個Java User Group (JUG) 組織，這個組織在每個大點的城市都有。我們會討論各種topic，從low level的編碼到上層的有關(guān)架構(gòu)的主題。我真的熱愛這些活動，因為它可以增強你的思維能力和擴大你個人的社交網(wǎng)絡(luò)。

2、決策（決定）

架構(gòu)師需要能夠做決定并且引導(dǎo)項目或整個組織朝著正確的方向邁進(jìn)。

1）知道什么是重要的：不要浪費時間在那些不重要的決定或活動上，學(xué)會認(rèn)識什么是重要的。目前看來也沒什么書籍教你識別這些。我個人有個原則，每當(dāng)我要評價一件事是否重要我就會考慮這兩個方面：

概念完整性（Conceptional Integrity）: 如果你決定以某種方式去做，那么就干，即使有時候會有更優(yōu)的方案。通常來說，這會使得你有一個直接的全局的概念，使得更容易理解和更容易維護(hù)。
統(tǒng)一性（Uniformity）:比如如果你有名稱的一些約定，當(dāng)然無論是小寫還是大寫，至少讓每個地方都是用同樣的方式，比較統(tǒng)一。

2）優(yōu)先級： 有關(guān)這方面建議去看一下Weighted Shortest Job First (WSJF) 模型，這個模型被廣泛用于敏捷軟件開發(fā)中。尤其是時間緊迫性（ time criticality）和降低風(fēng)險（risk reduction）對于評估架構(gòu)決策優(yōu)先級至關(guān)重要。

3）知道自己的能力： 不要對你不了解的事情做決策和決定。各級干各級的事情，要理清每一層的責(zé)任，然后對你所負(fù)責(zé)的層去做決策。如果有多個架構(gòu)師，那么你應(yīng)該遵循目前你所安排的架構(gòu)級別。作為一個lower level架構(gòu)師，如果對higher level的架構(gòu)不滿意，可以提建議，而不是做決定。此外，我建議始終與同伴一起檢查關(guān)鍵決策。

4）評估多個選項：應(yīng)該總是給出多種方案，這樣才能進(jìn)行做出決策和決定。不要只給一個方案，聽著感覺就是你沒有認(rèn)真工作一樣。另外只有一個方案的時候，也沒法做出一個合理的選擇，因為只有一個方案。另外就是要定義一些指標(biāo)和標(biāo)準(zhǔn)，通過這個來衡量哪個方案好，哪個方案不好，最好不要去憑感覺。比如：license花費或成熟度（本文有講到成熟度模型）。這樣才能做出一個更好的決策。

3、簡化（化繁為簡）

記住一個解決問題的原則Occam’s Razor。這個原則告訴你解決問題要簡單。這個原則里有一句話叫：最簡單的那個solution往往是最好的。我總結(jié)這個原則的核心是：如果你對某個問題有多個假定解決方案，這很有可能就是錯的，或者導(dǎo)致沒必要的復(fù)雜的解決方案。多個假定方案應(yīng)該被簡化到只有一個好的解決方案。別提出來一大堆解決方案，說這個也可以，那個也可以，說明是有問題的。

1）矯正解決方案：通過對解決方案的矯正，有助于你發(fā)現(xiàn)最簡單的那個方案，通過從不同的角度和位置去看，往往會得到不錯的效果。你可以從上到下的想一遍，然后再從下到上的想一遍。如果你有一個數(shù)據(jù)流（data flow）或流程，那么你可以先從左往右想一遍，然后從右往左想一遍。與此同時問自己一個問題：“在理想的世界里，你的解決方案會發(fā)生什么？” 或：“公司或指定人員會做什么？” 這兩個問題會強迫你把解決方案減少到如Occam’s Razor建議的那樣。

2）退一步海闊天空: 經(jīng)過了激烈而漫長的討論，通常會得出一個高度復(fù)雜的涂鴉。但千萬也永遠(yuǎn)都不應(yīng)將這個視為最終結(jié)果。這時候，你需要后退一步：再次查看全局（抽象級別）。回到最初的本心，還是有意義嗎？然后再次在抽象級別上進(jìn)行遍歷并進(jìn)行重構(gòu)。做這一步有時候讓結(jié)論更加清晰，而不至于第二天繼續(xù)進(jìn)行方案的討論。至少我的大腦需要一些時間來處理并提出更好，更優(yōu)雅，更簡單的解決方案。人的腦子是需要時間來思考的。

3）分解成一個個小問題（Divide and Conquer）: 簡化問題的一個好辦法就是把問題切分成多個小問題然后挨個解決。這讓我想起了自己小時候打掃院落的場景，看著偌大一個院子，看著就煩，于是我決定把院子劃分成三個小塊，然后一個個去打掃，這讓我的心理負(fù)擔(dān)減輕了不少。一個個小塊打掃完了，最后再整體查看下整個院子還有沒有邊邊角角的地方需要打掃。總覽一下全局，然后整個院子就打掃完了。再枯燥的生活，都可以發(fā)現(xiàn)一些樂趣。

4）重構(gòu)并不可恥: 有時候，你可能一時半會想不到更簡單的方案，你不妨就從一個復(fù)雜的方案開始做起，先做著，等到之后再進(jìn)行重構(gòu)，這時候再去重新思考解決方案。重構(gòu)并不可恥，但重構(gòu)之前要注意一件事情：足夠的自動化測試以確保你所重構(gòu)的地方的功能正確和滿足利益相關(guān)者的需求。學(xué)習(xí)更多重構(gòu)的知識，我建議你可以讀讀《重構(gòu)、改善既有代碼的設(shè)計》 “Refactoring. Improving the Design of Existing Code” ，這本書是 Martin Fowler寫的。

4、代碼

即使你是一個企業(yè)級別的架構(gòu)師，就最頂層的那種架構(gòu)，你依然應(yīng)該知道開發(fā)人員在他們每天的工作中主要做些什么。如果你不能明白某個東西如何實現(xiàn)的，你可能會面臨兩個主要問題：

開發(fā)人員有可能不會接受你說的。
你也不會明白開發(fā)人員要什么和面臨的挑戰(zhàn)。

1）有個輔助項目（Have a side project）: 跟進(jìn)一個輔助項目，可以讓你了解到新的技術(shù)和工具，以了解到當(dāng)今和未來的開發(fā)方式。Kurt Schneider寫的“Experience and Knowledge Management in Software Engineering”（軟件工程中經(jīng)驗和知識管理）一書中說經(jīng)驗是所見、情感和假設(shè)的結(jié)合。看書固然是好事，但這只是書本知識（book knowledge）。只有當(dāng)你自己嘗試去做事情本身，然后你感受到情感和發(fā)生情緒，然后有了對事物好壞的判斷。你使用技術(shù)的時間越長越能做出正確的評判。這有助于你在日常的工作中做出正確的判斷。當(dāng)前有大量的語言和框架，只有你對這些有一定的經(jīng)驗和了解后才能做出正確的決策，從而引導(dǎo)開發(fā)人員朝著正確的方向邁進(jìn)。還是那句話，記住經(jīng)驗的定義：所見、情感和假設(shè)。要想有經(jīng)驗就要去動手！

2）找到正確的事去嘗試：你不可能去嘗試所有事情。這是不可能的。你需要一個更加結(jié)構(gòu)化的方法。有一個來自ThoughtWorks不錯的方法是技術(shù)雷達(dá)（Technology Radar）。他們把技術(shù)、工具、平臺、語言和框架分為四類：Adopt，Trial，Assess 和 Hold。Adopt（采用）意思是 “強烈的感覺到已經(jīng)可投入到生產(chǎn)中使用了”，Trial（試用）意思是 “可以先在某個項目中做嘗試，在這個項目中做到風(fēng)險可控”， Assess（調(diào)研）意思是“可以探索下對公司有哪些影響”， Hold（保留）意思是 “謹(jǐn)慎使用”。通過這種分類，更容易獲得新技術(shù)的整體情況及其準(zhǔn)備情況，以更好地評估下一步要干什么。

5、文檔

架構(gòu)文檔有時候很重要，但有時候又不重要。重要的文檔比如架構(gòu)決策或編碼指導(dǎo)手冊。編碼開始之前通常需要初始文檔，并且需要不斷完善。其他文檔可以自動生成，因為代碼也可以是文檔，例如UML類圖。

1）Clean Code：代碼是最好的文檔，如果你寫得足夠好。一個好的架構(gòu)師要有能力分辨出好代碼和爛代碼。著名的書：“Clean Code”。

2）如果可能的話，盡可能自動生成文檔：手動寫文檔的壞處不多說，把 Swagger 和 RAML 或者公司內(nèi)部開發(fā)的文檔系統(tǒng)快點用起來吧。

3）文檔盡可能少（As much as necessary, as little as possible）：文檔盡量少。無論您需要寫什么文檔（例如決策文檔），都應(yīng)嘗試一次只關(guān)注一件事，并且僅包含關(guān)于這件事的必要信息。大量的文檔很難閱讀和理解。附加信息應(yīng)放在附錄中。特別是對于決策文件，講一個有說服力的故事更為重要而不是僅僅發(fā)表大量的論證。而且，這可以為你和你的同事節(jié)省很多時間，因為他們要閱讀你的文檔。看看你過去輸出過的一些文檔（源代碼，模型，決策文件等），然后問自己以下問題：“是否包含所有必要的信息才能理解它？”，“確實需要哪些信息？可以省略嗎？”和“文檔中是否有紅線？”。一句話，不要廢話。

6、溝通

不多說，溝通很重要。

1）學(xué)習(xí)怎么和別人溝通你的觀點： 推薦一本書 “UZMO — Thinking With Your Pen” 。作為架構(gòu)師你經(jīng)常參會，甚至主持會議，所以你得學(xué)會如何和人們溝通你的想法。

2）通過演講宣貫：一開始你可以向你身邊的朋友表達(dá)，然后范圍慢慢擴大，最后向眾多人演講來表述你的觀點。如果你對此感到不適，你需要走出舒適區(qū)來加強提高這一點。保持耐心，這個可能需要一些時日。（有時候大佬的一句鼓勵，會讓你釋放掉過往的不自信，開始相信即使最差發(fā)揮大家都會感覺到還不錯。）

3）確定溝通的人群level：不同的利益相關(guān)者有不同的興趣和視角。不同的人群需要單獨的針對某一級別的人群去定向溝通。在溝通之前，請確認(rèn)你要溝通的人群，比如抽象性、內(nèi)容、目標(biāo)、動機等。比如開發(fā)人員關(guān)注一些解決方案的微小細(xì)節(jié)，而管理者更傾向怎么省錢。

4）經(jīng)常溝通：一個再好的架構(gòu)沒人知道它的價值依然為零。分發(fā)對應(yīng)級別的架構(gòu)，然后安排會議與開發(fā)者、架構(gòu)師和管理者分享未來的和已經(jīng)在踐行的架構(gòu)。

5）要透明：定期的溝通只能部分緩解透明度問題。你需要把決策的原因透明化。特別有的人可能沒有參加決策過程的情況下會很難理解決策以及其背后的原因。

6）隨時準(zhǔn)備演講：把常見問題放在一個顯眼（易找到）的地方，隨時應(yīng)對人們提出的問題，這樣有時候會保護(hù)你。

7、估算和評估

1）知道基本的項目管理和原則： 作為架構(gòu)師你經(jīng)常會被問到如下問題，多久完成？得花多少錢？需要幾個人？用到哪些技術(shù)？等。你需要學(xué)習(xí)一些估算技能。比如敏捷中的估算法等，建議到網(wǎng)上查閱這部分的資料。

2）評估未知架構(gòu)（Evaluate “unknown” architecture）：作為一個架構(gòu)師你也要能夠去評估架構(gòu)的適用性，針對目前和將來的適用性。這不是一個簡答的事情，但你可以準(zhǔn)備一些問題，然后去使用，以下是一些通用的問題：

①設(shè)計實踐：

這個架構(gòu)用了哪個模式？有沒有被正確的使用？
這個設(shè)計遵循紅線（red line）了嗎？這個設(shè)計有沒有能夠可持續(xù)（uncontrolled growth）？
有沒有一個清晰的結(jié)構(gòu)和各自領(lǐng)域的單獨關(guān)注有沒有分布合理？

②開發(fā)實踐：

代碼指引手冊有沒有到位？遵循了嗎？
代碼版本管理怎么做的？有沒有版本化？
部署是怎么分布的？

③質(zhì)量保障：

自動化測試覆蓋率怎么樣?
靜態(tài)代碼分析有沒有做？分析結(jié)果怎么樣？交叉檢查有沒有做？

④安全：

有哪些安全概念到位？
內(nèi)置安全？
滲透測試或自動安全分析工具是否到位，經(jīng)常在用嗎？

8、權(quán)衡（balance）

1）質(zhì)量是有代價的：早先我談到過質(zhì)量和非功能性需求。如果你過度設(shè)計架構(gòu)，則會增加成本，并可能降低開發(fā)速度。你需要權(quán)衡架構(gòu)和功能需求。應(yīng)避免過度設(shè)計。

2）解決矛盾目標(biāo)：一個典型的矛盾目標(biāo)的例子就是短期和長期目標(biāo)。項目往往趨向于構(gòu)建一個最簡單的方案來解決問題而架構(gòu)師則具有長期的眼光和愿景。一般情況下，最簡單的方案往往都不能滿足長期目標(biāo)和愿景。為了避免技術(shù)實現(xiàn)步入錯誤的方向，有兩件事情需要考慮：

開發(fā)人員和業(yè)務(wù)需要明白長期愿景和目標(biāo)，知道調(diào)整成新的解決方案可以帶來好處。
負(fù)責(zé)預(yù)算的管理人員需要知道對財務(wù)的影響，沒有必要100%站在長期愿景一邊。

3）沖突管理：架構(gòu)師經(jīng)常是多個不同背景的團(tuán)隊的粘合劑（膠水）。有時候在不同的level之間的交流會發(fā)生沖突，需要你去找到一個平衡的解決方案，這可能會對長期戰(zhàn)略的目標(biāo)造成影響。我的解決之道是Schulze von Thun的四眼模型（ “Four-Ears Model” of Schulze von Thun）。基于這個模型，可以幫你搞定一些事情。但這個理論需要多實踐幾次才能熟練掌握，可以在交流研討會上多用幾次。

9、顧問和教練

主動詢問，而不是被動等待，而且你需要有預(yù)見，預(yù)見接下來的幾周內(nèi)會發(fā)生什么，然后規(guī)劃相應(yīng)的步驟。

1）有遠(yuǎn)見：如果你被分配入一個項目，不管是傳統(tǒng)的瀑布式方法還是敏捷方法，你總是需要有一個你要完成的中期和長期目標(biāo)。這不是一個具體的涉及到細(xì)節(jié)的概念，更多的是一個road-map，可以引導(dǎo)每個人進(jìn)行工作。由于你不可能一次完成所有事情，它是一個長期持續(xù)的過程，我傾向使用成熟度模型（maturity models）。它可以給出一個清晰的結(jié)構(gòu)，這個結(jié)構(gòu)容易落地而且每次都能給出當(dāng)前進(jìn)度所處的狀態(tài)。對于不同的方面，我使用不同的模型。比如，開發(fā)實踐或持續(xù)交付。在成熟度模型中，每個level都有清晰的指標(biāo)，這些指標(biāo)都遵循SMART原則，這樣就能衡量你是否完成了目標(biāo)。一個不錯的例子就是持續(xù)交付，這個你可以看看有關(guān)持續(xù)交付的文章，其中就用到了成熟度模型來衡量持續(xù)交付的水平。

2）構(gòu)建實踐社區(qū) (CoP：community of practice)：在一個有共同興趣愛好的組織中，交換經(jīng)驗和知識有助于分享想法和統(tǒng)一方法。比如你可以把所有的Java開發(fā)和架構(gòu)師們聚集起來在一個屋子里，每隔三個月，討論過去和現(xiàn)在面臨的挑戰(zhàn)并且分享他們是如何解決問題的，他們的一些新的方法論和解決方法。架構(gòu)師們可以分享、討論和對齊他們的愿景，開發(fā)人員可以分享經(jīng)驗經(jīng)歷，然后相互學(xué)習(xí)。這樣的回合非常有利于公司，也有利于個人自己的發(fā)展。因為它有助于建立更強大的網(wǎng)絡(luò)和傳播思想。可以去看看這篇來自SAFe Framework的Communities of Practice，它解釋了在敏捷環(huán)境中的CoP的概念。

3）進(jìn)行公開討論：造成誤解和模棱兩可的源頭之一就是缺乏溝通。每周花三十分鐘的時間來和同伴交換熱門主題。這樣的討論可以沒有議程，任何事情都可以討論。也可以嘗試總是當(dāng)場解決小事。對于更復(fù)雜的主題則需要專門安排時間。

10、營銷

你的點子和架構(gòu)再好，當(dāng)你講給別人聽的時候，沒人響應(yīng)你，那么說明你可能缺乏一些營銷技能。

1）激勵并說服：別人憑什么買你的產(chǎn)品？你需要展示產(chǎn)品的價值和好處。你可以說出幾個核心的點，比如5個點或3個點，你需要包裝的好，而且讓別人容易理解（這里不是讓你過分（虛假）包裝，但包裝是必要的）。沒人喜歡一個整天穿著不整的人。

原型：為你的idea搞個原型。這樣讓別人一眼就知道你的產(chǎn)品最終的形態(tài)。這里說的產(chǎn)品指的是你的架構(gòu)。
小短片：PPT有時候會讓人煩躁，有時候你可以祭出一些小短片來表達(dá)你的觀點和方向。但是還是請不要過度營銷，否則未來沒人會理你的。

2）為你的idea堅持到底：人們有時候不喜歡你的觀點或他們沒時間follow你。如果你真的對你自己的idea有信心，那么你需要有屢戰(zhàn)屢敗，屢敗屢戰(zhàn)的心態(tài)。這個有時候很有用。架構(gòu)決策有時候涉及到長期目標(biāo)，往往沒那么容易：開發(fā)人員不愿意改，因為他們覺得開發(fā)起來復(fù)雜。管理者也不喜歡，在他們看來，對短期效益來說成本很高。這時候你要愈挫愈勇。

3）找到同盟：有時候你需要尋找盟友，使用你的網(wǎng)絡(luò)。如果你沒有網(wǎng)絡(luò)，那么現(xiàn)在就開始構(gòu)建你的網(wǎng)絡(luò)。一開始你可以和你的同伴分享你的idea，如果他們喜歡，那么你可以在向其他人推銷的時候，你至少可以說你的觀點目前被哪幾個人支持。如果他們不喜歡，你可以問問原因，你可以獲得更多然后改進(jìn)idea，或者你的故事沒有足夠的說服力。下一步你可以找一些具有決定權(quán)的盟友，進(jìn)行公開的討論。如果你害怕討論，請盡量克服它，有時候你需要離開你的舒適區(qū)。

4）重復(fù)它，相信它：有一項研究表明重復(fù)不斷的廣播一個觀點，可以讓人們相信這個觀點，即使是只有一個人給你廣播這個觀點 (來源: The Financial Brand)。這也是很多那些西方的新聞報紙重復(fù)的發(fā)布有關(guān)川普的丑聞的奧秘所在，時間久了，人們就會相信川普是個大壞蛋。但這個策略要謹(jǐn)慎使用，畢竟你不是在搞政治，你需要道德。

相信本文會成為你在架構(gòu)師道路上的一篇工具文，本文從作者的親身經(jīng)歷以及綜合業(yè)界大佬們的見解，最終梳理出了成為架構(gòu)師所必備的技能清單并給出建議，希望此文可以改善你的工作！

ps：文中部分場景結(jié)合了一些譯者本人的經(jīng)歷。

>>>>參考資料