程序員都認(rèn)不全的軟件開發(fā)定律
與其他領(lǐng)域一樣，軟件開發(fā)領(lǐng)域也有一些非常有趣的定律。程序員、技術(shù)經(jīng)理和架構(gòu)師們經(jīng)常在會議和聊天中提到它們。作為小白，我們常常只有點頭附和的份，因為我們不希望讓對方知道我們實際上根本不知道布魯克、摩爾或者維斯都是什么人。
這些定律包括了一些法則或軟件開發(fā)大神的名言。它們都很有趣，值得我們一探究竟，而且每個定律背后都有令人驚嘆的背景故事。
在這篇文章中，我將分享我對軟件開發(fā)領(lǐng)域最著名和最常見的定律的解釋和想法。
墨菲定律（Murphy's Law）
可能是最著名的定律之一，主要是因為它不僅適用于軟件開發(fā)。
如果事情可能出錯，它就會出錯。
第一個推論：那些有效的（代碼），你可能反而沒有寫出來。
第二個推論：詛咒是唯一一門所有程序員都能流利說出來的語言。
結(jié)論：電腦會按照你所寫的（代碼）去做，而不是按照你所想的去做。
防御性編程、版本控制、末日場景（針對那些該死的僵尸服務(wù)器攻擊）、TDD、MDD，等等，這些都是針對這一定律的防御性實踐。
布魯克定律（Brook's Law）
大多數(shù)開發(fā)人員都有意無意地經(jīng)歷過布魯克定律，該定律指出：
為已經(jīng)延期的軟件項目增加人手只會讓項目延期得更厲害。
如果一個項目出現(xiàn)了延期，只是簡單地增加人手很可能會帶來災(zāi)難性的后果。對編程效率、軟件開發(fā)方法、技術(shù)架構(gòu)等因素進行評審總是會帶來更好的結(jié)果。如果沒有，那說明霍夫施塔特定律也在起作用。
霍夫施塔特定律（Hofstadter's Law）
霍夫施塔特定律由 Douglas Hofstadter 提出，并以他的名字命名。
當(dāng)然，不要將這個定律與電視劇《大爆炸》里的 Leonard Hofstadter 混淆起來了，盡管他說的一些話對某些人來說是有一點意義的。
這個定律指出：
即使你考慮到了霍夫施塔特定律，項目的實際完成時間總是比預(yù)期的要長。
這個“定律”是關(guān)于準(zhǔn)確預(yù)估完成復(fù)雜任務(wù)所需時間的難度。這個定律具有遞歸性，反映了預(yù)估復(fù)雜項目的難度，盡管你可能已經(jīng)做出了最大的努力，而且也知道任務(wù)的復(fù)雜性。
這就是為什么在進行項目預(yù)估時必須要有一個緩沖區(qū)。
康威定律（Conway’s Law）
軟件的結(jié)構(gòu)反映了開發(fā)軟件的組織的結(jié)構(gòu)。
或者說得更清楚一點：
組織所設(shè)計的系統(tǒng)的結(jié)構(gòu)受限于組織的通信結(jié)構(gòu)。
很多組織是根據(jù)功能性技能來劃分團隊的，所以會有前端開發(fā)團隊、后端開發(fā)團隊和數(shù)據(jù)庫開發(fā)團隊。簡單地說，如果某人想要改變的東西屬于其他人，那么他就很難改變這些東西。
現(xiàn)在越來越多的組織根據(jù)有界上下文來組建團隊，而微服務(wù)等架構(gòu)也在根據(jù)服務(wù)邊界而不是孤立的技術(shù)架構(gòu)分區(qū)來組建團隊。
因此，根據(jù)目標(biāo)軟件架構(gòu)來組建團隊可以更容易實現(xiàn)軟件架構(gòu)，而這就是對抗康威法律的一種有效方式。
波斯托定律（Postel's Law）或魯棒性法則
保守輸出，自由輸入。
Jon Postel 最初將它作為實現(xiàn)健壯的 TCP 的一個原則。這個原則也體現(xiàn)在 HTML 中，HTML 的成敗可以歸因于它的很多屬性，但究竟 HTML 是成功的還是失敗的，不同的人有不同的看法。
帕累托法則（Pareto Principle）或 80/20 法則
對于很多現(xiàn)象，80％的后果源于 20％的原因。
80％的 bug 來自 20％的代碼，這個說的就是帕累托法則。
還有人說，公司里 80％的工作是由 20％的員工完成的，問題是你并不清楚是哪 20％員工。
彼得法則（The Peter Principle）
這是一個相當(dāng)令人沮喪的定律，特別是如果你碰巧親身經(jīng)歷過。
在一個等級制度中，每個員工都傾向于晉升到他無法勝任的職位。
呆伯特（Dilbert）系列漫畫中有一些這方面的例子。
基爾霍夫法則（Kerchkhoff's Principle）
在密碼學(xué)中，系統(tǒng)應(yīng)該是安全的，即使系統(tǒng)的所有東西都是公開的——除了一小部分信息——秘鑰。
這是公鑰密碼學(xué)的主要法則。
萊納斯定律（Linus's Law）
這是以 Linux 之父 Linus Torvalds 的名字命名的，該定律指出：
如果有足夠多的眼睛，所有的 bug 都將無所遁形。
可以使用著名的《大教堂與集市》來描述這個定律，它解釋了兩種不同的自由軟件開發(fā)模型之間的對比：
大教堂模型——每個軟件發(fā)行版都提供源代碼，但發(fā)行版之間的代碼開發(fā)僅限于一組專有的軟件開發(fā)人員。
集市模型——代碼開發(fā)通過互聯(lián)網(wǎng)公開進行。
結(jié)論？對源代碼進行更廣泛的公開測試、評審和實驗，就會更快地發(fā)現(xiàn)各種形式的 bug。
摩爾定律（Moore's Law）
單位成本的計算機算力每 24 個月翻一番。
最流行的版本是說：
集成電路上的晶體管數(shù)量大約每 18 個月會增加一倍。
或者：
計算機的處理速度每兩年翻一番！
沃斯定律（Wirth's Law）
軟件比硬件更容易變慢。
參考一下摩爾定律吧！
九九法則（Ninety-Ninety Rule）
前 90％的代碼占用了 10％的時間，其余的 10％代碼占用了剩下的 90％時間。
有人不同意這個的嗎？
克努特優(yōu)化法則（Knuth's Optimization Principle）
過早優(yōu)化是萬惡之源。
先寫代碼，然后找出瓶頸，最后才修復(fù)！
諾維格定律（Norvig's Law）
任何超過 50％滲透率的技術(shù)都不會再次翻倍（無論在多少個月內(nèi)）。
