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