第三定律

• There is a homomorphism from the linear graph of a system to the linear graph of its design organization

• 線型系統和線型組織架構間潛在的異質同態特性

第四定律

• The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems

• 大的系統組織總是比小系統更傾向於分解

三、定律說明

第一定律

人是複雜得社會動物

組織的溝通和系統設計之間的緊密聯絡，在很多別的領域有類似的闡述。對於複雜的系統，聊設計就離不開聊人與人的溝通，解決好人與人的溝通問題，才能有一個好的系統設計。相信幾乎每個程式設計師都讀過的《人月神話》（1975年，感覺都是老古董了，經典的就是經得起時間考驗）裡面許多觀點都和這句話有異曲同工之妙。

比如《人月神話》中最著名的一句話就是

Adding manpower to a late software project makes it later --Fred Brooks, (1975)

Boss們都聽到了嗎？為了趕進度加程式設計師就像用水去滅油鍋裡的火一樣（無奈大家還是前赴後繼）。

為什麼？人月神話也給出了很簡潔的答案：溝通成本 = n(n-1)/2，溝通成本隨著專案或者組織的人員增加呈指數級增長。是的，專案管理這個演算法的複雜度是O(n^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

所以知道為什麼網際網路創業公司都這麼小了吧，必須小啊，不然等CEO和所有人講一遍創業的想法後，風投的錢都燒完了。

Mike還舉了一個非常有意思的理論，叫“Dunbar Number”，這是一個叫Dunbar（廢話）生物學家在1992年最早提出來的。最初，他發現靈長類的大腦容量和其對應的族群大小有一定關聯，進而推斷出人類的大腦能維繫的關係的一些有趣估計。舉例來說

• 親密（intimate）朋友: 5

• 信任（trusted）朋友: 15

• 酒肉（close）朋友: 35

• 照面（casual）朋友: 150

?

是不是和上面的溝通成本的數字很貌似有關聯？是的，我們的大腦智力只能支援我們維繫這麼多的關係。（大家都知道這不是程式猿擅長的領域，在開發團隊裡，這個值應該更小，估計和猿差不多 -_-凸 ）

溝通的問題，會帶來系統設計的問題，進而影響整個系統的開發效率和最終產品結果。

第二定律

一口氣吃不成胖子，先搞定能搞定的

Eric Hollnagel是敏捷開發社群的泰斗之一，在他《Efficiency-Effectiveness Trade Offs》 一書中解釋了類似的論點。

Problem too complicated? Ignore details.

Not enough resources?Give up features.

--Eric Hollnagel (2009)

系統越做越複雜，功能越來越多，外部市場的競爭越來越劇烈，投資人的期待越來越高。但人的智力是有上限的，即使再牛逼的人，融到錢再多也不一定招到足夠多合適的人。對於一個巨複雜的系統，我們永遠無法考慮周全。Eric認為，這個時候最好的解決辦法竟然是——“破罐子破摔”。

其實我們在日常開發中也經常碰到。產品經理的需求太複雜了？適當忽略一些細節，先抓主線。產品經理的需求太多了？放棄一些功能。

據說Eric被一家航空公司請去做安全諮詢顧問，複雜保證飛機飛行系統的穩定性和安全性。Eric認為做到安全有兩種方式：

• 常規的安全指的是儘可能多的發現並消除錯誤的部分，達到絕對安全，這是理想。

• 另一種則是彈性安全，即使發生錯誤，只要及時恢復，也能正常工作，這是現實。

對於飛機這樣的複雜系統，再牛逼的人也無法考慮到漏洞的方方面面，所以Eric建議放棄打造完美系統的想法，而是通過不斷的試飛，發現問題，確保問題發生時，系統能自動復原即可，而不追求飛行系統的絕對正確和安全。

下面的圖很好的解釋了這個過程：

聽著很耳熟不是嗎？這不就是 持續整合 和敏捷開發嗎？的確就是。

另一方面，這和網際網路公司維護的分散式系統的彈性設計也是一個道理。對於一個分散式系統，我們幾乎永遠不可能找到並修復所有的bug，單元測試覆蓋1000%也沒有用，錯誤流淌在分散式系統的血液裡。解決方法不是消滅這些問題，而是容忍這些問題，在問題發生時，能自動修復，微服務組成的系統，每一個微服務都可能掛掉，這是常態，我們只要有足夠的冗餘和備份即可。即所謂的彈性設計或者叫高可用設計。

第三定律

種瓜得瓜，做獨立自治的子系統減少溝通成本

這是第一定律組織和設計間內在關係的一個具體應用。更直白的說，你想要什麼樣的系統，就搭建什麼樣的團隊。如果你的團隊分成前端團隊，java後臺開發團隊，DBA團隊，運維團隊，你的系統就會長成下面的樣子：

相反，如果你的系統按照業務邊界劃分的，大家按照一個業務目標去把自己的模組做成小系統，小產品的話，你的大系統就會成長成下面的樣子，即微服務的架構

微服務的團隊間應該是??inter-operate, not integrate 。?inter-operate?是定義好系統的邊界和介面，在一個團隊內全棧，讓團隊自治，原因就是因為如果團隊按照這樣的方式組建，將溝通的成本維持在系統內部，每個子系統就會更加內聚，彼此的依賴耦合變弱，跨系統的溝通成本也就能減低。

第四定律

合久必分，分久必合

前面說了，人是複雜的社會動物，人與人的通過非常複雜。但是當我們面對複雜系統時，又往往只能通過增加人力來解決。這時，我們的組織一般是如何解決這個溝通問題的呢？Divide and conquer,分而治之。大家看看自己的公司的組織，是不是一個一線經理一般都是管理15個人以下的？二線經理再管理更少的一線？三線再管理更少的，以此類推。（這裡完全沒有暗示開發經理比程式猿更難管理）

所以，一個大的組織因為溝通成本/管理問題，總為被拆分成一個個小團隊。

總結

以上是位元組二面的一些問題，面完之後其實挺後悔的，沒有提前把各個知識點都複習到位。現在重新好好複習手上的面試大全資料（含JAVA、MySQL、演算法、Redis、JVM、架構、中介軟體、RabbitMQ、設計模式、Spring等），現在起閉關修煉半個月，爭取早日上岸！！！！

下面給大家分享下我的面試大全資料，如果你也有需要，可以戳這裡即可免費領取我的這份複習資料

• 第一份是我的後端JAVA面試大全

後端JAVA面試大全

• 第二份是MySQL+Redis學習筆記+演算法+JVM+JAVA核心知識整理

MySQL+Redis學習筆記演算法+JVM+JAVA核心知識整理

• 第三份是Spring全家桶資料

MySQL+Redis學習筆記演算法+JVM+JAVA核心知識整理