軟體開發中有趣的規律
- 2019 年 11 月 14 日
- 筆記
說到軟體工程很多人會想到瀑布模型、敏捷開發、領域驅動。雖然這些名詞大家耳熟能詳，但如果你去聽大牛們的講座或者查閱相關資料會發現每個人陳述的都不大一樣。這讓聽的人很迷惑，為什麼大家講的不一樣但是又都很有道理？
軟體工程這門學科發展不過幾十年，很多概念還在不斷演化，定義也比較模糊。在項目中使用這些方法非常的靈活，比如引入SOA架構，如果完全按照SOA的規範來做不一定適合自己的項目，但是不按規範來做又容易遭到質疑。於是基於SOA修修改改，如果項目結果豐碩，還可以說自己用的是微服務架構。雖然在不同項目中推進軟體工程方法的過程不同，但最終的結果大多是好的。
隨著互聯網的發展，新的軟體工程方法論會層出不窮，未來會有更多新詞出現，但唯一不變的是思維。無論是SOA架構還是微服務架構，都是為了解決軟體工程的根本問題『溝通』，下面聊聊軟體開發中一些和溝通有關的規律。
一. 溝通成本 = n(n-1)/2
記得在《軟體工程》中有一節專門講了 「軟體危機」，說的是軟體開發從小作坊式的開發模式轉向大團隊打造大型項目的過程中暴露出了許多從前沒有注意過的問題，而其中最有代表性的就是著名的「OS/360」項目，這個項目被比作一個焦油坑，整個開發團隊像一隻巨獸在焦油坑中拚命掙扎，然而自己反而越陷越深，無法掙脫。
在這個項目艱難的完成後，負責人Brooks將其中的經驗總結下來寫出了巨著《人月神話》，儘管距離成書的時間已經四五十年，書中熠熠閃光的智慧依然在給我們啟迪，『溝通成本 = n(n-1)/2』公式就是其中之一。
假設計劃做一件事兩個人溝通需要10分鐘，5個人就需要100分鐘。15個人需要1050分鐘，2天左右。50個人需要12250分鐘，25天。隨著公司項目參與的人越來越多，公司如果不引入工程化的方法進行溝通架構改進，僅溝通成本就會拖垮公司。
二. 系統架構等同於組織之內的溝通結構
熟悉微服務的人對『康威定律』肯定不陌生，作為微服務架構的理論基礎，康威定律在最近幾年被推上了神壇。其中最出名的定律就是『系統架構等同於組織之內的溝通結構』。
用過微信和QQ的人能感受到這是一家公司做出來的產品嗎？這兩款產品的功能雖然相近但是體驗感受差異巨大。用過天貓和淘寶的人會覺得這兩款App有差異嗎？這兩款產品提供的服務並不一樣，但用起來感受幾乎差不多。從這幾款App的設計就能看出騰訊和阿里是以一種什麼樣的組織架構在運行。比如騰訊是各個BG自負盈虧，微信和QQ像是兩個完全獨立的公司在運營，更注重細節打磨和產品盈利，所以騰訊的2C業務獨佔鰲頭。阿里各BG之間聯繫緊密，合伙人都需要輪崗，更注重溝通效率和公共服務建設，所以阿里的2B業務做的非常好。
利用康威定律很容易從公司的產品架構分析出系統架構，但康威定律的作用並不是分析公司，而是告訴管理者-要改變系統架構，必須要改變組織的溝通結構。
之前有人做過實驗，同樣一個研發團隊，當辦公位置在一起時寫的程式碼會更耦合，沒有明顯的邊界。當辦公位置分散時寫的程式碼耦合度更低，並且有明顯的邊界和文檔。物理上的距離會增加溝通成本，研發人員為了減少溝通成本無意識的就會更多的使用文檔和介面。合理的利用康威定律，能幫助我們改善程式碼。
三. 軟體的錯誤是無法避免的
Eric Hollnagel是敏捷開發社區的泰斗之一，對於一個巨複雜的系統，我們永遠無法考慮周全，他的解決辦法是「破罐子破摔」。Eric曾經被一家航空公司請去做安全諮詢顧問，複雜保證飛機飛行系統的穩定性和安全性。Eric認為做到安全有兩種方式：
1. 常規的安全指的是儘可能多的發現並消除錯誤的部分，達到絕對安全，這是理想。
2. 彈性安全，即使發生錯誤，只要及時恢復，也能正常工作，這是現實。
對於飛機這樣的複雜系統，再厲害的人也無法考慮到漏洞的方方面面，所以Eric建議放棄打造完美系統的想法，而是通過不斷的試飛，發現問題，確保問題發生時，系統能自動復原即可，而不追求飛行系統的絕對正確和安全。這不就是持續集成和敏捷開發嗎？
微服務架構中最難處理的問題就是"容錯"（下一篇文章會講微服務中最重要的容錯設計），大家對待錯誤的態度已經從不能忍變成了默許。
四. 程式運行時出問題的規律符合墨菲定律
如果上線前聽到 "用戶絕對不會那樣操作"，"這種概率非常低" 往往上線後就會出問題。當時阿波羅登月的程式就有個已知的bug"如果宇航員不小心啟動了P01的預運行程式，會導致原本還在飛行狀態的模擬器瞬間崩潰"。但當時所有人都覺得宇航員受過嚴格訓練，操作是完美的，「絕對不可能出錯」。但可怕的事情還是發生了，宇航員Jim Lovell不小心按下了P01程式，導致導航系統崩潰，如果不能修復飛船將無法返航，人類登月的歷史也將被改寫。最後MIT的一群程式設計師連夜奮戰9個小時才挽救這個bug。
我們無法揣測用戶的想法，也無法對隨機事件做出準確的預判，所以遇到『發生概率極低』的問題一定要及時修復。如果看到這裡請點個喜歡，寫公眾號實在太難了。
