說到軟件工程很多人都會想到瀑布模型、敏捷開發(fā)、領(lǐng)域驅(qū)動优炬。雖然這些名詞大家耳熟能詳颁井，但如果你去聽大牛們的講座或者查閱相關(guān)資料會發(fā)現(xiàn)每個人陳述的都不大一樣。這讓聽的人很迷惑蠢护，為什么大家講的不一樣但是又都很有道理雅宾？
軟件工程這門學科發(fā)展不過幾十年，很多概念還在不斷演化糊余，定義也比較模糊秀又。在項目中使用這些方法非常的靈活单寂，比如引入SOA架構(gòu)贬芥，如果完全按照SOA的規(guī)范來做不一定適合自己的項目，但是不按規(guī)范來做又容易遭到質(zhì)疑宣决。于是基于SOA修修改改蘸劈，如果項目結(jié)果豐碩，還可以說自己用的是微服務(wù)架構(gòu)尊沸。雖然在不同項目中推進軟件工程方法的過程不同威沫，但最終的結(jié)果大多是好的。
隨著互聯(lián)網(wǎng)的發(fā)展洼专，新的軟件工程方法論會層出不窮棒掠，未來會出現(xiàn)更多新詞，但唯一不變的是思維屁商。無論是SOA架構(gòu)還是微服務(wù)架構(gòu)烟很，都是為了解決軟件工程的根本問題『溝通』，下面聊聊軟件開發(fā)中一些有意思的規(guī)律蜡镶。
一. 溝通成本 = n(n-1)/2
記得在《軟件工程》中有一節(jié)專門講了 “軟件危機”雾袱，說的是軟件開發(fā)從小作坊式的開發(fā)模式轉(zhuǎn)向大團隊打造大型項目的過程中暴露出了許多從前沒有注意過的問題，而其中最有代表性的就是著名的“OS/360”項目官还，這個項目被比作一個焦油坑芹橡，整個開發(fā)團隊像一只巨獸在焦油坑中拼命掙扎，然而自己反而越陷越深望伦，無法掙脫林说。
在這個項目艱難的完成后，負責人Brooks將其中的經(jīng)驗總結(jié)下來寫出了巨著《人月神話》屯伞，盡管距離成書的時間已經(jīng)四五十年腿箩，書中熠熠閃光的智慧依然在給我們啟迪，『溝通成本 = n(n-1)/2』公式就是其中之一愕掏。
假設(shè)計劃做一件事兩個人溝通需要10分鐘度秘，5個人就需要100分鐘。15個人需要1050分鐘，2天左右剑梳。50個人需要12250分鐘唆貌，25天。隨著公司項目參與的人越來越多垢乙，公司如果不引入工程化的方法進行溝通架構(gòu)改進锨咙，單單溝通成本就會拖垮公司。
二. 系統(tǒng)架構(gòu)等同于組織之內(nèi)的溝通結(jié)構(gòu)
熟悉微服務(wù)的人對『康威定律』肯定不陌生追逮，作為微服務(wù)架構(gòu)的理論基礎(chǔ)酪刀，康偉定律在最近幾年被推上了神壇。其中最出名的定律就是『系統(tǒng)架構(gòu)等同于組織之內(nèi)的溝通結(jié)構(gòu)』钮孵。
用過微信和QQ的人能感受到這是一家公司做出來的產(chǎn)品嗎骂倘？這兩款產(chǎn)品的功能雖然相近但是體驗感受差異巨大。用過天貓和淘寶的人會覺得這兩款A(yù)pp有差異嗎巴席？這兩款產(chǎn)品提供的服務(wù)并不一樣历涝，但用起來體驗感受都差不多。從這幾款A(yù)pp的設(shè)計就能看出騰訊和阿里是以一種什么樣的組織架構(gòu)在運行漾唉。比如騰訊是各BG自負盈虧荧库，微信和QQ像是兩個完全獨立的公司在運營，更注重細節(jié)打磨和產(chǎn)品盈利赵刑，所以騰訊的2C業(yè)務(wù)獨占鰲頭分衫。阿里各BG之間聯(lián)系緊密，合伙人都需要輪崗般此，更注重溝通效率和公共服務(wù)建設(shè)蚪战，所以阿里的2B業(yè)務(wù)做的非常好。
利用康威定律很容易從公司的產(chǎn)品架構(gòu)分析出系統(tǒng)架構(gòu)恤煞，但康威定律的作用并不是分析公司屎勘，而是告訴管理者-要改變系統(tǒng)架構(gòu)，必須要改變組織的溝通結(jié)構(gòu)居扒。
之前有人做過實驗概漱，同樣一個研發(fā)團隊，當辦公位置在一起時寫的代碼會更耦合喜喂，沒有明顯的邊界瓤摧。當辦公位置分散時寫的代碼耦合度更低，并且有明顯的邊界和文檔玉吁。物理上的距離會增加溝通成本照弥，研發(fā)人員為了減少溝通成本無意識的就會更多的使用文檔和接口。合理的利用康威定律进副，能幫助我們改善代碼这揣。
三. 軟件的錯誤是無法避免的
Eric Hollnagel是敏捷開發(fā)社區(qū)的泰斗之一悔常，對于一個巨復雜的系統(tǒng)，我們永遠無法考慮周全给赞，他的解決辦法是“破罐子破摔”机打。Eric曾經(jīng)被一家航空公司請去做安全咨詢顧問，復雜保證飛機飛行系統(tǒng)的穩(wěn)定性和安全性片迅。Eric認為做到安全有兩種方式：
- 常規(guī)的安全指的是盡可能多的發(fā)現(xiàn)并消除錯誤的部分残邀，達到絕對安全，這是理想柑蛇。
- 彈性安全芥挣，即使發(fā)生錯誤，只要及時恢復耻台，也能正常工作空免，這是現(xiàn)實。
對于飛機這樣的復雜系統(tǒng)粘我，再厲害的人也無法考慮到漏洞的方方面面鼓蜒，所以Eric建議放棄打造完美系統(tǒng)的想法，而是通過不斷的試飛征字，發(fā)現(xiàn)問題，確保問題發(fā)生時娇豫，系統(tǒng)能自動復原即可匙姜，而不追求飛行系統(tǒng)的絕對正確和安全。這不就是持續(xù)集成和敏捷開發(fā)嗎冯痢？
微服務(wù)架構(gòu)中最難處理的問題就是"容錯"（下一篇文章會講微服務(wù)中最重要的容錯設(shè)計）氮昧，大家對待錯誤的態(tài)度已經(jīng)從不能忍變成了默許。
四. 程序運行時出問題的規(guī)律符合墨菲定律
如果聽到 "用戶絕對不會那樣操作"浦楣，"這種概率非常低" 往往上線就會出問題袖肥。當時阿波羅登月的程序就有個已知的問題"如果宇航員不小心啟動了P01的預(yù)運行程序，會導致原本還在飛行狀態(tài)的模擬器瞬間崩潰"振劳。但當時所有人都覺得宇航員受過嚴格訓練椎组，操作是完美的，“絕對不可能出錯”历恐。但可怕的事情還是發(fā)生了寸癌，宇航員Jim Lovell不小心按下了P01程序，導致導航系統(tǒng)崩潰弱贼，如果不能修復飛船將無法返航蒸苇，人類登月的歷史也將被改寫。最后MIT的一群程序員連夜奮戰(zhàn)9個小時才挽救這個bug吮旅。
我們無法揣測用戶的想法溪烤，也無法對隨機事件做出準確的預(yù)判，所以遇到『發(fā)生概率極低』的問題也一定要及時修復。
