演進式架構

二零二零年讀完的第二十本書，今年讀書的進度不是一點點慢，半年過去了才完成五分之一，我都開始懷疑能否完成既定目標了，跟 Martin 的《微服務設計》搭配着讀更能理解其中的緣由。這本書不管是作者還是譯者的寫作功力都非常厲害，結構清晰，表述到位，不留廢話。

- 整合方法論的書, 通常指適合決策羣體, 受衆有限, 而且離落地很有距離, 對大部分開發而言, 「show me the code」纔是金科玉律

概念太多，不接地氣；着重強調適應度函數，但對於怎麼定義適應度，在各類業務場景下具體如何實操沒有給出案例和說明。粗略看完後，雲裏霧裏，不甚理解。

指引式，概念式小冊子，提供架構演進指引，感覺叫進化會好一些，架構師就是體系的上帝。

主要收穫： 1、圍繞架構的各項特徵維度創建適應度函數，並構建自動測試和自動驗證。以防止架構腐化。 2、如何構建演進式架構。

看看還是可以學習到一些不錯的理念。 例如從進化角度定義的適應度函數。 康威定律對業務、技術、團隊的解釋。 架構是對業務的抽象、提取關注點、隔離複雜度、從多個維度觀看架構。 架構量子以物理學概念類比軟件的基礎構建單元，但是概念類比的時候闡述概念過少、帶着這一塊解釋說明比較空洞不全面。 總的來說：看一看還是可以獲取一些新的概念和視角。也能引發關於架構多角度的思考。 作者書裏面試圖從進化論、量子物理等概念體系來類比解釋軟件姿態的構成和演化。思路不出，但是概念引入的時候做充分的說明和定義還是比較有價值。畢竟、對非物理專業、甚至專業物理學生對量子理解都各不相同。

提出了一個適應度函數說法，說明適應度圍繞着架構而走，並且做演進。 但是這種形式，看起來更像是一種變體的測試驅動開發。你可以認爲所有的適應度函數是一種測試CASE。 並且，也沒有對如何做演進架構做很好的說明。

主要以加入devops流水線的適應度函數建立起架構防腐和引導變更的柵欄。 作爲架構師，一個難點是如何在架構首輪落地後仍持續保持着架構設計的執行、以及適時演進。常規手段是多做培訓，拉齊團隊對設計的理解；更多、全的代碼走查。這些手段還是多依賴“人”去做，歷史經驗是隨着人員出人、n次走查的覆蓋不到位（時間？），幾個月的逐步腐化就會導致專項重構或者重建（成本考慮有時重建會更合適）。 將架構設計約束點、特徵（包括非功能性需求）建立適應度函數，以在代碼入庫前進行覆蓋檢查、監控，保障架構執行。這是架構層次的“單元測試”。

這本書的概念放在十年二十年前，也許值得一讀。現在已經是基礎理念了，長篇累牘囉嗦一大片，實際上就是一句話：軟件架構需要根據實際需要來判定是否演進，演進需要適應性函數作指導。

架構上乾貨不多，新東西不多。圍繞着適應度函數，如何演進講了一大通。 適應度函數如何設計並沒有非常好的落地經驗，看起來更多是一種思想或者一個構建監控指標，卡點體系。 如何演進，如果你在大廠上班基本能學的不多，藍綠髮布，向前兼容性，數據兼容等。涉及架構的部分不如去看ddd。 少部分除了架構技術相關的倒提高了一些姿勢，比如康威定律，比如簡歷驅動架構，這些名詞算是增長見識。