這些著名的軟體開發定律，你都知道哪些？
與其他領域一樣，軟體開發領域也有一些非常有趣的定律。程式設計師、技術經理和架構師們經常在會議和聊天中提到它們。作為小白，我們常常只有點頭附和的份，因為我們不希望讓對方知道我們實際上根本不知道布魯克、摩爾或者維斯都是什麼人。
這些定律包括了一些法則或軟體開發大神的名言。它們都很有趣，值得我們一**竟，而且每個定律背後都有令人驚嘆的背景故事。
墨菲定律（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％滲透率的技術都不會再次翻倍（無論在多少個月內）。
真香定律
別更新了，我學不動了！
……真香。
資料：windy。
Hibernate開發者中好的軟體開發理念
飛快的版本發布。活躍的版本發布。發現使用者真正的需要。回歸測試。綜合性的test suite提高軟體的可維護性和穩定性。把乙個功能做到最好。這條特別支援！要做就一定做到最好。做不到的，扔給其他軟體去做吧。避免過度設計。不要浪費大量的時間和精力進行功能抽象和擴充靈活性。花更多的時間解決使用者面臨的實際...
軟體開發者面試百問
想僱到搞軟體開發的聰明人可不容易。萬一一不小心，就會搞到一堆低能大狒狒。我去年就碰到這種事了。你肯定不想這樣吧。聽我的，沒錯。在樹上開站立會議門都沒有。問點有難度的問題，能幫你把聰明人跟狒狒們分開。我決定把我自己整理出來的軟體開發者面試百問發出來，希望能幫到你們的忙。這個列表涵蓋了軟體工程知識體系中...
敏捷開發實踐（2） 敏捷軟體開發者的習慣
敏捷開發實踐 2 敏捷軟體開發者的習慣 敏捷開發的最小單位就是參與敏捷開發的個人。將這些敏捷開發者聚集起來，就形成了敏捷開發團隊。正如上回介紹的，敏捷開發是一種以人為核心 迭代 循序漸進的開發方法，它以最大可能地發揮團隊的作用為目的。根據需要，隨時改善，以降低軟體開發中的風險。敏捷開發者的態度 敏捷...