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