那些你不得(de)不承認的(de)軟件開發定律

　　與其他(tā)領域一樣，軟件開發領域也(yě)有一些非常有趣的(de)定律。程序員(yuán)、技術經理(lǐ)和(hé)架構師們經常在會議(yì)和(hé)聊天中提到它們。作爲小白，我們常常隻有點頭附和(hé)的(de)份，因爲我們不希望讓對(duì)方知道我們實際上根本不知道布魯克、摩爾或者維斯都是什(shén)麽人(rén)。今天我們就一起來(lái)聽(tīng)聽(tīng)那些你不得(de)不承認的(de)軟件開發定律。

　　這(zhè)些定律包括了(le)一些法則或軟件開發大(dà)神的(de)名言。它們都很有趣，值得(de)我們一探究竟，而且每個(gè)定律背後都有令人(rén)驚歎的(de)背景故事。

　　在這(zhè)篇文章(zhāng)中，我将分(fēn)享我對(duì)軟件開發領域最著名和(hé)最常見的(de)軟件開發定律的(de)解釋和(hé)想法。

　　墨菲定律(Murphy's Law)

　　可(kě)能是最著名的(de)定律之一，主要是因爲它不僅适用(yòng)于軟件開發。

　　如果事情可(kě)能出錯，它就會出錯。

　　第一個(gè)推論：那些有效的(de)(代碼)，你可(kě)能反而沒有寫出來(lái)。

　　第二個(gè)推論：詛咒是唯一一門所有程序員(yuán)都能流利說出來(lái)的(de)語言。

　　結論：電腦(nǎo)會按照(zhào)你所寫的(de)(代碼)去做(zuò)，而不是按照(zhào)你所想的(de)去做(zuò)。

　　防禦性編程、版本控制、末日場(chǎng)景(針對(duì)那些該死的(de)僵屍服務器攻擊)、TDD、MDD，等等，這(zhè)些都是針對(duì)這(zhè)一定律的(de)防禦性實踐。

　　布魯克定律(Brook's Law)

　　大(dà)多(duō)數開發人(rén)員(yuán)都有意無意地經曆過布魯克定律，該定律指出：

　　爲已經延期的(de)軟件項目增加人(rén)手隻會讓項目延期得(de)更厲害。

　　如果一個(gè)項目出現了(le)延期，隻是簡單地增加人(rén)手很可(kě)能會帶來(lái)災難性的(de)後果。對(duì)編程效率、軟件開發方法、技術架構等因素進行評審總是會帶來(lái)更好的(de)結果。如果沒有，那說明(míng)霍夫施塔特定律也(yě)在起作用(yòng)。

　　霍夫施塔特定律(Hofstadter's Law)

　　霍夫施塔特定律由 Douglas Hofstadter 提出，并以他(tā)的(de)名字命名。

　　當然，不要将這(zhè)個(gè)定律與電視劇《大(dà)爆炸》裏的(de) Leonard Hofstadter 混淆起來(lái)了(le)，盡管他(tā)說的(de)一些話(huà)對(duì)某些人(rén)來(lái)說是有一點意義的(de)。

　　這(zhè)個(gè)定律指出：

　　即使你考慮到了(le)霍夫施塔特定律，項目的(de)實際完成時(shí)間總是比預期的(de)要長(cháng)。

　　這(zhè)個(gè)“定律”是關于準确預估完成複雜(zá)任務所需時(shí)間的(de)難度。這(zhè)個(gè)定律具有遞歸性，反映了(le)預估複雜(zá)項目的(de)難度，盡管你可(kě)能已經做(zuò)出了(le)最大(dà)的(de)努力，而且也(yě)知道任務的(de)複雜(zá)性。

　　這(zhè)就是爲什(shén)麽在進行項目預估時(shí)必須要有一個(gè)緩沖區(qū)。

　　康威定律(Conway’s Law)

　　軟件的(de)結構反映了(le)開發軟件的(de)組織的(de)結構。

　　或者說得(de)更清楚一點：

　　組織所設計的(de)系統的(de)結構受限于組織的(de)通(tōng)信結構。

　　很多(duō)組織是根據功能性技能來(lái)劃分(fēn)團隊的(de)，所以會有前端開發團隊、後端開發團隊和(hé)數據庫開發團隊。簡單地說，如果某人(rén)想要改變的(de)東西屬于其他(tā)人(rén)，那麽他(tā)就很難改變這(zhè)些東西。

　　現在越來(lái)越多(duō)的(de)組織根據有界上下(xià)文來(lái)組建團隊，而微服務等架構也(yě)在根據服務邊界而不是孤立的(de)技術架構分(fēn)區(qū)來(lái)組建團隊。

　　因此，根據目标軟件架構來(lái)組建團隊可(kě)以更容易實現軟件架構，而這(zhè)就是對(duì)抗康威法律的(de)一種有效方式。

　　波斯托定律(Postel's Law)或魯棒性法則

　　保守輸出，自由輸入。

　　Jon Postel 最初将它作爲實現健壯的(de) TCP 的(de)一個(gè)原則。這(zhè)個(gè)原則也(yě)體現在 HTML 中，HTML 的(de)成敗可(kě)以歸因于它的(de)很多(duō)屬性，但究竟 HTML 是成功的(de)還(hái)是失敗的(de)，不同的(de)人(rén)有不同的(de)看法。

　　帕累托法則(Pareto Principle)或 80/20 法則

　　對(duì)于很多(duō)現象，80%的(de)後果源于 20%的(de)原因。

　　80%的(de) bug 來(lái)自 20%的(de)代碼，這(zhè)個(gè)說的(de)就是帕累托法則。

　　還(hái)有人(rén)說，公司裏 80%的(de)工作是由 20%的(de)員(yuán)工完成的(de)，問題是你并不清楚是哪 20%員(yuán)工。

　　彼得(de)法則(The Peter Principle)

　　這(zhè)是一個(gè)相當令人(rén)沮喪的(de)定律，特别是如果你碰巧親身經曆過。

　　在一個(gè)等級制度中，每個(gè)員(yuán)工都傾向于晉升到他(tā)無法勝任的(de)職位。

　　呆伯特(Dilbert)系列漫畫(huà)中有一些這(zhè)方面的(de)例子。

　　基爾霍夫法則(Kerchkhoff's Principle)

　　在密碼學中，系統應該是安全的(de)，即使系統的(de)所有東西都是公開的(de)——除了(le)一小部分(fēn)信息——秘鑰。

　　這(zhè)是公鑰密碼學的(de)主要法則。

　　萊納斯定律(Linus's Law)

　　這(zhè)是以 Linux 之父 Linus Torvalds 的(de)名字命名的(de)，該定律指出：

　　如果有足夠多(duō)的(de)眼睛，所有的(de) bug 都将無所遁形。

　　可(kě)以使用(yòng)著名的(de)《大(dà)教堂與集市》來(lái)描述這(zhè)個(gè)定律，它解釋了(le)兩種不同的(de)自由軟件開發模型之間的(de)對(duì)比：

　　大(dà)教堂模型——每個(gè)軟件發行版都提供源代碼，但發行版之間的(de)代碼開發僅限于一組專有的(de)軟件開發人(rén)員(yuán)。

　　集市模型——代碼開發通(tōng)過互聯網公開進行。

　　結論?對(duì)源代碼進行更廣泛的(de)公開測試、評審和(hé)實驗，就會更快(kuài)地發現各種形式的(de) bug。

　　摩爾定律(Moore's Law)

　　單位成本的(de)計算(suàn)機算(suàn)力每 24 個(gè)月(yuè)翻一番。

　　最流行的(de)版本是說：

　　集成電路上的(de)晶體管數量大(dà)約每 18 個(gè)月(yuè)會增加一倍。

　　或者：

　　計算(suàn)機的(de)處理(lǐ)速度每兩年翻一番!

　　沃斯定律(Wirth's Law)

　　軟件比硬件更容易變慢(màn)。

　　參考一下(xià)摩爾定律吧!

　　九九法則(Ninety-Ninety Rule)

　　前 90%的(de)代碼占用(yòng)了(le) 10%的(de)時(shí)間，其餘的(de) 10%代碼占用(yòng)了(le)剩下(xià)的(de) 90%時(shí)間。

　　有人(rén)不同意這(zhè)個(gè)的(de)嗎?

　　克努特優化(huà)法則(Knuth's Optimization Principle)

　　過早優化(huà)是萬惡之源。

　　先寫代碼，然後找出瓶頸，最後才修複!

　　諾維格定律(Norvig's Law)

　　任何超過 50%滲透率的(de)技術都不會再次翻倍(無論在多(duō)少個(gè)月(yuè)内)。

　　真香定律

　　别更新了(le)，我學不動了(le)!……真香。

　　所有程序員(yuán)都逃不過的(de)定律，同意嗎?

　　以上軟件開發定律，你都知道幾條?