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），一個技術產品，一波人可以做，另一波人也可以做，到底誰做的好，真不好說，不管誰做，都給業務套上了一副手銬。”
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
備註：本文轉自程序新視界，鏈接：