文|和其他領域一樣，在軟體開發的世界中也有一些有趣而著名的定律，開發人員、管理人員還是架構師，都經常在會議或閒談中提到他們，很多時候我們都只是點頭附和，免得讓人知道自己其實根本沒聽說過布魯克斯(brooks)、摩爾(moore)或康威(conway)這些大佬。翻譯| 碼農翻身
或許是所有的定律中最廣為人知的，因為它不僅僅適用於軟體開發領域。
凡是可能出錯的事就一定會出錯。衍生定律：說髒話是唯一一門程式設計師用得都很流暢的語言。
推論：計算機會按照你寫出來的方式執行，而不是你臆想出來的。
防禦性程式設計、版本控制、測試驅動開發、模型驅動開發等等都是預防墨菲定律很好的做法。
大多數開發人員都會經歷過布魯克斯定律：
向乙個延期的專案增加人手只會讓它延期得更加厲害如果乙個專案進展落後了，僅僅增加人力很有可能會帶來災難性的後果。
相反，提高程式設計效率、審查軟體開發方法和技術架構是否合理，幾乎總是會比增加人力帶來更好的效果。如果沒有，這可能意味著霍夫施塔特定律在起作用。
霍夫斯塔特定律是由道格拉· 霍夫斯塔特(douglas hofstadter) 提出，並且以他的名字來命名的。
不要將這個定律與《生活大**》中的倫納德·霍夫斯塔特混為一談。即使他的話對你們一些人或許有用。
這個定律是這麼說的：
事情總是要花費比你預想更長的時間，即使你把霍夫斯塔特定律也考慮在內。這條定律的遞迴性反映出，即使付出最大的努力，也知道任務是複雜的，去精確地估算它依然是非常難的，所以要給估算留乙個緩衝區出來。
軟體的任何一部分都反應了建立它的組織結構或者更清楚一點：
組織形式等同其設計的系統架構
許多組織都根據他們的技能來劃分團隊。因此會有前端開發、後端開發和資料庫開發組成的團隊。這會導致某人想要修改乙個不屬於自己領域的東西會很難。
最好是按照有邊界的上下文(bounded context)來規劃團隊，並且越來越多的組織者也正在這麼做。像微服務這樣的架構圍繞服務邊界而不是孤立的技術體系劃分來組織他們的團隊。
康威定律帶來的具體的實踐建議就是：你想要什麼樣的系統設計，就架構什麼樣的團隊，這會帶來事半功倍的效果。
又稱健壯性法則(robustness principle)
傳送時要保守，接收時要大方jon postel 最初認為正是這個原則讓tcp協議的實現很健壯。一些人認為這正是 html 很成功的原因，也有一些人認為這正是 html 很失敗的原因。（因為html可以寫得不那麼嚴格，但是瀏覽器依然可以解析它）
又稱80/20法則(the 80-20 rule)
對於許多現象來說，有 80% 的後果都是 20% 的原因造成的。
在軟體開發中的體現是： **中80%的錯誤都是由**中的20%引起的。
另外，公司80%的工作是由20%的員工完成的。問題是你並不總是清楚誰是那20%。
該原則還是比較打擊人的，特別是你碰巧正在經歷的話。
在等級制度中，每個員工都傾向於提公升到他無法勝任的等級在各種組織中，由於習慣於對在某個等級上稱職的人員進行晉公升提拔，因而雇員總是趨向於被晉公升到其不稱職的地位。
一旦組織中的相當部分人員被推到了其不稱職的級別，就會造成組織的人浮於事，效率低下，導致平庸者出人頭地，發展停滯。
在密碼學中，即使乙個系統中的所有東西都是公開的（金鑰除外），該系統也應當是安全的。這就是非對稱加密的主要原則。
以linux之父林納斯·托瓦茲（linus torvalds）的名字命名，該定律表述為：
眾目睽睽之下，一切 bug 都無所遁形這個定律出自著名的文集《大教堂與集市》，這個文集對比了兩種不同的開源軟體開發模型。
被公開審查、測試的**越多，各種形式的錯誤就能更快地被發現。
每一美元所能買到的電腦效能，將每隔24個月翻一番。最流行的版本是：
積體電路上可容納的元器件的數目，約每隔18個月便會增加一倍。或
計算機的處理效能每隔兩年翻一倍。前90%的**要花費90%的開發時間，剩餘的10%的**要再花費90%的開發時間。如此真實。還會有人不同意嗎？不成熟的優化是萬惡之源。先把**寫出來，定位瓶頸所在，然後優化它。當公司的市場份額超過50%之後，就不能再翻番了。在乙個市場佔主導地位的公司必須不斷開拓新財源，才能長盛不衰。這就是我喜歡的「定律」， 他們都有自己的故事和背景。作為軟體開發人員你必須熟悉他們。
15條軟體開發黃金定律
與其他領域一樣，軟體開發領域也有一些非常有趣的定律。程式設計師 技術經理和架構師們經常在會議和聊天中提到它們。作為小白，我們常常只有點頭附和的份，因為我們不希望讓對方知道我們實際上根本不知道布魯克 摩爾或者維斯都是什麼人。這些定律包括了一些法則或軟體開發大神的名言。它們都很有趣，值得我們一 竟，而且...
15條軟體開發黃金定律
與其他領域一樣，軟體開發領域也有一些非常有趣的定律。程式設計師 技術經理和架構師們經常在會議和聊天中提到它們。作為小白，我們常常只有點頭附和的份，因為我們不希望讓對方知道我們實際上根本不知道布魯克 摩爾或者維斯都是什麼人。這些定律包括了一些法則或軟體開發大神的名言。它們都很有趣，值得我們一 竟，而且...
15條軟體開發黃金定律
與其他領域一樣，軟體開發領域也有一些非常有趣的定律。程式設計師 技術經理和架構師們經常在會議和聊天中提到它們。作為小白，我們常常只有點頭附和的份，因為我們不希望讓對方知道我們實際上根本不知道布魯克 摩爾或者維斯都是什麼人。這些定律包括了一些法則或軟體開發大神的名言。它們都很有趣，值得我們一 竟，而且...