耗費(fèi)近三個月，其中經(jīng)歷了長達(dá)一個月的9117工作強(qiáng)度，以及其它諸多紛雜的干擾之后，終于在云南回武漢的火車上將這本書翻到了最后一頁。
1. 概述
關(guān)于本書的作者Bob大叔，對筆者可謂影響深遠(yuǎn)。從最開始接觸的《代碼整潔之道》中感受到的匠人精神（《Clean Code讀后感》），到之后閱讀Bob大叔強(qiáng)烈推薦的《SICP》所感受到三觀重建，以及最近的本《架構(gòu)整潔之道》里久遠(yuǎn)的教誨，古老的智慧（出自推薦序二，直接借用下）。對于耳熟能詳?shù)脑恚薏呷肜锏钠饰?，不由讓人感慨—大師就是大師?/p>
全書被分為六部分，由最開始的概述，到之后的編程范式，設(shè)計(jì)原則，組件構(gòu)建原則以及軟件架構(gòu)，到最后的實(shí)現(xiàn)細(xì)節(jié)，作者完全拋開了現(xiàn)在被所有公眾號，技術(shù)書鼓吹的分布式，高并發(fā)，高可用的噱頭，直接回歸本質(zhì)，由軟件領(lǐng)域多年積累的諸如SOLID原則，編程范式等入手，剖析架構(gòu)的本質(zhì)，帶領(lǐng)讀者探索隱藏在架構(gòu)這個高大尚名詞，以及被諸多或無意，或有心的人用各種新造"大詞"遮蓋住的本質(zhì)。揭示出深層次的，本質(zhì)性的，原理性的，可遇見范圍內(nèi)，甚至未來極小可能性被顛覆的智慧。整本書看下來不似其它討論架構(gòu)的書那樣，一堆新奇的名詞和概念只會讓你感到無比焦慮，而從本書中你所感受到的是踏實(shí)和平和，掌握了真諦的安心感，即使是未知也將在你的預(yù)期范圍內(nèi)的。
發(fā)完頗多感慨之后，接下來筆者就本書中一些印象深刻的章節(jié)做出一些自己的解讀，寄希望于在留下思考的痕跡，留作之后的對比提升（筆者閱讀本書的時間跨度比較長，有所紕漏還請見諒）。
2. 全書概況
2.1 前言部分
是的，在《架構(gòu)整潔之道》一書中，Bob大叔在前言部分就一語道破天機(jī) — 軟件設(shè)計(jì)發(fā)展了這么多年，使用的技術(shù)和工具更新?lián)Q代了無數(shù)次，但是軟件架構(gòu)的規(guī)則是相同的，而本書正是為了揭示這些永恒的，不變的軟件架構(gòu)規(guī)則。關(guān)于這一點(diǎn)，筆者在最近幾年的閱讀和實(shí)踐中也有類似的感受 — 關(guān)于微服務(wù)和分布式的思考。
2.2 概述部分
本部分共包含兩個章節(jié)，其中給筆者留下印象比較深刻的是第二章節(jié)中關(guān)于“軟件”的解釋 — 軟件發(fā)明的目的就是讓我們可以以一種靈活的方式來改變機(jī)器的工作行為，對于機(jī)器上那些很難改變的工作行為，我們通常稱之為“硬件”。
關(guān)于以上這段，結(jié)合作者之后的論述，筆者認(rèn)為，并不是說你所編寫的程序就是軟件，如果你的程序?qū)σ蕾嚭翢o控制，任由依賴的侵入，在面對需求時候難以改變，那這樣的程序其實(shí)并不能稱之為“軟件”。軟件二字重點(diǎn)提現(xiàn)在前面一個“軟”字上，其必須有足夠的"軟"，從而確保在面對需求變更或外部條件發(fā)生變化時候能夠靈活應(yīng)對。
2.3 編程范式
作者在本部分介紹了三種編程范式，基本在這個行業(yè)里浸淫過一兩年的人，對這三種范式多少都有耳聞。但作者對對這三者的解讀以及總結(jié)卻是諸多在這行業(yè)里多年的人都難以望其項(xiàng)背的。作者在本部分的第一章中總結(jié)到 — 這三種編程范式都從某一方面限制和規(guī)范了程序員的能力，沒有一個范式是增加新能力的。
- 結(jié)構(gòu)范式限制了goto語句的使用
- 面向?qū)ο笙拗屏撕瘮?shù)指針的使用
- 函數(shù)式則是限制了賦值語句的使用
以上結(jié)論與直覺相反，但靜下心來仔細(xì)思考，卻又發(fā)現(xiàn)確實(shí)如此，也許這就是思考的樂趣 — 獲得與直覺相反的正確性知識。
另外從1968年至今，人們沒有再提出任何新的編程范式，搞不好以后也沒有了。
2.4 SOLID設(shè)計(jì)原則
關(guān)于大名鼎鼎的SOLID設(shè)計(jì)原則的名詞解釋就不用多說了。
作者在本部分分別針對SOLID這五個原則進(jìn)行了講解，告訴讀者這五個原則不僅僅適用于類和模塊的設(shè)計(jì)，在軟件架構(gòu)層面，它們甚至有著更加重大的意義。
2.5 組件構(gòu)建原則
相較于前面章節(jié)指導(dǎo)"將磚塊砌成房間"，本部分則更上一個層次——傳授讀者在“將房間組合成房子”過程中需要注意和遵循的原則，這些原則也就是組件構(gòu)建原則。
為了保證組件的獨(dú)立部署特性，我們遵循如下基本原則：
- REP：復(fù)用/發(fā)布等同原則。
- CCP：共同閉包原則。
- CRP：共同復(fù)用原則。
而關(guān)于組件之間的關(guān)系，為了避免組件之間的過度耦合，我們需要遵守如下基本原則：
- ADP：無依賴環(huán)原則(P99)。即組件依賴關(guān)系圖中不應(yīng)該出現(xiàn)環(huán)。
- SDP：穩(wěn)定依賴原則(P106)。即依賴關(guān)系必須要指向更穩(wěn)定的方向。
- SAP：穩(wěn)定抽象原則(P112)。即一個組件的抽象化程度應(yīng)該與其穩(wěn)定性保持一致。
關(guān)于以上六個原則，說來慚愧，雖然多年來未敢放下手中的書籍，但依然只在非常偶然的機(jī)會閱讀阿里大神梁飛的 以HTTL為例講講模塊分包&領(lǐng)域模型&擴(kuò)展框架 時首次接觸到類似的概念，Bob大叔這里算是第二次接觸。每每念及此，不由得讓人心生感慨。
2.6 軟件架構(gòu)
在所有六個部分中，本部分是擁有最多的章節(jié)的。而在本部分中，作者列舉了一個好的軟件架構(gòu)應(yīng)該支持的目標(biāo)，以及為此需要注意的事項(xiàng)。鑒于方面較多，而筆者目前的水平也僅限于理解，尚未形成自己的反思和總結(jié)，就不在這里大放厥詞了。
本部分給筆者影響最深刻的是關(guān)于Main組件和測試邊界。
- 關(guān)于前者，Main組件是整個系統(tǒng)中細(xì)節(jié)最多的，而且該組件應(yīng)該是整個系統(tǒng)中的一個底層組件，處于整潔架構(gòu)的最外圈，主要負(fù)責(zé)加載所有的必要信息，然后將控制權(quán)交回給系統(tǒng)的高層組件。
- 關(guān)于后者，只能說筆者最近的經(jīng)歷讓筆者對于測試重要性的理解更加深了一步。測試先行，在測試認(rèn)可了當(dāng)前改動之后再進(jìn)行下一步的研發(fā)和修復(fù)工作。一窩蜂戰(zhàn)術(shù)那只能將命運(yùn)交給老天爺。
2.7 實(shí)現(xiàn)細(xì)節(jié)
本部分作者用前三章告訴我們：
- 數(shù)據(jù)庫只是實(shí)現(xiàn)細(xì)節(jié)。我們在架構(gòu)設(shè)計(jì)時候應(yīng)該隔離它們。
- Web也只是實(shí)現(xiàn)細(xì)節(jié)。它也只是1960年來數(shù)次振蕩中的一次，在做架構(gòu)設(shè)計(jì)的時候其不應(yīng)該作為作決定的約束條件。
- 應(yīng)用程序框架只是實(shí)現(xiàn)細(xì)節(jié)。作者在開篇尖銳地指出框架作者和使用者之間不對等的關(guān)系，我們在選擇框架時一定要慎重，時刻保持警惕，讓框架保持在實(shí)現(xiàn)細(xì)節(jié)之列，避免讓其進(jìn)入架構(gòu)核心。
關(guān)于本部分的拾遺一章，真的給予筆者很大的驚喜，章節(jié)作者開篇即道出設(shè)計(jì)的困難之處往往就在于細(xì)節(jié)之中，要將設(shè)計(jì)映射到對應(yīng)的代碼結(jié)構(gòu)上。由此引出了四種安排具體安排代碼設(shè)計(jì)和代碼結(jié)構(gòu)的方法：
- 按層封裝（水平切分）。經(jīng)典到看著想吐的Controller，Service，Repository三層架構(gòu)這一在項(xiàng)目初期比較合適的組織方式。
- 按功能封裝（錘子切分）。正如作者所說，這種組織方式好處是代碼容易找到，但得益于現(xiàn)代IDE的日益強(qiáng)大，這點(diǎn)好處似乎變得越來越不明顯，但讓人慚愧的是筆者所在公司的系統(tǒng)更新方式讓這種封裝方式越來越流行，唉。
- 端口和適配器。這種組織方式下，只有外部能依賴內(nèi)部代碼，反之則不能。
- 按組織封裝。 這種組織方式，充分利用了編譯器的特性，將一個粗粒度組件相關(guān)的所有類放在一個Java包中，只開放必要的public類。這對于筆者有著嚴(yán)重代碼潔癖的人來說真是深以為然（基礎(chǔ)之訪問修飾符）。
另外筆者深受“神在細(xì)節(jié)之中”思想的影響，始終堅(jiān)信在包結(jié)構(gòu)劃分和代碼組織方式上一定有更多且更優(yōu)的方式，現(xiàn)在看到另外一位大師對其的思考，這真是一件讓人無比興奮的事情（是的，本章節(jié)的作者并不是Bob大叔）。
2.8 附錄A
在本章中，Bob大叔回顧了自己幾十年的職業(yè)生涯中對其影響頗深的項(xiàng)目以及由此帶來的影響，例如維護(hù)中心計(jì)算機(jī)（SAC）所引發(fā)的對代碼整潔性的重視；以及修理工派遣系統(tǒng)這個在1985年誕生的微服務(wù)架構(gòu)，太陽下面沒有新鮮事。筆者在其中看到不少感同身受的地方，原來大師也曾經(jīng)深受困擾，只是他們會從中學(xué)習(xí)，反思，最后一步步走到現(xiàn)在。筆者個人非常喜歡這種的行文風(fēng)格（正如，很多人以為架構(gòu)師未卜先知，但其實(shí)事實(shí)絕非如此，bob大叔在書中不斷強(qiáng)調(diào)要迭代和持續(xù)觀察反思）。想著自己的困惑也是大師曾經(jīng)深陷其中的，讓筆者更能將注意力集中到解決問題上，而不是不斷去懷疑自己的智商問題。
3. 最后
筆者作為半路出家的野路子，初入此行時深感基礎(chǔ)薄弱，不入大佬法眼，時至今日依然不敢放下手中的書籍，看似勤奮，但實(shí)際情況是在被生活裹挾的職業(yè)生涯中，逐漸被各種經(jīng)典概念的鮮艷外衣，多年的業(yè)務(wù)邏輯迷惑住了雙眼，將前輩的諄諄教誨束之高閣，現(xiàn)在回想起來，不由得汗顏。
最后推薦還在猶豫是否閱讀本書的讀者至少去翻閱下該書的兩篇推薦序，兩位作者都是國內(nèi)赫赫有名的大能，其中第二篇直接以實(shí)際例子說明所謂的“藍(lán)綠部署”歸根結(jié)底也就是老程序員所銘記于心的隔離變化，關(guān)注點(diǎn)分離思想的體現(xiàn)，不過爾爾。
突然發(fā)現(xiàn)自己好久沒有在閱讀完一本書后再去復(fù)習(xí)了。
4. 相關(guān)鏈接
5. 附錄（經(jīng)典語錄）
最后摘抄一點(diǎn)經(jīng)典語錄吧：
- 軟件架構(gòu)師自身需要是程序員，并且必須一直堅(jiān)持做一線程序員。軟件架構(gòu)師其實(shí)應(yīng)該是能力最強(qiáng)的一群程序員。
- 如果不親身承受因系統(tǒng)設(shè)計(jì)而帶來的麻煩，就體會不到設(shè)計(jì)不佳所帶來的痛苦，接著就逐漸迷失正確的設(shè)計(jì)方向。
- Humble object對象模式，對象清楚地認(rèn)識到自己的局限性，只發(fā)揮自己的橋梁和通信作用，并不從中干預(yù)信息的傳輸。
- 架構(gòu)師必須持續(xù)觀察系統(tǒng)的演進(jìn)，時刻注意哪里可能需要設(shè)計(jì)邊界，然后仔細(xì)觀察這些地方由于不存在邊界而出現(xiàn)哪些問題。持之以恒，一刻不能放松。(P202)
- 在真正制作出來一個可復(fù)用的框架之前，是不知道怎么制作一個可復(fù)用框架的，想要制作一個可復(fù)用的框架，必須要和幾個復(fù)用該框架的應(yīng)用一起開發(fā)。(P324)
