每一次的擴充，都不應該是疊床架屋的開始，而是以維運為本的藝術。
前言
前些日子因公參加了一場由「VMware」所舉辦的研討會，議題涵蓋「金融數位轉型」、「雲原生應用」、「DevSecOps」⋯等；其中的一場演講，內容是在分享台灣某一金融相關企業現代化轉型的過程與經驗。
該場的分享者是該企業的一位科長，同時也是該組織中，「DevOps」團隊的領導者。
在那場演講中，講者敘述了他們團隊在轉型過程中曾遭遇過的問題、阻礙，與如何因應、處理，譬如在「團隊建立」時，人員的該如何組成與配置；在「環境建置」時，產品、廠商該如何挑選，包含挑選時應該注意的重點⋯等。
另外，由於金融行業的特殊性，其資安的要求相對嚴格，所以在轉型過程中，與資安相關議題的決策就必須要更謹慎，也更需要經驗了，更別說金融單位還有法規與稽核的議題需要考慮。
在該場分享的內容中，講者的一些論述，筆者覺得相當有意思，譬如在「團隊建立」的議題上，講者他引用了「康威定律」來作為其建立團隊的基礎準則；在「系統架構」的設計上，講者則是採用他自創的「魚缸式架構」的設計方式，而最令筆者印象深刻的還是他說的一句話，他說，「每一次的擴充，不是疊床架屋的開始，而是以維運為本的藝術」；這部分我們晚點再介紹。
除了上述的議題外，筆者還有提到另外一個重點，也讓筆者不可置否；講者說，在整個轉型的過程中，他認為最為棘手、最難以處理的問題仍是在「人」，包含「人」的「溝通」與「協調」，尤其是在「跨部門合作」、「向上溝通」時，更別說其中還可能涉及「組織文化」的革新；對於「人」的議題，他們至今都仍持續地在奮戰。
前言結束了，接著，就讓我們來介紹一下上述那些有趣的論述吧。
正文
康威定律
首先是「康威定律」，英文為「Conway’s Law」；是「Melvin Conway」於「1967」年發表的一篇論文：「How Do Committees Invent?」中所提出的一個概念，其內容是在說，「Melvin Conway」認為，任何「系統」的「架構設計」都會受到其「組織架構」的影響，其相關說明請參考「Mel Conway, CONWAY’S LAW」，該定律的原文敘述如下：
而這個論點在「軟體開發」的領域中常被提及，尤其在「敏捷軟體開發」盛行的當今，例如著名的敏捷大師「Jim Coplien」就曾在「Organizational Patterns of Agile Software Development」一書中寫到：倘若某一「組織結構」與其「產品結構」脫鉤，那麼該「產品」就可能會面臨到一些困境，其原文描述為：「If the parts of an organization — such as teams, departments, or subdivisions — do not closely reflect the essential parts of the product, or if the relationships between organizations do not reflect the relationships between product parts, then the project will be in trouble.」。
同樣為敏捷大師的「Robert Martin」也曾在「Clean Architecture: A Craftsman’s Guide to Software Structure and Design」一作中引述「康威定律」來解釋「SRP, Single Responsibility Principle」，「Robert Martin」是這麼說的：「An active corollary to Conway’s law: The best structure for a software system is heavily influenced by the social structure of the organization that uses it so that each software module has one, and only one, reason to change.」。
關於「康威定律」，或許有人曾聽過其它不同的版本，譬如：「The organization of the software and the organization of the software team will be congruent.」；事實上，這的確也是一種「康威定律」的說法，只是這段敘述並非出自於「Melvin Conway」本人，而是「Eric S. Raymond」在「The New Hacker’s Dictionary」一書中對於「康威定律」的「重新定義」，而我們通常會把這類描述稱為「變體」。
事實上，不只是「Eric S. Raymond」，還有另一個更常見的版本，其描述為：「The structure of any system designed by an organization is isomorphic to the structure of the organization.」，這」是「Yourdon」在「Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design」中所提出的說法。
但各位有沒有想過為什麼會有這些「變體」呢？
筆者認為，其可能原因是「Melvin Conway」的描述比較抽象，就如同他自己說的，他認為，「康威定律」的應用場景，其涵蓋的範圍應不止於「軟體工程」，其原文描述如下：
但正因如此，「Melvin Conway」提出的「康威定律」的描述，其維度就比較高，而當其在被引用時，就可能需要更多的解釋，甚至可能會有「過度解讀」的疑慮產生，而「變體」的描述通常就比較明確且針對性高，當然，這通常也使得其能應用的範圍比較侷限。
最後，說個題外話，根據「Melvin Conway」的說法，「康威定律」一詞其實並不是由他自己所命名的，而是「The Mythical Man-Month: Essays on Software Engineering」的作者「Frederick Phillips Brooks」在其書中引述到「康威定律」的概念時，所使用的名稱。
關於「康威定律」在本文中的介紹就暫時到此，至於其具體細節，倘若未來有機會的話，筆者會在另闢篇幅。
魚缸式架構
接著，我們來介紹講者在談論「系統架構設計」時所提到的一個論述：「魚缸式架構」；與「康威定律」不同，「魚缸式架構」的這套設計理論是作者自創的設計理論；其概念是說，「系統」的「架構」應該就像「魚缸」一樣，一個「大魚缸」可以由多個「小魚缸」組成，且每個「魚缸」都應該是具有「獨立性」的「個體」，其可以輕易的「被擴充」以及「被移除」。
也就是說，在「魚缸式」系統架構的概念中，每個「系統」中的每個「子系統」，其彼此都應該是要能獨立存在，且能獨立運行的；簡單說，就是「子系統」本身為「高內聚」，「子系統」間為「鬆耦合」。
咦，這概念聽起來是不是與「微服務架構」非常相似？
所以，筆者認為，「魚缸式架構」的設計概念一定程度的重疊於「微服務架構」，其兩者都是在傳遞系統的架構設計應具有「高內聚」與「鬆耦合」的特性。
維運為本
最後，讓我們來談談在這場演講中，最令筆者印象深刻的一個概念：「維運為本」。
在這場分享中，筆者有提到一個觀念，他說：「每一次的擴充，都不應該是疊床架屋的開始，而是以維運為本的藝術。」。
我們來咀嚼一下這句話的意思，其中，「擴充」，顧名思義，其可能是新功能的「增加」，當然也可能是既有功能的「修改」，但不論是何者，其都涉及「程式碼」的「異動」，而有經驗的開發者都知道，「異動」通常就是讓「程式架構」走向「疊床架屋」起點。
事實上，程式碼「異動」這件事本身是正常的，也沒有什麼問題，而會導致「疊床架屋」的發生，其十之八九都是源自「不符合當前架構設計」的「異動」；這段描述適用於「系統架構」層級，也適用於「程式架構」層級。
就「系統架構」層面而言，想必有過經驗的人員都知道，只要涉及「系統架構」的「異動」，不論規模是大或小，其所需代價往往不斐，舉例來說，像是容器平台的「抽換」，假設原本使用的容器平台是「K8S」，而今需求是要將容器平台從原本的「K8S」更換成「OCP」，又或是更改「資料庫」的架構、種類，像是因應標準「微服務」概念將「單資料庫」的架構改成「多資料庫」的架構，又或是將「Ms SQL Server」換成「Oracle Database」⋯等。
上述的行為雖然都不是不行，但各個都是傷筋動骨，在執行之前，我們應經過審慎的規劃，並確認異動內容與現行架構的相容及相關風險因應、備援⋯等，在執行時，其更是需要謹慎處理，因為其往往會因為一個粗心或思慮不周，就釀成難以挽回的災難。
而「程式架構」的層面亦然，當在每次程式碼「異動」之後，除了基本「程式碼風格」之外，我們更必須確認其「修改」是否符合原先架構的「設計理念」，與其所屬「類別」、「組件」，以及「模組」，是否仍能遵守「單一職責」⋯等。
而「維運為本」想表達的意思是，當我們在「更改」架構時，應該以「維護」的面向來考量；更直白的說就是，當我在「改動」後，不論是一個「系統」、一段「邏輯」、一個「組件」，我們都可以先問問自己，對於這次的「改動」，倘若三個月後又有一個新的「異動」需求，那麼，這次的改變會使得下次的「工」變得更複雜嗎？
如果會，是不是就意味著我們正在「疊床架屋」，或是離「疊床架屋」不遠了呢？
或許有人會疑惑，為什麼是問「自己」，而不是「別人」？
事實上，當然也可以問「別人」，譬如其它同事，或其它共同開發者⋯等，但是，思考一下，如果連修改者本身都覺得下次的「維護」會更複雜，那又何必再問「別人」呢？
對於這個想法，筆者其實相當的認同，以「自己」作為基準無疑是一個相當簡單且有效的「判斷方式」，雖然它並不是個明確且可量化的「指標」；但這並不重要，因為在大多數的時候，「自己」也通常就是那個「維護者」。
說真的，這場演講的內容讓筆者感觸良多，從「維護」的思維看待「修改」，這句話想要傳遞的，其實就是「可維護性」，或著更正確的說，是「可維護性」的「本質」；當我們在追求以各種相對複雜的「量化指標」或是「方法論」來對「可維護性」秤斤論兩時，或許我們是不是該緩一緩腳步，回歸本質，以一個最簡單的角度去看待「開發」這件事情。
筆者想表達的並不是說那些「量化指標」或「方法論」沒有用，而是認為，當我們走在追求這些「估算」後的「量化數值」的道路上時，是否應不斷地自檢、自省，時刻提醒自己，莫忘了「數值」背後的「初衷」，方才能避免落入一昧追求「數值」的陷阱，走到「矯枉過正」的歧途上。
參考資料
- Mel Conway, CONWAY’S LAW
- Mel Conway, How Do Committees Invent?
- Edward Yourdon, Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design
- Eric S. Raymond, The New Hacker’s Dictionary
- Frederick Phillips Brooks, The Mythical Man-Month: Essays on Software Engineering
- James Coplien & Neil Harrison, Organizational Patterns of Agile Software Development
- Robert Martin, Clean Architecture: A Craftsman’s Guide to Software Structure and Design
