通讀完《架構(gòu)整潔之道》全書，回過頭再來寫總結(jié)和感想醇王，真不是一件容易的事呢燥。之前在《禪與摩托車維修藝術(shù)再探》里我說，寫這類文字是一個合上書又翻開書的過程寓娩，合上書回想主要收獲叛氨，翻開書做有重點的二次閱讀。這篇就是翻開書棘伴。
組件耦合
這一章節(jié)除了已經(jīng)廣泛應(yīng)用的每日構(gòu)建外寞埠，主要講了三個原則：無依賴環(huán)原則、穩(wěn)定依賴原則焊夸、穩(wěn)定抽象原則仁连。
到這里我想到這些原則、規(guī)則阱穗、law與程序員之間的關(guān)系饭冬。作為一名程序員，這些原則應(yīng)該要內(nèi)化掉揪阶，了解原則之后至少要指導(dǎo)一次編碼實踐昌抠，在實際需求中這些原則應(yīng)該共同組成程序員的良質(zhì)（《禪與摩托車維修藝術(shù)》），指導(dǎo)程序員追求更加有序鲁僚、節(jié)省人力的設(shè)計方法炊苫。作為一名TL、SE或者架構(gòu)師蕴茴，我逐漸意識到劝评，這些原則是需要有意識地收集、整理倦淀、舉證蒋畜、實踐的，因為這類角色經(jīng)常需要去給別人講東西撞叽，經(jīng)常需要推動一些改革姻成，工作重點中有一大部分都是與人打交道，已經(jīng)不止是應(yīng)用愿棋，更多地變成了一本行走的書科展，我想架構(gòu)師團隊?wèi)?yīng)該至少把不同方面不同角度的原則整理出來，將零碎的知識點歸納出來糠雨，作為指導(dǎo)設(shè)計和健康度評估的checklist才睹。
組件依賴關(guān)系圖中不應(yīng)該出現(xiàn)環(huán)。組件間難道不是通過接口通信的嗎？怎么會出現(xiàn)環(huán)呢琅攘？我意識到我認(rèn)為的“組件”和這里說的“組件”出現(xiàn)了不一致垮庐。《組件》一章說“組件是軟件的部署單元”坞琴，可以獨立部署哨查，也可以做成插件進行動態(tài)加載。我想《組件耦合》一章里說的組件剧辐，應(yīng)該是插件寒亥，只有插件才會出現(xiàn)互相依賴的情況，可獨立部署和發(fā)布的組件一般都是依賴于接口的荧关。自然也就不會出現(xiàn)依賴環(huán)溉奕。依賴關(guān)系圖可以通過structure 101或者understand這類軟件自動獲取，用以評估當(dāng)前組件間依賴關(guān)系是否符合預(yù)期羞酗。無依賴環(huán)原則不只適用于組件間腐宋，也適用于模塊間，即domain層的各個文件夾之間檀轨，反思一下胸竞，模塊間的依賴關(guān)系確實是很容易出現(xiàn)環(huán)的，模塊間的依賴關(guān)系很難守護参萄，這往往是業(yè)務(wù)模型或者算法決定的卫枝，這一階段的設(shè)計一般很少考慮依賴關(guān)系，在業(yè)務(wù)專家看來讹挎，就像坐在辦公桌前面對一桌子的零件校赤，每一個具體問題都可以拿來用來解決問題，機械專家組裝機械的時候零件A上需要零件B筒溃，零件B上又需要與零件A同一廠家的零件马篮，將來一旦A廠家更換，B的處境就很尷尬怜奖，整個系統(tǒng)面臨失敗的風(fēng)險浑测。這是一個很現(xiàn)實的問題，這要求業(yè)務(wù)專家也必須了解“實際”歪玲，不能制造空中樓閣迁央，最近新看一本書《系統(tǒng)架構(gòu)》，就是在說不單單程序需要架構(gòu)師滥崩，所有人造系統(tǒng)都需要架構(gòu)師岖圈。
與三個原則同級標(biāo)題的，有一個“自上而下的設(shè)計”钙皮，書中認(rèn)為“組件結(jié)構(gòu)是不可能自上而下被設(shè)計出來的蜂科，它必須隨著軟件系統(tǒng)的變化而變化和擴張”顽决，這與《UNIX編程藝術(shù)》的觀點是不一致的。關(guān)于自上而下還是自下而上崇摄，是分場景的擎值，軟件是要盡量自上而下的，但一個項目演進過程中總會遇到新的變化方向和聚合實體逐抑，這就需要自下而上。熟悉系統(tǒng)的第二次開發(fā)是自上而下屹蚊，新系統(tǒng)的開發(fā)是自下而上厕氨。
依賴關(guān)系必須要指向更穩(wěn)定的方向。前兩天交流的時候我舉了個例子汹粤，模塊A有流量統(tǒng)計的功能命斧，模塊B也想做流量統(tǒng)計，那B能不能直接拿A功能用呢嘱兼？不能国葬，要把流量統(tǒng)計功能提取出來，A和B共同依賴于流量統(tǒng)計芹壕。模塊的穩(wěn)定性汇四，書中給了詳細(xì)的量化穩(wěn)定性的方法可作參考，一個組件的穩(wěn)定程度取決于它的修改頻率踢涌、修改的方式通孽、獲取實例的多少、抽象化程度睁壁，上面舉的就是抽象新模塊的例子背苦，修改頻率高的模塊不穩(wěn)定比如A和B模塊，如果修改的方式總是按系統(tǒng)原始設(shè)計的變化方向進行修改也可以認(rèn)為是穩(wěn)定的潘明，獲取的實例越多行剂、輸出越多表明模塊與外部的聯(lián)系越多外部修改很容易引發(fā)修改也就越不穩(wěn)定。
一個組件的抽象化程度應(yīng)該與其穩(wěn)定性保持一致钳降。這個原則與上面穩(wěn)定依賴原則有點像厚宰，在依賴于抽象的基礎(chǔ)上又做了進一步的要求。穩(wěn)定組件要高度抽象牲阁，否則就會難以修改固阁。比如組件內(nèi)的主流程，就要足夠抽象城菊，主流程太關(guān)注細(xì)節(jié)會導(dǎo)致難于擴展备燃，具體的實現(xiàn)要放到實現(xiàn)層。
