開(kāi)發(fā)軟件系統(tǒng)的目標(biāo)往往是構(gòu)建符合質(zhì)量標(biāo)準(zhǔn)的系統(tǒng)，并在長(zhǎng)期或預(yù)定時(shí)間內(nèi)獲得最高的投資回報(bào)率（ROI）。同時(shí)，這也是軟件架構(gòu)的目標(biāo)。軟件架構(gòu)本質(zhì)上是在構(gòu)建軟件系統(tǒng)的設(shè)計(jì)藍(lán)圖。如果在產(chǎn)品上增加投入能夠帶來(lái)更多的收益，那么這將被視為具有良好的投資回報(bào)率。在這里，投資回報(bào)率不僅僅是指經(jīng)濟(jì)效益。相反，粗劣的軟件架構(gòu)設(shè)計(jì)則會(huì)導(dǎo)致后期頻繁的修改，最終耗費(fèi)更多的成本。優(yōu)秀的軟件架構(gòu)設(shè)計(jì)能夠平衡成本與收益，并最大化投資回報(bào)率。軟件架構(gòu)設(shè)計(jì)涉及諸多方面，比如找到恰當(dāng)?shù)某橄蟾拍睢�決定包含哪些功能、確定每項(xiàng)功能的深度、設(shè)定服務(wù)質(zhì)量（QOS）參數(shù)、確定靈活性程度，以及時(shí)間安排和用戶(hù)體驗(yàn)等。判斷力的作用軟件架構(gòu)師會(huì)學(xué)習(xí)抽象概念、架構(gòu)風(fēng)格和模式，并研究它們的優(yōu)缺點(diǎn)、在特定情況下的適用性，以及如何在了解潛在陷阱、失敗案例和用例的基礎(chǔ)上組合它們。然而，大多數(shù)的設(shè)計(jì)錯(cuò)誤都是由于缺乏判斷力而不是缺乏知識(shí)造成的。在這里，判斷力指的是經(jīng)過(guò)深思熟慮后做出決策或得出合理結(jié)論的能力，以?xún)?yōu)化最重要的結(jié)果。我在20多年的軟件架構(gòu)設(shè)計(jì)中，發(fā)現(xiàn)了以下常見(jiàn)錯(cuò)誤：過(guò)多納入用戶(hù)旅程所需的功能。設(shè)計(jì)過(guò)于靈活或過(guò)于一致，從而影響未來(lái)的變化。限制功能深度，從而嚴(yán)重影響用戶(hù)體驗(yàn)（UX）。為最終用戶(hù)解決無(wú)關(guān)緊要的問(wèn)題。對(duì)用戶(hù)旅程和體驗(yàn)關(guān)注不足。錯(cuò)過(guò)交付時(shí)間。之所以會(huì)犯下這些錯(cuò)誤，主要是因?yàn)槲覀儾涣私馕磥?lái)的趨勢(shì)，不了解使用系統(tǒng)的用戶(hù)，也不了解系統(tǒng)是如何運(yùn)作的。這說(shuō)明了判斷力的必要性，也使我們面臨的不僅僅是技術(shù)方面的挑戰(zhàn)，更是領(lǐng)導(dǎo)力方面的挑戰(zhàn)。這里是領(lǐng)導(dǎo)力是指管理不確定性、將混亂變?yōu)橛行�、為更美好的未�?lái)提供希望，并朝著這個(gè)未來(lái)前進(jìn)。拿破侖·波拿巴曾說(shuō)過(guò)，領(lǐng)導(dǎo)者是希望的傳遞者。也就是說(shuō)，領(lǐng)導(dǎo)者并不總是知道未來(lái)會(huì)發(fā)生什么，也并不是全知全能的。領(lǐng)導(dǎo)者應(yīng)該有一個(gè)關(guān)于未來(lái)的愿景；他們應(yīng)該以一種最小化風(fēng)險(xiǎn)的方式管理不確定性。領(lǐng)導(dǎo)者應(yīng)該將他們的愿景和實(shí)施方案?jìng)鬟_(dá)給他人，并帶領(lǐng)眾人實(shí)現(xiàn)愿景。讓我們從軟件架構(gòu)師的角度重申一下此觀點(diǎn)。也就是說(shuō)軟件架構(gòu)師并不是無(wú)所不知的，也不是總知道系統(tǒng)應(yīng)該具備哪些功能以及將被如何使用。他們應(yīng)該有一個(gè)愿景以及整體解決方案。領(lǐng)導(dǎo)者應(yīng)該將他們的愿景和實(shí)施方案?jìng)鬟_(dá)給團(tuán)隊(duì)，并指導(dǎo)團(tuán)隊(duì)構(gòu)建軟件系統(tǒng)，然后運(yùn)行這個(gè)系統(tǒng)。我并不認(rèn)為知識(shí)對(duì)于架構(gòu)師來(lái)說(shuō)不重要。知識(shí)的確重要，但是判斷力起著關(guān)鍵性的作用。但遺憾的是，知識(shí)是普遍的，判斷力卻很稀缺。我讀過(guò)很多軟件架構(gòu)方面的好書(shū)和文章，僅舉幾例：鮑勃·馬�。˙ob Martin）的著作、格雷戈·霍普（Gregor Hohpe）的著作以及馬丁·福勒（Martin Fowler）的博客。然而，他們的作品主要關(guān)注的是知識(shí)，較少涉及判斷力方面的話題。我還讀過(guò)很多關(guān)于領(lǐng)導(dǎo)力的好書(shū)：本·霍洛維茨（Ben Horowitz）的The Hard Things About Hard Things、埃里克·施密特（Eric Schmidt）等人的Trillion Dollar Coach、斯坦利·麥克里斯特爾（Stanley McChrystal）的Team of Teams: New Rules of Engagement for a Complex World、理查德·魯梅爾特（Richard Rumelt）的Good Strategy, Bad Strategy，以及喬科·威林克（Jocko Willink）等人的其他著作。這些作品討論了判斷力，但只是停留在一般層面上，而不涉及技術(shù)層面。顯然，在優(yōu)秀的領(lǐng)導(dǎo)力和優(yōu)秀的軟件架構(gòu)判斷力之間存在著不小的認(rèn)知鴻溝。內(nèi)容導(dǎo)讀本書(shū)討論了領(lǐng)導(dǎo)力和軟件架構(gòu)判斷力之間的差距，重點(diǎn)闡述了何為軟件領(lǐng)導(dǎo)力，以及我們?cè)跇?gòu)建軟件系統(tǒng)時(shí)如何將其發(fā)揮至極致。如前所述，許多在軟件架構(gòu)上犯的錯(cuò)誤都源于知識(shí)與判斷力之間的差距。本書(shū)不是關(guān)于如何管理團(tuán)隊(duì)的書(shū)，也不是關(guān)于工程管理或人力資源管理（HR）以及如何組建團(tuán)隊(duì)的書(shū)，更不是關(guān)于企業(yè)戰(zhàn)略的書(shū)。此外，本書(shū)也不涉及如何創(chuàng)造愿景�？梢哉f(shuō)，本書(shū)是一本關(guān)于技術(shù)領(lǐng)導(dǎo)力的書(shū)，也可以說(shuō)本書(shū)是一本關(guān)于技術(shù)判斷力的書(shū)。本書(shū)解釋了高級(jí)架構(gòu)師必須深入理解的原則和概念，并討論了技術(shù)領(lǐng)導(dǎo)者或架構(gòu)師如何利用這些原則來(lái)管理不確定性。例如，本書(shū)的一個(gè)論點(diǎn)是：深思熟慮，慢慢實(shí)施。另一個(gè)論點(diǎn)是，領(lǐng)導(dǎo)者必須確定事務(wù)的界限，承擔(dān)起不確定性的責(zé)任，而不是將責(zé)任轉(zhuǎn)嫁給同事。本書(shū)討論的問(wèn)題和原則可以幫助我們管理不確定性，并提供了一種有效的決策框架。如果你不是負(fù)責(zé)人，那還需要讀本書(shū)嗎？我認(rèn)為是需要的。人們總是會(huì)跟隨那些提出并處理不確定性問(wèn)題并取得進(jìn)展的人。優(yōu)秀的架構(gòu)師在被授予“負(fù)責(zé)人”的頭銜之前的許多年就已經(jīng)開(kāi)始扮演這個(gè)角色了。知識(shí)越淵博，成為領(lǐng)導(dǎo)者的機(jī)會(huì)就越大。主動(dòng)出擊，幫助你的領(lǐng)導(dǎo)一起完成任務(wù)，你就會(huì)發(fā)現(xiàn)你得到的機(jī)會(huì)越來(lái)越多，聲譽(yù)和頭銜也將隨之而來(lái)。如果你認(rèn)為有人比你更適合扮演這個(gè)角色，那就要向他學(xué)習(xí)、提出問(wèn)題，并向他請(qǐng)教！在這種情況下，你可以使用我們?cè)跁?shū)中討論的內(nèi)容協(xié)助領(lǐng)導(dǎo)者。你成長(zhǎng)的機(jī)會(huì)也將隨之而來(lái)。本書(shū)引用了許多技術(shù)領(lǐng)導(dǎo)力方面的范例，并特別提到了兩個(gè)故事：眾所周知的萊特兄弟——奧維爾和威爾伯，以及設(shè)計(jì)了U-2和黑鳥(niǎo)SR-71等飛機(jī)的凱利·約翰遜的故事。這些領(lǐng)導(dǎo)者具備一種強(qiáng)大的技術(shù)控制力，他們利用有限的資源，使看似不可能實(shí)現(xiàn)的系統(tǒng)成為現(xiàn)實(shí)。當(dāng)然，還有許多像Google的杰夫·迪恩這樣的軟件領(lǐng)導(dǎo)者，我對(duì)他們同樣推崇備至。眾所周知，萊特兄弟制造了第一架可持續(xù)和控制飛行的具有動(dòng)力的飛行器。但事實(shí)上，他們并沒(méi)有受過(guò)大學(xué)教育，他們只不過(guò)經(jīng)營(yíng)著一家自行車(chē)店而已。他們與資金充足的專(zhuān)業(yè)人士競(jìng)爭(zhēng)，并最終獲得了成功。的確，在萊特兄弟之前有許多飛行器的設(shè)計(jì)，但他們是第一個(gè)正確設(shè)計(jì)所有參數(shù)的團(tuán)隊(duì)。萊特兄弟先是制造了滑翔機(jī)并學(xué)習(xí)如何控制和調(diào)整它，然后增加了螺旋槳和發(fā)動(dòng)機(jī)，逐漸將滑翔機(jī)改造為一架飛機(jī)，展示了極佳的判斷力。凱利·約翰遜是洛克希德U-2、SR-71黑鳥(niǎo)和其他40多種飛機(jī)的設(shè)計(jì)師�！昂邙B(niǎo)”飛機(jī)對(duì)雷達(dá)隱身，飛行速度能夠超過(guò)導(dǎo)彈，并且在20多年的服役期間從未被擊落過(guò)。它是第一架飛行速度超過(guò)3倍音速的量產(chǎn)飛機(jī)。凱利還制造了第一架速度達(dá)到2倍音速的戰(zhàn)斗機(jī)和第一架速度超過(guò)400mile/h的戰(zhàn)斗機(jī)（1mile=1609.344m）。洛克希德U-2飛機(jī)達(dá)到并保持了70000ft（1ft=0.3048m）的飛行高度。他能夠?qū)⒁粋�(gè)不可實(shí)現(xiàn)的目標(biāo)分解為若干可執(zhí)行的任務(wù)，精益求精地要求自己，然后讓系統(tǒng)運(yùn)轉(zhuǎn)起來(lái)。凱利以在預(yù)算范圍內(nèi)提前完成項(xiàng)目而聞名，而且還將節(jié)省的資金返還給了政府。據(jù)說(shuō)他的上司曾經(jīng)感慨：“那個(gè)瑞典人真的能看到空氣”。這指的就是凱利對(duì)設(shè)計(jì)的強(qiáng)大直覺(jué)�！凹軜�(gòu)”和“設(shè)計(jì)”這兩個(gè)術(shù)語(yǔ)通常可互換使用。“設(shè)計(jì)”是指完整詳細(xì)的藍(lán)圖（例如，軟件架構(gòu)中的類(lèi)圖和序列圖）；而“架構(gòu)”則是高層次的概念視圖（例如，組件視圖和組件級(jí)的序列圖）。在本書(shū)中，我們將重點(diǎn)落在高層次視圖上，因此全書(shū)都將使用“架構(gòu)”這個(gè)術(shù)語(yǔ)。本書(shū)使用TOGAF的三層架構(gòu)來(lái)確定以下重點(diǎn)關(guān)注的主題：在業(yè)務(wù)架構(gòu)層勾勒出業(yè)務(wù)運(yùn)營(yíng)的概貌，并展示各種組件如何協(xié)同工作以推動(dòng)業(yè)務(wù)運(yùn)營(yíng)。信息系統(tǒng)架構(gòu)層分為數(shù)據(jù)架構(gòu)和應(yīng)用架構(gòu)。數(shù)據(jù)架構(gòu)的核心是對(duì)不同的數(shù)據(jù)類(lèi)型進(jìn)行分類(lèi)，并突出它們之間的連接。應(yīng)用架構(gòu)識(shí)別系統(tǒng)中的獨(dú)特組件（如服務(wù)），并闡明它們?cè)谙到y(tǒng)中的交互作用。技術(shù)架構(gòu)層描述了具體的特定技術(shù)。包括軟件標(biāo)準(zhǔn)、使用的軟件包、硬件、網(wǎng)絡(luò)以及安全細(xì)節(jié)等要素。本書(shū)側(cè)重于信息系統(tǒng)架構(gòu)。業(yè)務(wù)架構(gòu)與信息系統(tǒng)架構(gòu)之間的聯(lián)系較為錯(cuò)綜復(fù)雜。信息系統(tǒng)架構(gòu)的設(shè)計(jì)在很大程度上取決于各種業(yè)務(wù)要素。這些要素不僅包括業(yè)務(wù)架構(gòu)，還包括諸如項(xiàng)目進(jìn)度、團(tuán)隊(duì)技能和競(jìng)爭(zhēng)對(duì)手的挑戰(zhàn)等業(yè)務(wù)環(huán)境要素。盡管這些業(yè)務(wù)環(huán)境要素通常不包括在TOGAF等業(yè)務(wù)架構(gòu)中，但它們確實(shí)影響了業(yè)務(wù)架構(gòu)的實(shí)施和組織的戰(zhàn)略方向。系統(tǒng)架構(gòu)面臨的一個(gè)主要挑戰(zhàn)是：領(lǐng)導(dǎo)層要基于業(yè)務(wù)環(huán)境做出技術(shù)決策。本書(shū)第1章討論的五個(gè)問(wèn)題的一個(gè)關(guān)鍵目標(biāo)就是確保我們的架構(gòu)始終符合業(yè)務(wù)環(huán)境。系統(tǒng)架構(gòu)有兩種主要的方法：瀑布式（Waterfall）方法。敏捷（Agile）方法。瀑布式方法基于這樣的前提：事先確定系統(tǒng)需求的全部細(xì)節(jié)是可行的。因此，這種方法需要進(jìn)行全面的規(guī)劃，然后再執(zhí)行。TOGAF的架構(gòu)設(shè)計(jì)模型（ADM）就是這種方法的一個(gè)例子。它演示了如何準(zhǔn)確捕捉需求并基于需求進(jìn)行開(kāi)發(fā)。此外，像對(duì)象管理組織（OMG）和國(guó)際標(biāo)準(zhǔn)化組織（ISO）這樣的機(jī)構(gòu)也提供了支持類(lèi)似概念模型的標(biāo)準(zhǔn)。敏捷方法（也是一種迭代方法）則專(zhuān)注于快速推出一個(gè)版本，并與用戶(hù)合作完善需求，構(gòu)建一個(gè)能讓用戶(hù)真正受益的系統(tǒng)。比較這兩種方法，我更傾向于敏捷方法。雖然人們一直努力將迭代特性與ADM等模型結(jié)合起來(lái)，但在實(shí)踐中，這往往過(guò)于復(fù)雜，且無(wú)法保持迭代模型所需的快速節(jié)奏（通常是1～2周進(jìn)行一次迭代）。對(duì)于大型組織和復(fù)雜項(xiàng)目來(lái)說(shuō)，更加集中的規(guī)劃或許是合理的。許多軟件流程（如TOGAF ADM等標(biāo)準(zhǔn)和參考架構(gòu)）都以瀑布模型為基礎(chǔ)，旨在精確捕捉需求。雖然我們可以從TOGAF、OMG和ISO中汲取寶貴的經(jīng)驗(yàn)，但前提是可以在事先確定需求，并且只會(huì)進(jìn)行漸進(jìn)式的改變。因此，本書(shū)重點(diǎn)介紹一種敏捷方法，使得需求更加簡(jiǎn)單和易操作，并通過(guò)短期迭代不斷改進(jìn)，同時(shí)向用戶(hù)學(xué)習(xí)。在更廣泛的設(shè)計(jì)層面上，運(yùn)用敏捷方法可將整個(gè)系統(tǒng)分解為松散連接的子系統(tǒng)（每個(gè)子系統(tǒng)都可能與用戶(hù)互動(dòng)并提供價(jià)值），定義它們之間的應(yīng)用程序接口（API），然后將各個(gè)子系統(tǒng)連接起來(lái)，在高層監(jiān)督下獨(dú)立運(yùn)作。在我們深入探討敏捷方法之前，有必要了解一下軟件項(xiàng)目中的各個(gè)典型角色。產(chǎn)品經(jīng)理在業(yè)務(wù)利益相關(guān)者、用戶(hù)體驗(yàn)（UX）設(shè)計(jì)師和架構(gòu)師的幫助下決定要構(gòu)建什么產(chǎn)品。架構(gòu)師與工程經(jīng)理和團(tuán)隊(duì)合作構(gòu)建產(chǎn)品。然后，產(chǎn)品經(jīng)理與所有人合作以確保達(dá)到產(chǎn)品的質(zhì)量要求（精益求精）。根據(jù)工作地點(diǎn)的不同，架構(gòu)師的職責(zé)也會(huì)發(fā)生變化。例如，在初創(chuàng)公司，架構(gòu)師負(fù)責(zé)產(chǎn)品管理，決定要構(gòu)建的產(chǎn)品功能；而在大型公司，架構(gòu)師可能與需求規(guī)范無(wú)關(guān)。當(dāng)今時(shí)代，業(yè)界正從瀑布式方法轉(zhuǎn)向迭代的、敏捷的軟件開(kāi)發(fā)方法，責(zé)任正在共擔(dān)，職業(yè)角色也在融合。例如，在決定包含哪些功能、何時(shí)包含這些功能以及如何定義用戶(hù)體驗(yàn)時(shí)，架構(gòu)師應(yīng)該與產(chǎn)品經(jīng)理密切合作，并要求團(tuán)隊(duì)精益求精。本書(shū)共12章。第1章討論了軟件架構(gòu)、不確定性和判斷力，提出了處理不確定性的五個(gè)問(wèn)題和七項(xiàng)原則。第2～3章深入探討了系統(tǒng)性能和用戶(hù)體驗(yàn)（UX）。系統(tǒng)性能決定了架構(gòu)中什么是可行的，什么是不可行的。用戶(hù)體驗(yàn)（UX）決定了用戶(hù)對(duì)系統(tǒng)的采用與否。與其他章節(jié)相比，第2章講述的內(nèi)容更為詳細(xì)、技術(shù)性也更強(qiáng)。這些細(xì)節(jié)至關(guān)重要，然而在其他書(shū)籍中并未被廣泛提及。如果你最初是為了尋求更寬泛的理解，可以簡(jiǎn)要瀏覽第2章，但我建議最終回過(guò)頭重讀第2章，以便掌握更細(xì)微的要點(diǎn)。第3章強(qiáng)調(diào)了用戶(hù)體驗(yàn)（UX）原則的重要性，并建議你盡早將用戶(hù)體驗(yàn)專(zhuān)家納入團(tuán)隊(duì)中，并聽(tīng)取這些專(zhuān)家的建議。此外，我還想強(qiáng)調(diào)用戶(hù)體驗(yàn)對(duì)于應(yīng)用程序接口（API）、配置和擴(kuò)展的重要性。第4～11章從宏觀和微觀層面討論了如何構(gòu)建系統(tǒng)或應(yīng)用程序。在宏觀層面將服務(wù)組合成一個(gè)連貫的架構(gòu)；在微觀層面學(xué)習(xí)如何構(gòu)建良好的服務(wù)。在這部分中，我們會(huì)盡可能解釋一種默認(rèn)的架構(gòu)選擇，這種選擇大多數(shù)時(shí)間都是行之有效的，我們還會(huì)討論如何選擇更復(fù)雜的架構(gòu)，并討論如何為你的公司選擇合適的架構(gòu)方案。這些討論包括了反模式和一些常見(jiàn)錯(cuò)誤。此外，還將討論一些至關(guān)重要的技術(shù)思想。第10章闡述了微服務(wù)的注意事項(xiàng)，并沒(méi)有將它們分散在第5～7章中。這種闡述方式更容易將相關(guān)概念作為一個(gè)整體來(lái)掌握，而不是將各個(gè)部分分開(kāi)來(lái)理解。隨后，本書(shū)將根據(jù)適用的五個(gè)問(wèn)題和七項(xiàng)原則來(lái)解釋每一個(gè)技術(shù)決策。第12章將討論如何將全書(shū)內(nèi)容整合在一起。這一章的重點(diǎn)是建立一個(gè)快速反饋循環(huán)，以消除任何阻礙開(kāi)發(fā)人員完成迭代、接收反饋和學(xué)習(xí)的因素。本章敦促領(lǐng)導(dǎo)者確保開(kāi)發(fā)人員能夠高效地完成工作，同時(shí)也要親自參與解決阻礙開(kāi)發(fā)人員工作進(jìn)程的問(wèn)題。