康威定律，作為架構師還不會靈活運用？

Soft skills are always hard than hard skills. 軟技能比硬技能難。

老板聽說最近流行“微服務”，問架構師咱們的系統要不要來一套？老板又聽說最近流行“中臺系統”，問架構師咱們要不要搞起來？其實，這些問題不用老板問，關注技術發展趨勢的架構師每當聽到新的技術或解決方案，都會暗中思忖是否應用到系統中。然而，用或不用，總不能憑感覺吧。此時，如果你能靈活運用康威定律，那么做出的判斷將更加完美。

康威定律

康威定律是馬爾文·康威1967提出的：“設計系統的架構受制于產生這些設計的組織的溝通結構。”通俗的來講：產品必然是其（人員）組織溝通結構的縮影。

跨部門溝通是非常難的，系統各個模塊的接口也反映了它們之間的信息流動和合作方式。

康威定律可謂軟件架構設計中的第一定律，起初只是在雜志上的發表，后經過《人月神話》這本軟件界圣經的引用，并命名為康威定律（Conway’s law），因此得以推廣。

只通過簡單的描述可能無法理解康威定律的精髓所在，原文中康威定律可總結為四個定律：

第一定律組織溝通方式會通過系統設計表達出來。
第二定律時間再多一件事情也不可能做的完美，但總有時間做完一件事情。
第三定律線型系統和線型組織架構間有潛在的異質同態特性。
第四定律大的系統組織總是比小系統更傾向于分解。

第一定律

Communication dictates design。
組織溝通方式決定系統設計。

這條定律重點是講組織架構和溝通對系統設計的影響。組織的溝通和系統的設計之間緊密相連，特別是復雜系統，解決好人與人的溝通才能有一個更好的系統設計。

《人月神話》中總結出了隨著人員的增加溝通成本呈指數增長的規律：溝通成本 = n(n-1)/2。舉例說明一下：

5人項目組，需要溝通的渠道是 5*(5–1)/2 = 10
15人項目組，需要溝通的渠道是15*(15–1)/2 = 105
50人項目組，需要溝通的渠道是50*(50–1)/2 = 1,225
150人項目組，需要溝通的渠道是150*(150–1)/2 = 11,175

這也是為什么互聯網公司都追求小團隊的原因之一。溝通的問題會帶來系統設計的問題，進而影響整個系統的開發效率和最終產品結果。

第二定律

There is never enough time to do something right, but there is always enough time to do it over。
時間再多一件事情也不可能做的完美，但總有時間做完一件事情。

人手永遠是不夠的，事情永遠是做不完的，但可以一件一件來。這不就是軟件行業中“敏捷開發”模式所解決的問題嗎。面對這樣的狀況，敏捷開發可以做到不斷迭代、持續交付、快速驗證和反饋，并持續改進。

再牛的開發也會寫出bug，再全面的測試覆蓋率也無法測出所有的問題。解決方案不是消滅這些問題，是容忍一些問題的存在，然后通過適當的設計（冗余、監控、高可用設計）當問題發生時能夠快速解決。

幾個開發人員的小公司，去追求微服務、去追求中臺架構，這是追求完美嗎？不是，是找死。

好的架構不是買來的，也不是設計出來的，而是根據業務落地生根長期演化來的。

第三定律

There is a homomorphism from the linear graph of a system to the linear graph of its design organization。
線型系統和線型組織架構間有潛在的異質同態特性。

這一定律是第一定律的具體應用。想象一下如果公司的組織架構是這樣的：團隊是分布式，每個團隊都包含產品、研發、測試、運維等角色。而此時系統是單塊的，項目溝通和協調的成本是巨大的，弄不好還會打起來。

如果將單塊的系統拆分成微服務，每個團隊負責自己的部分，對外提供對應的接口即可，互不干擾。系統效率將得到提升。這與軟件設計中的高內聚、低耦合是相通的。

直白的說就是想要什么的系統就搭建什么樣的團隊，有什么樣的團隊就搭建什么樣的系統。需要前后端分離的系統就搭建前后端分離的團隊，反之，擁有前后端分離的團隊，可以設計前后端分離的系統。當然，如果能統籌管理，擁有重組團隊或設計系統架構的權利，那就再好不過了。通常情況下讓兩者形成1：1的映射關系，更加高效。

第四定律

The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems。
大的系統組織總是比小系統更傾向于分解。

“話說天下大勢，分久必合，合久必分。”系統越復雜，越需要增加人手，人手越多，溝通成本也呈指數增長。分而治之便是大多數公司選擇的解決方案。分不同的層級，分不同的小團隊，讓團隊內部完成自治理，然后統一對外溝通。

楊波老師曾在他的文章《每個架構師都應該研究下康威定律》中提到：“政治指的是和他人協作將事情搞定的藝術，架構是一種社交活動，在技術的世界里，個人主義很容易被打敗，即使你的目的是好的技術是最優的，技術決策是政治決策（technical decisions are political decisions），一個技術產品，一波人可以做，另一波人也可以做，到底誰做的好，真不好說，不管誰做，都給業務套上了一副手銬。”

原文鏈接：《康威定律，作為架構師還不會靈活運用？》

---------------------
作者：程序新視界
來源：CSDN
原文：https://blog.csdn.net/wo541075754/article/details/102476828
版權聲明：本文為作者原創文章，轉載請附上博文鏈接！
內容解析By：CSDN,CNBLOG博客文章一鍵轉載插件