 |
-- 會員 / 註冊 --
|
 |
|
|
|
架構整潔之道 ( 簡體 字) |
| 作者：孫宇聰 | 類別：1. -> 程式設計 -> 綜合 |
| 譯者： |
| 出版社：電子工業出版社 |  3dWoo書號： 49956
詢問書籍請說出此書號！【缺書】
NT售價： 495 元 |
| 出版日：9/1/2018 |
| 頁數：348 |
| 光碟數：0 |
|
站長推薦：   |
| 印刷：黑白印刷 | 語系： ( 簡體 版 ) |
| |
加入購物車  │加到我的最愛
(請先登入會員) |
| ISBN：9787121347962 |
| 作者序 | 譯者序 | 前言 | 內容簡介 | 目錄 | 序 |
| (簡體書上所述之下載連結耗時費功, 恕不適用在台灣, 若讀者需要請自行嘗試, 恕不保證) |
| 作者序： |
| 譯者序： |
前言：推薦序一
在我心里，程序員可以分為三個層次：普通程序員、工程師和架構師。
普通程序員是編寫代碼的人。編寫代碼的方式有很多，只要能讓程序跑起來，能正確地處理業務流程和對數據進行計算，就可以說“會編寫代碼”。程序員需要熟悉整個程序的邏輯及處理過程，需要熟悉程序語言的特性，還需要熟悉一些計算機操作系統的交互調用方式，才能寫出從用戶側交互，到數據和業務邏輯處理，再到與計算機系統交互的代碼，有效地把用戶信息、數據、業務和計算機串聯和拼裝出來。
然而，其中一些程序員發現，只讓代碼跑起來是不夠的，因為這個世界是不斷變化的，他們發現自己需要花更多的時間來維護代碼：增加新的需求，擴展原有的流程，修改已有的功能，優化性能……一個人完全維護不過來，還需要更多的人，于是代碼還需要在不同人之間輪轉；他們發現代碼除了需要跑起來，還需要易讀、易擴展、易維護，甚至可以直接重用。于是，這些人使用各種各樣的手段和技術不斷提高代碼的易讀性、可擴展性、可維護性和重用性。我們把這些有“潔癖”、有工匠精精、有修養的程序員叫作工程師，工程師不僅僅是在編寫代碼，他們會用工程的方法來編寫代碼，以便讓編程開發更為高效和快速。他們把編程當成一種設計，一種工業設計，把代碼模塊化，讓這些模塊可以更容易地交互拼裝和組織，讓代碼排列整齊——閱讀和維護這些代碼就像看閱兵式一樣舒心暢快。
但是故事還沒完，這些擁有工匠精神的工程師們還是難以解決某些問題，這些人漸漸地發現，這個世界上有很多問題就像翹翹板一樣，只能要一邊，這一邊上去了，另一邊就下來了。就像要么用空間換時間，要么用時間換空間一樣，你很難找到同時滿足空間和時間要求的“雙利解”；就像CAP的三選二的理論一樣，這個世界不存在完美的解決方案，無論什么方案都有好的一面和不好的一面。而且，這些工程師還漸漸發現，每當引入一個新的技術來解決一個已有的問題時，這個新的技術就會帶來更多的問題，問題就像有一個生命體一樣，它們會不斷地繁殖和進化。漸漸地，他們發現，問題的多少和系統的復雜度呈正比，而且不僅是線性正比，還可能呈級數正比，此時就越來越難做技術決定。但是有一些資深的工程師開始站出來挑戰這些問題，有的基于業務分析給出平衡的方案，有的開始嘗試設計更高級的技術，有的開始設計更靈活的系統，有的則開始簡化和輕量化整個系統……這些高智商、經驗足、不怕難的工程師們引領著整個行業前行。他們就是架構師！
感覺Bob大叔的系列著作好像也在走這個過程，《代碼整潔之道》教你寫出易讀、可擴展、可維護、可重用的代碼，《代碼整潔之道：程序員的職業素養》教你怎樣變成一個有修養的程序員，而《架構整潔之道》基本上是在描述軟件設計的一些理論知識。《架構整潔之道》大體分成三個部分：編程范式（結構化編程、面向對象編程和函數式編程），設計原則（主要是SOLID），以及軟件架構（其中講了很多高屋建翎的內容）。總體來說，這本書中的內容可以讓你從微觀（代碼層面）和宏觀（架構層面）兩個層面對整個軟件設計有一個全面的了解。
但是，如果你想從這本書里找到一些可以立馬解決具體問題的工程架構和技術，恐怕你會感到失望。這本書中更多的是一些基礎的理論知識，看完后你可能會比較“無感”，因為這些基礎知識對于生活在這個高速發展的喜歡快餐文化的社會中的人來說，可能很難理解其中的價值——大多數人的目標不是設計出一個優質的軟件或架構，而是快速地解決一個具體的問題，完成自己的工作。然而，可能只有你碰過足夠多的壁，掉過足夠多的坑，經歷過足夠多的痛苦后，再來讀這本書時，你才會發現本書中的這些“陳舊的知識”是多么充滿智慧。而且，如果有一天，你像我這個老家伙一樣，看到今天很多很多公司和年輕的程序員還在不斷地掉坑和掙扎，你就會明白這些知識的重要性了。
我個人覺得，這本書是架構方面的入門級讀物，但也并不適合經驗不足的人員學習，這本書更適合的讀者群是，有3~5年編程經驗、需要入門軟件設計和架構的工程師或程序員。
最后，我想留下一個觀點和一組問題。
觀點：無論是微觀世界的代碼，還是宏觀層面的架構，無論是三種編程范式還是微服務架構，它們都在解決一個問題——分離控制和邏輯。所謂控制就是對程序流轉的與業務邏輯無關的代碼或系統的控制（如多線程、異步、服務發現、部署、彈性伸縮等），所謂邏輯則是實實在在的業務邏輯，是解決用戶問題的邏輯。控制和邏輯構成了整體的軟件復雜度，有效地分離控制和邏輯會讓你的系統得到最大的簡化。
問題：如果你要成為一名架構師，你需要明確地區分幾組詞語（如何區分它們正是留給你的問題），否則你不可能成為一名合格的工程師或架構師。這幾組詞語是簡單vs.簡陋、平衡vs.妥協、迭代vs.半成品。如果你不能很清楚地定義出其中的區別，那么你將很難做出正確的決定，也就不可有成為一名優秀的工程師或架構師。
我相信這個觀點和這組問題將有助于你更好地閱讀并理解這本書，也會讓你進行更多的思考，帶著思考讀這本書，會讓你學到更多！
陳皓
（@左耳朵耗子）
推薦序二
久遠的教誨，古老的智慧
如果讓你接手一套不穩定但要緊的在線系統，這套系統還有各種問題：變量命名非常隨意，依賴邏輯錯綜復雜，層次結構亂七八糟，部署流程一塌糊涂，監控系統一片空白……你該怎么辦？
前幾年我就遇到了這種問題，我對著頻發的故障仔細觀察，發現了最關鍵的問題：如果放著不動，這套系統的核心功能還是相對穩定的，但經常會有一些外圍需求要開發，這時由于原有的依賴邏輯和層次結構不夠清楚，就會導致“牽一發而動全身”的情況，加上測試不完善，所以幾乎每次外圍功能上線更新，核心功能都會受影響，然后又要重復好幾次“調試→改正→上線”的流程。
怎么辦？大家說了很多辦法：把單元測試都補全，重構代碼拆分核心功能和非核心功能，跟業務方談暫停需求……這些辦法都很對，但是，都需要時間才能見效，而我們最缺的就是時間。
我提了一個很“笨”的辦法：把所有“共享變量”都抽到Redis中進行讀寫，消滅本地副本，然后把穩定版本程序多部署幾份，這樣就可以多啟動幾個實例，將這些實例標記為AB兩組。同時，在前面搭建代理服務，用于分流請求——核心功能請求分配到A組（程序基本不更新），外圍功能請求分配到B組（程序按業務需求更新）。這樣做看起來有點多此一舉——AB兩組都只有部分代碼提供服務，而且要通過Redis共享狀態，但是卻實現了無論B組的程序如何更新，都不會影響A組所承載的核心服務的目的。
雖然當時不少人說“怎么能這樣玩呢”，但它確實有效。當天部署，當天生效，在線服務迅速穩定下來，即便新開發的外圍功能有問題，核心服務也不受任何影響。這樣業務人員滿意了，開發人員也可以安心對系統做改造了。
后來有不少人問我是怎么想到這個辦法的，答案是：因為我是個老程序員，成長在面向對象的年代，運用SOC（關注點分離）、SRP（單一職責原則）、OCP（開閉原則）這些東西對我來說就如同本能。具體到這個例子，無非就是識別關注點、隔離責任、保持核心關注點的封閉而已。
后來我才知道，我提出的這個方法有個專門的名字叫“藍綠部署”。當然我自認是個老程序員，不懂這些新鮮概念也不太要緊。確實，如今不少程序員已經不認識SOC、SRP、OCP、LSP等“古老”的玩意了，大家熟悉的是各種語言、類庫、框架、代碼托管網站。互聯網開發場景千變萬化，技術一日千里，而面向對象在不少人的腦海里早就是棄之不用的老古董了。只有“老一輩”的程序員還記得那些古老的教誨，守著那些古拙的技巧。但是這些東西，總有一天會被時代淘汰嗎？
實際上，這也是我初讀《架構整潔之道》的疑惑。雖然Bob大叔這個名字對我們這些“老程序員”來說可謂如雷貫耳，之前針對一般性軟件開發所著的《代碼整潔之道》和《代碼整潔之道：程序員的職業素養》也確實很受歡迎，但如今寫架構，還從結構化編程、面向對象編程、函數式編程寫起，還花時間解釋SRP、OCP、LSP等原則，實在難掩“古老”的感覺。請問，它們和如今的“架構”有什么關系嗎？
不過，如果你耐心讀下去就會發現，還真有關系。按照Bob大叔的說法，所謂架構就是“用最小的人力成本來滿足構建和維護系統需求”的設計行為。以前的面向對象系統和如今的分布式系統，在這一點上是完全一致的。聽取久遠的教誨，尊重古老的智慧，如今的架構師也會從中受益。不信？我們就拿經典的三個編程范式來舉例，看看這些“老掉牙”的玩意兒和如今的架構設計有什么關聯。
大家對結構化編程的一般理解是，由if-else、switch-case之類的語句組織程序代碼的編程方式，它杜絕了goto導致的混亂。但是從更深的層次上看，它也是一種設計范式，避免隨意使用goto，使用if-else、switch-case之類控制語句和函數、子函數組織起來的程序代碼，可以保證程序的結構是清楚的，自頂向下層層細化，消滅了雜錯，杜絕了混淆。
聯系如今的分布式系統，我們在設計的時候，真的能夠做到自頂向下層層細化嗎？有多少次，我看到的系統設計圖里，根本沒有“層次”的概念，各個模塊沒有一致的層次劃分，與子系統交互的不是子系統，而是一盤散沙式的接口，甚至接口之間隨意互調、關系亂成一團麻的情況也時常出現，帶來的就是維護和調試的噩夢。吹散歷史的迷霧，不正是古老的goto陷阱的再現嗎？
大家對面向對象編程的一般理解是，由封裝、繼承、多態三種特性支持的，包含類、接口等若干概念的編程方式。但是從更深的層次上看，它也是一種設計范式。多態大概算其中最神奇的特性了，程序員在確定接口時做好抽象，代碼就可以很靈活，遇到新情況時，新寫一個實現就可以無縫對接。
聯系如今的分布式系統，我們在設計的時候，真的能夠做到接口足夠抽象、新模塊能無縫對接嗎？有多少次，我看到接口的設計非常隨意，接口不是基于行為而是基于特定場景的實現，沒有做適當的抽象，也沒有為未來預留空間，直接導致契約僵硬死板。每新增一種終端呈現形式，整個內容生產流程就要大動干戈，這樣的例子并不罕見。抹去歷史的塵埃，這不正是“多態”出現之前的困境嗎？
大家對函數式編程的一般理解是，以函數為基本單元，沒有變量（更準確地說是不能重復賦值）也沒有副作用的編程方式。但是從更深的層次上看，它徹底隔離了可變性，變量或者狀態默認就是不可變的，如果要變化，則必須經過合理設計的專門機制來實現。所以，它也避免了死鎖、狀態沖突等眾多麻煩。
聯系如今的分布式系統，我們在設計的時候，真的能夠徹底隔離可變性、避免狀態沖突嗎？有多少次，我看到狀態或變量的修改接口大方暴露，被不經意（或者惡意）修改，導致奇怪的故障。Bob大叔舉了一個相當有趣的例子，如果又要保證操作原子性又要能精確還原各時刻的狀態，有個辦法是這樣的：只提供CR操作，而不提供完整的CRUD操作（就像MySQL的binlog那樣）。平時只要追加操作記錄即可，各時刻的狀態永遠通過重放之前的操作記錄得出，這樣就徹底避免了狀態的錯亂。這個辦法看起來古怪，但我真的在之前的開發中用過（當然是在程序生命周期有限的場景下），而且真的從沒出過錯。
坦白說，看完《架構整潔之道》這本書，我心里好受點了。因為我發現，我們這些老程序員的知識其實沒有過時，如今不少光鮮的架構其實要解決的還是那些古老的問題。多虧了Bob大叔的妙手點撥，我才能穿越時空，享受到“重新發現智慧”的愉悅。
當然，架構設計是一門復雜的學問，要綜合考慮編碼、質量、部署、發布、運維、排障、升級等等各種因素，做出權衡。好消息是，Bob大叔的這本書覆蓋面廣，涉及各個方面，相信你認真讀完全書一定會和我一樣有不小的收獲。唯一的問題是，你要適應這個老程序員的口吻和節奏：他當然也會拿如今流行的打車系統做例子，但他更熟悉的還是鏈接器、C語言、UML圖等玩意。
不過我覺得，這都不是大問題。看得出類之間的依賴關系不合理，自然容易發現子系統之間的依賴關系不合理；搞得懂UNIX如何巧妙定義通用的IO設備，自然容易想到對PC Web、Mobile Web、App內的頁面做適當抽象；認得清各線程、進程、鏈接庫的職責，自然容易明白微服務也需要避免跨邊界調用。更妙的是，從這種古老的視角看問題，往往更能擺脫細節的困擾，把握問題的核心。就像老子說的那樣：治大國如烹小鮮。
噢，對了，“治大國如烹小鮮”也是久遠的教誨，也包含著古老的智慧。
余 晟
公眾號“余晟以為”（yurii-says）作者
現在滬江教育集團擔任平臺架構部負責人
序言
軟件架構（architecture）究竟是什么？
不論從哪個角度分析軟件系統，都不可能面面俱到。如果從架構學角度來分析，在一定程度上能夠做到抓大放小，把握住重點，但是也不可避免地會錯失某些重要的細節信息。
軟件架構學關注的的一個重點是組織結構（structure）。不管是討論組件（Component）、類（Class）、函數（Function）、模塊（Module），還是層級（Layer）、服務（Service）以及微觀與宏觀的軟件開發過程，軟件的組織結構都是我們的主要關注點。但是真實世界中的許多軟件項目并不完全按照我們的信念和愿望生長——它們就像超大型國企那樣，層層嵌套，纏繞成一團亂麻 。有的時候真的很難相信，軟件項目的組織結構性也能像物理建筑那樣一目了然，層次清晰。
物理建筑，不管其地基是石頭還是水泥，形狀是高大還是寬闊，風格是氣勢恢宏還是小巧玲瓏，其組織結構都一目了然。物理建筑的組織結構必須遵守“受重力”這一自然規律，同時還要符合建筑材料自身的物理特性。軟件項目則沒有定律可以遵循。另外，物理建筑是用磚頭、水泥、木頭、鋼鐵或者玻璃等標準材料建成的，而大型軟件項目往往是由小的軟件組件構成的，這些軟件組件又是由更小的軟件組件構成的，層層堆疊，無窮無盡。
所以，當討論軟件架構時，要特別注意軟件項目是具有遞歸（recursive）和分形（fractal）特點的，最終都要由一行行的代碼組成。脫離了一行行的代碼，脫離了具體的細節設計，架構設計就無從談起。大型物理建筑通常可以用比例模型分層描述細節信息，但是軟件項目內部結構是很難用模型分層描述的。軟件項目也具有內部結構，但是其結構無論從數量上還是多樣性上來說，都遠遠超過了物理建筑的結構。可以不夸張地說，軟件開發比修建物理建筑需要更長、更專注的設計過程，軟件架構師應該比建筑架構師更懂架構！
比例模型是深入人心的展示方式，但是不管某個PowerPoint圖表中的彩色方塊多么好看，多么簡單易懂，它也無法完全代表一個軟件的架構。它只能是該軟件的架構的一個視圖，而非全部。軟件的架構并沒有固定的展現形式，你所看到的每一個視圖的背后都是架構師所做的層層抉擇。一個視圖包含了哪些部分，排除了哪些部分；用特殊形狀和顏色強調了哪些部分，又有哪些部分被泛泛地一筆帶過，甚至直接忽略，這些都是這個視圖本身的特性。然而，每個視圖都是對的，它們往往并沒有優劣之分。
雖然軟件無法很好地用比例模型展示，但它還是要在現實世界中運行的。在設計軟件架構的過程中，我們必須理解和遵守現實的約束條件。CPU速度和網絡帶寬往往在很大程度上決定了系統的性能，而內存和存儲空間的大小也會大幅影響代碼的設計野心。
女士，這就是愛情的窮兇極惡之處，人的意愿是無窮的，而實際行動卻處處受限。人的欲望是無止境的，行為卻不得不遵從現實的限制。
——威廉·莎士比亞
人類的整個經濟活動都是存在于現實世界中的，所以我們可以利用現實世界的一些準則來衡量和推理軟件開發過程中那些不好量化和物化的因素。
軟件架構是系統設計過程中的重要設計決定的集合，可以通過變更成本來衡量每個設計決定的重要程度。
——Grady Booch
需要付出的時間、金錢和人力成本是區分軟件架構規模大小的衡量標準，也可以用來區分架構設計和細節設計。同時，我們還可以依據這個信息來判斷某個特定架構設計是好還是壞：一個好的架構，不僅要在某一特定時刻滿足軟件用戶、開發者和所有者的需求，更要在一段時間內持續滿足他們的后續需求。
如果你覺得好架構的成本太高，那你可以試試選擇差的架構加上返工重來的成本。
——Brian Foote 和 Joseph Yoder
一個系統的常規變更不應該是成本高昂的，也不應該需要難以決策的大型設計調整，更不應該需要單獨立項來推進。這些常規變更應該可以融入每日或者每周的日常系統維護中去完成。
我們怎么能夠預知某個系統未來的變更需求，以便提前做準備呢？我們怎么能在沒有水晶球與時光穿梭機的情況下，未卜先知，降低未來的變更成本呢？
所謂軟件架構，就是你希望在項目一開始就能做對，但是卻不一定能夠做得對的決策的集合。
——Ralph Johnson
了解歷史已經夠難了，我們對現實的認知也不夠可靠，預言未來就更難了。
這就是不同的軟件開發理論的主要分歧點。
其中一條比較悲觀陰暗的路線認為，只有權威和剛性才能帶來強壯與穩定。如果某項變更成本高昂，那么就應該忽視它——變更背后的需求要么應該被抑制，要么就應該被丟到官僚主義的大機器中去絞碎。架構師的決定永遠是完整的、徹底的，軟件架構就是全體開發人員的敵托邦噩夢（Dystopia），永遠是所有人沮喪的源泉。
另外一條路線則到處充斥著大量的投機性的通用設計。在這樣的軟件項目中到處都是硬編碼的猜測性代碼，到處是無窮無盡的參數，存在著成篇累牘的無效代碼。 維護這樣的項目，肯定會遇到意外情況，而且無論預留多少資源都不夠應付。
而本書試圖探索的則是一條整潔路線。這條路線擁抱軟件的靈活多變性，將其作為系統的一級設計目標。同時，我們也承認人類并不能全知全曉，但在信息不全的情況下人類仍然能夠做出優良的決策。這條路線可以讓我們多發揮優勢，避開弱勢。通過實際創造和探索，不停地提出問題和進行實驗。優良的軟件架構不是一成不變的，只有經過不斷打磨和改進才能最終成就。
軟件架構是一個猜想，只有通過實際實現和測量才能證實。
——Tom Gilb
遵循這條路線，我們需要用心，全神貫注，不停觀察和思考，在原則指導下不斷實踐。雖然這可能聽起來很麻煩、很慢，但是只要堅持走下去一定能夠成功。
走快的唯一方法是先走好。
——Robert C. Martin
一起享受這個過程吧！
Kevlin Henney
2017年5月
前言
本書的名字叫作《架構整潔之道》，使用這個名字可謂是十分膽大，甚至可以說有點目中無人了。那么，為什么我會選擇寫這本書，并且使用這個名字呢？
自1964年，12歲的我寫下了人生的第一行代碼算起，到2016年，我已經編程超過50年。在這段時間里，我自認為學到了構建軟件系統的一些方法——并且我相信這些方法和經驗對其他人應該有些價值。
我學習的途徑是實際構建一些大大小小的軟件系統。我寫過小型的嵌入式系統，也構造過大型的批處理系統；我構建過實時控制系統，也構建過Web網頁系統；我寫過命令行程序、圖形界面程序、進程管理程序、游戲、計費系統、通信系統、設計工具、畫圖工具等。
我寫過單線程程序，也寫過多線程程序；我寫過由幾個重型進程組成的應用，也寫過由大量輕型進程組成的應用；我寫過跨多個處理器的應用，還有數據庫類、數值計算類和幾何計算類應用，以及很多很多其他類型的應用。
回首過去，經歷了這么多應用和系統的構建過程，我最意外的領悟是：
軟件架構的規則是相同的！
我所構建的這些系統是千差萬別的，為什么所有這些差異巨大的系統都遵守同樣的軟件架構規則呢？這里我得出的結論是，軟件架構規則和其他變量完全無關。
回顧過去這半個世紀以來硬件系統產生的巨大變革，這個結論就更驚人了。我的編程生涯起步于像家用冰箱那么大的巨型機時代，它的CPU頻率只有0.5MHz，擁有4KB核心內存，32KB磁盤存儲，以及每秒只能傳輸10個字符的電傳打字機接口。而現在，我正在一輛游覽南非的觀光車上敲這篇前言。我正在用一個擁有4核i7的MacBook，每核2.8GHz。這臺筆記本電腦有16GB內存，1TB SSD硬盤，可以用2880?1800虹膜顯示屏展現高清視頻。二者計算能力上的差距真的是天壤之別。粗略分析可知，這臺MacBook至少比我半個世紀以前用的計算機強大1022倍。
22個數量級的差距是非常非常巨大的，從地球到半人馬星系也只有1022埃（angstrom，長度單位，主要用來描述原子尺寸與波長），你口袋里的零錢加起來所包含的電子數量也差不多為1022個。而這個數字（注意還是至少）是我在一生中，所親身經歷的計算能力的提升。
計算能力發生了這么巨大的變化，但對我所寫軟件的影響有多大呢？軟件尺寸當然變大了。我過去認為2000行的程序就很龐大了。畢竟這樣的程序變成打孔卡片能裝滿一盒子，重量超過10磅。而現在，一個10萬行的程序都不能算大程序了。
同時，軟件性能當然也有大幅提升。我們現在可以輕輕松松地完成那些1960年只能幻想的事情。電影The Forbin Project、The Moon is a Harsh Mistress以及2001: A Space Odyssey都試圖預言我們的現狀，但是都沒有成功。在這些電影中普遍展現的是獲得了智能的巨型機器，而我們目前所擁有的計算機，雖然體積之小是當初難以想象的，卻還僅僅只是機器。
同時，還有一點很重要，今天的軟件與過去的軟件本質上仍然是一樣的。都是由if語句、賦值語句以及while循環組成的。
哦，你可能會抗議說我們現在有更好的編程語以及更先進的編程范式了。畢竟，我們現在都是用Java、C#、Ruby語言編寫程序，并且大量采用面向對象編程方式。這沒錯，但是最終產生的代碼仍然只是順序結構、分支結構、循環結構的組合，這方面和20世紀60年代甚至50年代的程序是一模一樣的。
如果深入研究計算機編程的本質，我們就會發現這50年來，計算機編程基本沒有什么大的變化。編程語言稍微進步了一點，工具的質量大大提升了，但是計算機程序的基本構造沒有什么變化。
如果一個1966年的計算機程序員時空穿梭來到2016年，在我的MacBook上用IntelliJ寫Java程序，她 可能也就需要24小時來適應一下，然后很快就能照常工作了。Java其實和C區別并不大，和FORTRAN也沒那么大區別。
同樣，如果我把你——讀者傳送回1966年，告訴你如何在一個每秒處理10個字符的終端上通過打孔紙帶來編輯PDP-8代碼，估計你最多也只需要24小時的適應時間。畢竟編程還是編程，代碼并沒有本質的變化。
這就是秘密所在：計算機代碼沒有變化，軟件架構的規則也就一直保持了一致。軟件架構的規則其實就是排列組合代碼塊的規則。由于這些代碼塊本質上沒有變化，因此排列組合它們的規則也就不會變化。
年輕的一代程序員可能認為這些都是胡說。他們可能堅持認為現在所有東西都是嶄新的、從來沒有過的，過去的規則已經過時，不再適用了。這是一個非常大的錯誤。這些規則一直都沒有變。雖然我們有了新的編程語言、新的編程框架、新的編程范式，但是軟件架構的規則仍然和1946年阿蘭·圖靈寫下第一行機器代碼的時候一樣。
當然，不一樣的是，那時候我們還不知道規則是什么。所以我們一次一次地顛覆了它，并且為此一次一次地付出了代價。半個世紀過去了，我們終于可以說，現在我們對這些規則有一定程度的了解了。
寫這本書就是為了講述這些規則，這些永恒的、不變的軟件架構規則。
致謝
下列這些人在本書編纂過程中提供了幫助，在此深表感謝，以下無特定順序。
Chris Guzikowski
Chris Zahn
Matt Heuser
Jeff Overbey
Micah Martin
Justin Martin
Carl Hickman
James Grenning
Simon Brown
Kevlin Henney
Jason Gorman
Doug Bradbury
Colin Jones
Grady Booch
Kent Beck
Martin Fowler
Alistair Cockburn
James O. Coplien
Tim Conrad
Richard Lloyd
Ken Finder
Kris Iyer (CK)
Mike Carew
Jerry Fitzpatrick
Jim Newkirk
Ed Thelen
Joe Mabel
Bill Degnan
還有許多許多其他的人，這里不再一一列出。
在本書最后審校的過程中，當我讀第21章的時候，回想起Jim Weirich明亮的大眼睛和富有旋律的笑聲。Jim，祝你一切順利! |
內容簡介：《架構整潔之道》是創造“Clean神話”的Bob大叔在架構領域的登峰之作，圍繞“架構整潔”這一重要導向，系統地剖析其緣起、內涵及應用場景，涵蓋軟件研發完整過程及所有核心架構模式。本書分為6部分，第1部分綱領性地提出軟件架構設計的終極目標，描述軟件架構設計的重點與模式；第2~4部分從軟件開發中三個基礎編程范式的定義和特征出發，進一步描述函數、組件、服務設計與實現的定律，以及它們是如何有效構建軟件系統的整體架構的；第5部分從整潔架構的定義開始，詳細闡述軟件架構設計過程中涉及的方方面面，包括劃分內部組件邊界、應用常見設計模式、避開錯誤、降低成本、處理特殊情況等，并以實戰案例將內容有機整合起來；第6部分講述具體實現細節；附錄則透過作者數十年的軟件從業經歷再次印證本書的觀點。對于每一位軟件研發從業人員——無論從事的是具體編碼實現、架構設計，還是軟件研發管理，本書都是不可或缺的。 |
目錄：第1部分 概述
第1章 設計與架構究竟是什么 3
目標是什么 4
案例分析 5
本章小結 11
第2章 兩個價值維度 12
行為價值 13
架構價值 13
哪個價值維度更重要 14
艾森豪威爾矩陣 15
為好的軟件架構而持續斗爭 16
第2部分 從基礎構件開始：編程范式
第3章 編程范式總覽 21
結構化編程 22
面向對象編程 22
函數式編程 23
僅供思考 23
本章小結 24
第4章 結構化編程 25
可推導性 26
goto是有害的 28
功能性降解拆分 29
形式化證明沒有發生 29
科學來救場 29
測試 30
本章小結 31
第5章 面向對象編程 32
封裝 33
繼承 36
多態 38
本章小結 44
第6章 函數式編程 45
整數平方 46
不可變性與軟件架構 47
可變性的隔離 48
事件溯源 49
本章小結 51
第3部分 設計原則
第7章 SRP：單一職責原則 56
反面案例2：代碼合并 59
解決方案 60
本章小結 61
第8章 OCP：開閉原則 62
思想實驗 63
依賴方向的控制 67
信息隱藏 67
本章小結 67
第9章 LSP：里氏替換原則 68
繼承的使用指導 69
正方形/長方形問題 70
LSP與軟件架構 70
違反LSP的案例 71
本章小結 73
第10章 ISP：接口隔離原則 74
ISP與編程語言 76
ISP與軟件架構 76
本章小結 77
第11章 DIP：依賴反轉原則 78
穩定的抽象層 79
工廠模式 80
具體實現組件 82
本章小結 82
第4部分 組件構建原則
第12章 組件 84
組件發展史 85
重定位技術 88
鏈接器 88
本章小結 90
第13章 組件聚合 91
復用/發布等同原則 92
共同閉包原則 93
共同復用原則 94
組件聚合張力圖 95
本章小結 97
第14章 組件耦合 98
無依賴環原則 99
自上而下的設計 105
穩定依賴原則 106
穩定抽象原則 112
本章小結 117
第5部分 軟件架構
第15章 什么是軟件架構 120
開發（Development） 122
部署（Deployment） 123
運行（Operation） 123
維護（Maintenance） 124
保持可選項 124
設備無關性 126
垃圾郵件 128
物理地址尋址 129
本章小結 130
第16章 獨立性 131
用例 132
運行 133
開發 133
部署 134
保留可選項 134
按層解耦 135
用例的解耦 136
解耦的模式 136
開發的獨立性 137
部署的獨立性 137
重復 138
再談解耦模式 139
本章小結 141
第17章 劃分邊界 142
幾個悲傷的故事 143
FitNesse 146
應在何時、何處畫這些線 148
輸入和輸出怎么辦 151
插件式架構 152
插件式架構的好處 153
本章小結 154
第18章 邊界剖析 155
跨邊界調用 156
令人生畏的單體結構 156
部署層次的組件 158
線程 159
本地進程 159
服務 160
本章小結 161
第19章 策略與層次 162
層次（Level） 163
本章小結 166
第20章 業務邏輯 167
業務實體 168
用例 169
請求和響應模型 171
本章小結 172
第21章 尖叫的軟件架構 173
架構設計的主題 174
架構設計的核心目標 175
那Web呢 175
框架是工具而不是生活信條 175
可測試的架構設計 176
本章小結 176
第22章 整潔架構 177
依賴關系規則 179
一個常見的應用場景 183
本章小結 184
第23章 展示器和謙卑對象 185
謙卑對象模式 186
展示器與視圖 186
測試與架構 187
數據庫網關 188
數據映射器 188
服務監聽器 189
本章小結 189
第24章 不完全邊界 190
省掉最后一步 191
單向邊界 192
門戶模式 193
本章小結 193
第25章 層次與邊界 194
基于文本的冒險游戲：Hunt The Wumpus 195
可否采用整潔架構 196
交匯數據流 199
數據流的分割 199
本章小結 201
第26章 Main組件 203
最細節化的部分 204
本章小結 208
第27章 服務：宏觀與微觀 209
面向服務的架構 210
服務所帶來的好處 210
運送貓咪的難題 212
對象化是救星 213
基于組件的服務 215
橫跨型變更 216
本章小結 216
第28章 測試邊界 217
測試也是一種系統組件 218
可測試性設計 219
測試專用API 220
本章小結 221
第29章 整潔的嵌入式架構 222
“程序適用測試”測試 225
目標硬件瓶頸 228
本章小結 238
第6部分 實現細節
第30章 數據庫只是實現細節 240
關系型數據庫 241
為什么數據庫系統如此流行 242
假設磁盤不存在會怎樣 243
實現細節 243
但性能怎么辦呢 244
一段軼事 244
本章小結 246
第31章 Web是實現細節 247
無盡的鐘擺 248
總結一下 250
本章小結 251
第32章 應用程序框架是實現細節 252
框架作者 253
單向婚姻 253
風險 254
解決方案 255
不得不接受的依賴 255
本章小結 256
第33章 案例分析：視頻銷售網站 257
產品 258
用例分析 258
組件架構 260
依賴關系管理 261
本章小結 262
第34章 拾遺 263
按層封裝 264
按功能封裝 266
端口和適配器 268
按組件封裝 270
具體實現細節中的陷阱 274
組織形式與封裝的區別 275
其他的解耦合模式 277
本章小結：本書拾遺 279
后序 280
附錄A 架構設計考古 283 |
| 序： |
|
