Building Evolutionary Architectures : Support Constant Change 心得歸納6
現實世界中許多損害專案演進能力的偶合
反模式:供應商霸王(vendor lock-in)
- 例如有些大企業會購買企業資源規劃(ERP)軟體
- ERP工具經常無法被訂製成完全實現開發人員所需要的功能
- 開發人員被這種工具束縛
- 最後陷入後面會提到的反模式:最後10%陷阱
- i.e.不要讓自家的架構與供應商耦合
陷阱:有漏的抽象(The Law of Leaky Abstractions — Joel Spolsky)
- 亦即所有非不證自明的抽象概念，都有某種程度的疏漏
- 原始抽象洩漏(primordial abstraction ooze)指再較低層級損壞的抽象會導致意外的毀滅,這是技術堆疊的複雜性增加的副作用之一
- 也就是技術堆疊越複雜的系統,除錯與採證分析就變得困難
- 所以了解技術堆疊中脆弱的地方,並透過適應度函數來自動保護
反模式:最後10%陷阱
- 工具、框架、或語言很容易完成客戶想要完成的80%內容
- 但是接下去的10%可以實現,但是往往卻非常困難
- 難以從80% →90%,甚至最後以失敗告終
- 如IBM的San Francisco專案
反模式:隨便復用程式
- 軟體的復用比較像器官移植,而不是拼裝樂高積木 — John D. Cook
- 微服務捨棄復用,採用重複重於耦合
陷阱:履歷驅動開發
- 架構師容易被令人興奮的新開發方法吸引,是履歷驅動開發陷阱 — 盡量利用所有的框架合程式庫,並且在履歷上兜售那些知識
- 不要為了完成某種架構而建立架構 — 你的工作是解決問題
漸進變更
- 如Continuous Delivery一書所述,許多現代工程做法都支援演進式架構了
反模式:不洽當的治理方式
- 微服務架構有一個共同特性是它們支持多語言環境
- 但是微服務專案的目標並不是隨興地選擇各種不同的技術,而是根據問題的大小選擇合適的技術
- 但要我個人來說的話,技術棧收斂而施放的開發與DevOps遇到問題解決的效能更高
- 但是書中也有提及要避免不同微服務團隊"無意間的耦合"這個問題,甚至可以因此考慮各團隊使用不同技術棧
陷阱:缺乏釋出速度
- "釋出軟體的能力"與"演進軟體設計的能力"有很密切關係
- 如果釋出是需要大量專業知識的工作,那麼利用演進式架構的好處的機會就減少很多
- 持續交付追蹤的是週期時間(一個工作單位),i.e.從軟體開發啟動到完成所花費的時間
- 減少週期時間是持續交付的關鍵目標之一
商業問題
陷阱:自訂產品
- Sales希望能販賣可以自由訂製的軟體,但是這需要一系列的技術才能實現
- 1.為不同顧客量身訂製版本
- 2.永久性功能開關(i.e.為不同顧客建立不同版本,甚至有解鎖高級功能版本)
- 3.產品驅動訂製(例如透過UI來加入訂製功能等)
反模式:報告
- 架構師很難透過同一組"可復用"的服務來支援每個商業關注點
- 服務越通用,它就越需要透過開發人員的客製化才能讓人使用
- 報告是單體架構中無意耦合的好例子
- 例如架構師和DBA都希望紀錄和報告系統使用同一個資料庫schema
- 但是有時schema的設計沒有考慮那兩種系統
陷阱:規劃願景
- 預算編列和程序規劃經常促使人們做出假設,以及為了實現那些假設而做出早期決策
- 長時間的計畫週期會迫使架構師做出不可逆決策
- 將大型工作程序分解成小規模的、可早期交付成果的程序,可以測試架構和基礎設施的可行性
- 在透過最終用戶的回饋來驗證某項技術確實是和用來解決問題之前,架構師應避免使用在實際建構軟體之前需要投資大量資源的技術
其實之前金融業經驗都有踩到上面不好的,也有踩到好的
像是被綁死死的ESB
每每要跟其他系統介接真的會卡在那10%複雜度(技術成本up)
或是常常有台灣原廠搞不定的問題
然後這樣package系統也已經根深蒂固的形成
與公司內其他數十個系統高耦合狀態
未來要演進系統想必成本會非常的高(人力,技術,資源等)
也見識了很多履歷驅動開發的例子
(不管後面接手的人,甚至沒留文件,隨便開發,甚至沒有上到版控中...)
缺發釋出速度更是有卡UAT超過一年的專案完全不上PROD
這對Gitflow設計造成極大困擾(完全沒辦法考慮用feature branch模式)
規劃願景就是公司能不能做到敏捷的問題了
遇到的還是總經理交辦,該功能本週上線的隕石開發模式為主
