今天給大家?guī)?lái)一篇自己翻譯的干貨《軟件架構(gòu)師之路》介陶。本周Github上升很快的項(xiàng)目宣旱。其內(nèi)容對(duì)致力于成為軟件架構(gòu)師（不論前后端）的同學(xué)應(yīng)該都會(huì)有極大的幫助怔接。

項(xiàng)目地址

中文地址 https://github.com/gamedilong/SoftwareArchitect-CN

原文地址 https://github.com/justinamiller/SoftwareArchitect

如果有看完英文原文盘寡，發(fā)現(xiàn)本文翻譯內(nèi)容中存在問(wèn)題或者錯(cuò)誤的歡迎到中文Git地址PR蚌父，如能夠?qū)Υ蠹移鸬揭欢ǖ膸椭矚g迎star

內(nèi)容

• 什么是軟件架構(gòu)
• 軟件架構(gòu)的層次
• 軟件架構(gòu)師的典型工作內(nèi)容
• 軟件架構(gòu)師的重要技能
• 架構(gòu)師的技術(shù)路線圖
• 相關(guān)書(shū)籍

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

• 軟件架構(gòu)師是一名軟件開(kāi)發(fā)專家惹资，他可以進(jìn)行高層設(shè)計(jì)選擇并決定技術(shù)標(biāo)準(zhǔn)贺纲，包括軟件編碼標(biāo)準(zhǔn)，工具和平臺(tái)褪测。
  (出處: 維基百科:軟件架構(gòu)師)
• 軟件架構(gòu)（architecture）是一個(gè)系統(tǒng)的基本組織猴誊，由其組件、它們之間的相互關(guān)系和環(huán)境以及決定系統(tǒng)設(shè)計(jì)和演化的原則來(lái)表示侮措。
  (出處: 軟件架構(gòu)手冊(cè))

軟件架構(gòu)的層次

軟件架構(gòu)可以被抽象的分為幾個(gè)層次懈叹，不同的層次對(duì)技能的要求不同。對(duì)層次有很多不同的劃分分扎，我最喜歡如下這三種劃分:

• 應(yīng)用級(jí): 最低層次的架構(gòu)澄成。聚焦單個(gè)具體的應(yīng)用。 非常注重細(xì)節(jié), 底層設(shè)計(jì)畏吓。 溝通僅限入單個(gè)開(kāi)發(fā)團(tuán)隊(duì)墨状。
• 解決方案級(jí): 中級(jí)別的架構(gòu). 聚焦解決業(yè)務(wù)需求（業(yè)務(wù)解決方案）的一個(gè)或多個(gè)應(yīng)用。進(jìn)行一些高層次但是主要以低層次的設(shè)計(jì)為主菲饼，需要在多個(gè)開(kāi)發(fā)團(tuán)隊(duì)之間的溝通肾砂。
• 企業(yè)層級(jí): 最高級(jí)別的架構(gòu)。專注于多種解決方案宏悦。高層次的抽象設(shè)計(jì)镐确，需要將解決方案對(duì)應(yīng)用架構(gòu)師進(jìn)行詳細(xì)說(shuō)明包吝。 需要在整個(gè)組織溝通。查看 鏈接 獲得更多相關(guān)信息源葫。

有時(shí)架構(gòu)師也被看作是不同利益相關(guān)者之間的“粘合劑”诗越。 三個(gè)例子:

• 水平方向: 架起業(yè)務(wù)與開(kāi)發(fā)人員或不同開(kāi)發(fā)團(tuán)隊(duì)之間的溝通橋梁。
• 垂直方向: 架起開(kāi)發(fā)人員和管理人員之間的溝通橋梁臼氨。
• 技術(shù)方向: 不同的技術(shù)棽粲鳎或應(yīng)用程序的集成和融合。

軟件架構(gòu)師的典型工作內(nèi)容

要了解架構(gòu)師所需的必要技能储矩，我們首先需要了解架構(gòu)師平時(shí)主要干什么感耙。以下是我認(rèn)為最重要的一些工作內(nèi)容:

• 定義和確定開(kāi)發(fā)技術(shù)和平臺(tái)。

• 定義開(kāi)發(fā)標(biāo)準(zhǔn)持隧，如編碼標(biāo)準(zhǔn)即硼、工具、評(píng)審過(guò)程屡拨、測(cè)試方法等只酥。

• 支持認(rèn)識(shí)和理解業(yè)務(wù)需求。

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

• 記錄并傳達(dá)架構(gòu)定義裂允、設(shè)計(jì)和決策。

• 檢查和評(píng)審架構(gòu)與代碼等哥艇，檢查是否符合約定的設(shè)計(jì)模式和編碼標(biāo)準(zhǔn)绝编。

• 與其他架構(gòu)師和相關(guān)方協(xié)作。

• 負(fù)責(zé)開(kāi)發(fā)的指導(dǎo)和咨詢貌踏。

• 細(xì)化十饥、細(xì)化上級(jí)設(shè)計(jì)為下級(jí)設(shè)計(jì)。

  注意: 架構(gòu)是一項(xiàng)持續(xù)的工作祖乳，尤其當(dāng)項(xiàng)目采取敏捷開(kāi)發(fā)的模式逗堵，上述工作應(yīng)該也是反復(fù)迭代進(jìn)行的。

軟件架構(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)銷能力

(1) 設(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撰寫的《設(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編寫的“企業(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í)踐同樣重要，甚至更重要坟比。

• 嘗試了解不同的技術(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

(2) 決策能力

架構(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):
  1. 概念完整性：即使您決定以一種方式做到這一點(diǎn)窑滞，堅(jiān)持下去，即使有時(shí)以其他方式更好地做到這一點(diǎn)也是如此恢筝。 通常哀卫，這會(huì)讓概念整體上更簡(jiǎn)單，簡(jiǎn)化可理解性并簡(jiǎn)化維護(hù)性撬槽。
  2. 一致性：例如此改，如果您定義并應(yīng)用命名約定共啃，它就無(wú)關(guān)于大小寫移剪，而是以相同的方式在任何地方應(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ì)遺漏一些因素。

(3) 化繁為簡(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)行以下工作：（1）進(jìn)行足夠的自動(dòng)化測(cè)試桃煎，以確保系統(tǒng)的正確功能；以及（2）從利益相關(guān)者的支持大刊。 要了解有關(guān)重構(gòu)的更多信息为迈，建議閱讀<<重構(gòu)。 改進(jìn)現(xiàn)有代碼的設(shè)計(jì)>>缺菌，作者是Martin Fowler葫辐。

(4) 編碼能力

即使作為一個(gè)企業(yè)級(jí)架構(gòu)師，最抽象的架構(gòu)層次伴郁，你仍然應(yīng)該知道開(kāi)發(fā)人員每天都在做什么耿战。如果你不明白這是怎么做到的，你可能會(huì)面臨兩大問(wèn)題:

1. 開(kāi)發(fā)者不會(huì)接受你的嘴炮焊傅。
2. 不了解開(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)慎處理“

(5) 文檔架構(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)門OGAF或Zachmann之類的框架正在提供“工具”，這些工具在文檔站點(diǎn)上感覺(jué)很沉重赠制，盡管它們的附加值并不限于文檔赂摆。 在這樣的框架中獲得認(rèn)證可以教會(huì)您更系統(tǒng)地解決體系結(jié)構(gòu)。

(6) 溝通能力

根據(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é)省最多的錢赴捞。

• 經(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)了安全感端辱。

(7) 評(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)題的一些想法:

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

(8) 平衡能力

• 質(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ò)誤，需要考慮兩件事:
  1. 開(kāi)發(fā)人員和業(yè)務(wù)部門需要了解長(zhǎng)期愿景及其好處哎垦，以便調(diào)整其解決方案囱嫩。
  2. 負(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)日裙。

(9) 指導(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分鐘蔗喂，與同事交流熱門話題。這次會(huì)議沒(méi)有議程高帖，一切都可以討論缰儿。盡量當(dāng)場(chǎng)解決小事。安排對(duì)更復(fù)雜主題的跟進(jìn)棋恼。

(10) 營(yíng)銷推廣

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

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

  1. 原型: 展示你想法的原型齐蔽。有很多創(chuàng)建原型的工具。在喜歡SAP的企業(yè)背景下床估，可以查看build.me含滴，在其中您可以快速輕松地創(chuàng)建漂亮且可點(diǎn)擊的UI5應(yīng)用程序。

  2. 視頻: 與“無(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ù)勀愕南敕āＨ绻麄兿矚g燕少，或者至少部分喜歡卡者，如果別人問(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)銷技巧谨究。

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

Architect roadmap

相關(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