统治软件开发中的著名定律
文|?https://www.timsommer.be/famous-laws-of-software-development/
翻譯| 碼農(nóng)翻身
和其他領(lǐng)域一樣，在軟件開發(fā)的世界中也有一些有趣而著名的定律，開發(fā)人員、管理人員還是架構(gòu)師，都經(jīng)常在會議或閑談中提到他們，很多時候我們都只是點頭附和，免得讓人知道自己其實根本沒聽說過布魯克斯(Brooks)、摩爾(Moore)或康威(Conway)這些大佬。
在這里，我把這些定律整理出來，分享給大家。
墨菲定律 (Murphy's Law)
或許是所有的定律中最廣為人知的，因為它不僅僅適用于軟件開發(fā)領(lǐng)域。
凡是可能出錯的事就一定會出錯。
衍生定律：說臟話是唯一一門程序員用得都很流暢的語言。
推論：計算機會按照你寫出來的方式運行，而不是你臆想出來的。
防御性編程、版本控制、測試驅(qū)動開發(fā)、模型驅(qū)動開發(fā)等等都是預(yù)防墨菲定律很好的做法。
布魯克斯法則(Brook's Law)
大多數(shù)開發(fā)人員都會經(jīng)歷過布魯克斯定律：
向一個延期的項目增加人手只會讓它延期得更加厲害
如果一個項目進展落后了，僅僅增加人力很有可能會帶來災(zāi)難性的后果。
相反，提高編程效率、審查軟件開發(fā)方法和技術(shù)架構(gòu)是否合理，幾乎總是會比增加人力帶來更好的效果。如果沒有，這可能意味著霍夫施塔特定律在起作用。
霍夫斯塔特定律 (Hofstadter's Law)
霍夫斯塔特定律是由道格拉· 霍夫斯塔特(Douglas Hofstadter) 提出，并且以他的名字來命名的。
不要將這個定律與《生活大爆炸》中的倫納德·霍夫斯塔特混為一談。即使他的話對你們一些人或許有用。
這個定律是這么說的：
事情總是要花費比你預(yù)想更長的時間，即使你把霍夫斯塔特定律也考慮在內(nèi)。
這條定律的遞歸性反映出，即使付出最大的努力，也知道任務(wù)是復(fù)雜的，去精確地估算它依然是非常難的，所以要給估算留一個緩沖區(qū)出來。?
康威定律 (Conway's Law)
軟件的任何一部分都反應(yīng)了創(chuàng)建它的組織結(jié)構(gòu)
或者更清楚一點：
組織形式等同其設(shè)計的系統(tǒng)架構(gòu)
許多組織都根據(jù)他們的技能來劃分團隊。因此會有前端開發(fā)、后端開發(fā)和數(shù)據(jù)庫開發(fā)組成的團隊。這會導(dǎo)致某人想要修改一個不屬于自己領(lǐng)域的東西會很難。
最好是按照有邊界的上下文(bounded context)來規(guī)劃團隊，并且越來越多的組織者也正在這么做。像微服務(wù)這樣的架構(gòu)圍繞服務(wù)邊界而不是孤立的技術(shù)體系劃分來組織他們的團隊。
康威定律帶來的具體的實踐建議就是：你想要什么樣的系統(tǒng)設(shè)計，就架構(gòu)什么樣的團隊，這會帶來事半功倍的效果。
伯斯塔爾定律(Postel's Law)
又稱健壯性法則(Robustness principle)
發(fā)送時要保守，接收時要大方
Jon Postel 最初認為正是這個原則讓TCP協(xié)議的實現(xiàn)很健壯。一些人認為這正是 HTML 很成功的原因，也有一些人認為這正是 HTML 很失敗的原因。（因為HTML可以寫得不那么嚴格，但是瀏覽器依然可以解析它）
帕累托法則 (Pareto Principle)
又稱80/20法則(The 80-20 rule)
對于許多現(xiàn)象來說，有 80% 的后果都是 20% 的原因造成的。
在軟件開發(fā)中的體現(xiàn)是：?代碼中80%的錯誤都是由代碼中的20%引起的。
另外，公司80%的工作是由20%的員工完成的。問題是你并不總是清楚誰是那20%。
彼得原則(The Peter Principle)
該原則還是比較打擊人的，特別是你碰巧正在經(jīng)歷的話。
在等級制度中，每個員工都傾向于提升到他無法勝任的等級
在各種組織中，由于習(xí)慣于對在某個等級上稱職的人員進行晉升提拔，因而雇員總是趨向于被晉升到其不稱職的地位。
一旦組織中的相當部分人員被推到了其不稱職的級別，就會造成組織的人浮于事，效率低下，導(dǎo)致平庸者出人頭地，發(fā)展停滯。
柯克霍夫原則(Kerchkhoff's Principle)
在密碼學(xué)中，即使一個系統(tǒng)中的所有東西都是公開的（密鑰除外），該系統(tǒng)也應(yīng)當是安全的。
這就是非對稱加密的主要原則。
林納斯定律 (Linus's Law)
以Linux之父林納斯·托瓦茲（Linus Torvalds）的名字命名，該定律表述為：
眾目睽睽之下，一切 bug 都無所遁形
這個定律出自著名的文集《大教堂與集市》，這個文集對比了兩種不同的開源軟件開發(fā)模型。
-
大教堂模型，每個軟件發(fā)行版都伴有源代碼，但是僅限于軟件開發(fā)人員查看。
-
集市模型，以互聯(lián)網(wǎng)為媒介，代碼開發(fā)的過程完全暴露在大眾的視野下。
被公開審查、測試的代碼越多，各種形式的錯誤就能更快地被發(fā)現(xiàn)。
摩爾定律 (Moore's Law)
每一美元所能買到的電腦性能，將每隔24個月翻一番。
最流行的版本是：
集成電路上可容納的元器件的數(shù)目，約每隔18個月便會增加一倍。
或
計算機的處理性能每隔兩年翻一倍。
90-90法則 (Ninety-ninety rule)
前90%的代碼要花費90%的開發(fā)時間，剩余的10%的代碼要再花費90%的開發(fā)時間。
如此真實。還會有人不同意嗎？
克努特優(yōu)化原則 (Knuth's optimization principle)
不成熟的優(yōu)化是萬惡之源。
先把代碼寫出來，定位瓶頸所在，然后優(yōu)化它。
諾維格定律 (Norvig's Law)
當公司的市場份額超過50%之后，就不能再翻番了。
在一個市場占主導(dǎo)地位的公司必須不斷開拓新財源，才能長盛不衰。
寫在最后
這就是我喜歡的“定律”， 他們都有自己的故事和背景。作為軟件開發(fā)人員你必須熟悉他們。
你也許會贊同或不贊同某條定律，或在其中任何一條有過有趣的經(jīng)歷，歡迎在下方留言討論！
總結(jié)
以上是生活随笔為你收集整理的统治软件开发中的著名定律的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 「面试题」介绍你做过最复杂的系统
- 下一篇： Java程序员必须掌握的常用Linux命