軟體開發帶來了相當多的範例、模式和原則。 其中許多以軟體開發法則的形式出現。
一些軟體開發法則只涉及了編碼實踐。 而另外一些則提供了針對對產品設計和開發的更廣泛方面的見解。 更有些法則超越了這些邊界，同樣是適用於我們所知道的生活的模式。
在這裡我將介紹一些非常重要的軟體開發原則和定律。
1、布魯克斯法則（Brooks』 law）
Adding manpower to a late project makes it later.
為一個延期的項目增加人力會只會使這個項目更晚。
布魯克斯法則來自弗雷德~布魯克斯1975年出版的《人月神話》一書。這涉及到一個假設，即團隊成員和所需月份是可以互換的。
但事實並非如此，特別是在軟體開發中（或任何產品開發中，都是如此）。為什麼？因為需要花時間讓添加的人力了解並跟上項目的進度。
2、康威定律（Conway’s law）
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
任何組織在設計一個系統（廣義的定義）時，都會產生一個設計，其結構是該組織的溝通結構的複製。
Melvin Conway在1967年闡述了這一軟體開發的規律。康威定律與產品設計有關，他觀察到組織溝通結構對軟體輸出的影響。
因此，一個協作緊密的團隊會創建具有相互交織的功能和代碼的軟體。 同時，一個更輕鬆、更分散的團隊會創建更多模塊化的軟體。
3、墨菲定律（Murphy’s law）
Anything that can go wrong will go wrong.
凡是可能出錯的事必定會出錯。
這是本清單中最著名的、最普遍適用的定律。墨菲定律在項目管理、軟體開發和一般生活的各個領域都能看到。
在軟體開發中，墨菲定律強調了一個關鍵點：計算機只能做你告訴（tell）它們做的事情，而不能做你想要（want）他們做的事情。
4、侯世達定律（Hofstadter’s law）
It always takes longer than you expect, even when you take into account Hofstadter's Law.
它總是比你預期的時間要長，即使你考慮到了侯世達定律。
「這個東西要花多長時間完成？」是軟體開發中最可怕的問題之一。侯世達定律提供了原因。它還與另一個定律有關：帕金森定律，該定律認為，在工作能夠完成的時限內，工作量會一直增加，直到所有可用時間都被填滿為止。
侯世達定律和帕金森定律都說明，幾乎不可能對工作完成的時間做出精確的估計。
5、林納斯定律（Linus』 law）
Given enough eyeballs, all bugs are shallow.
足夠多的眼睛，就可讓所有問題浮現。
只要有足夠的測試人員及開發人員，所有問題都會在很短時間內被發現，而且能夠很容易被解決。
Linus提醒了開發中的團隊合作的重要價值。通常，在解決問題時，兩個人的腦袋比一個人的好。
6、古德哈特定律（Goodhart’s law）
When a measure becomes a target, it ceases to be a good measure.
當一個指標成為目標時，它就不再是一個好的指標。
古德哈特定律在軟體開發中的一個例子就是代碼行數。代碼行數提供了一種衡量軟體產品規模的指標。但是，如果被當作目標時，代碼質量就會下降。
本應需要精煉或刪除的代碼行，卻被加了進去，形成混亂的義大利麵條式代碼。
其它的例子諸如：功能完成數量、bug數量等等。
7、蓋爾定律（Gall’s law）
A complex system that works has evolved from a simple system that worked. A complex system built from scratch won’t work.
一個能工作的複雜系統是從一個能工作的簡單系統演變而來的。一個從頭開始建立的複雜系統是不會工作。
我們在許多複雜系統的生命周期中看到了這一點，例如，生命本身從簡單的單細胞生物體開始。軟體開發也不例外。
蓋爾定律，是一個很好的理由，讓我們以最小可行產品（MVP）來進行新的軟體產品的開發。當我們創建一個新的軟體產品時，我們應該從一些簡單的、有效的東西開始，然後會漸漸演變成一個更複雜的解決方案。
8、扎溫斯基定律（Zawinski’s Law）
Every program attempts to expand until it can read mail. Those programs which cannot expand are replaced by ones that can.
每個程序都試圖擴張，直到它可以讀取郵件。那些不能擴張的程序會被能擴張的程序所取代。
說到複雜性，扎溫斯基定律表明，產品一旦建成，就會繼續擴張。它們會增加更多的功能區域，直到它們無法再擴張。扎溫斯基定律，通常用來對臃腫軟體的批評。
功能蠕變（feature creep）的例子說明了軟體開發中的扎溫斯基定律。臃腫的程序很快就會被放棄，轉而選擇更精簡的方案。
9、伊格爾森定律（Eagleson’s law）
Any code of your own that you haven’t looked at for six or more months might as well have been written by someone else.
你自己的任何代碼，如果你有6個月或更長時間沒有看，就好像是別人寫的一樣。
許多人認為Eagleson是個樂觀主義者，認為6個月是一個樂觀的時間，可能要不了6個月。不管怎麼說，Eagleson定律強調了清晰、有效的注釋和明確的編碼標準的必要性。畢竟，即使是最初的程式設計師也無法在以後的工作中理解自己剛開始編寫的混亂代碼。
10、盧巴斯基法則（Lubarsky’s law）
There’s always one more bug.
總會有一個更多的bug。
就算你運用了所有的最佳編程實踐、更新以及維護，但總是會有一個更多的錯誤需要修復。或者還有一件事需要調整，或添加，或學習。畢竟，程式設計師的工作是永遠不會完成的。
因此，請記住，當涉及到軟體開發時，完成總比完美好。
11、克努特優化原則（Knuth’s Optimization Principle）
Premature optimization is the root of all evil.
過早優化是萬惡之源。
過早優化讓你在你並不真正需要的東西上花費大量的時間。真正的問題是程式設計師在錯誤的時間和錯誤的地方花了太多時間來擔心效率效率問題。
如果我們試圖優化太早太多，我們就會花大量時間去實現這些優化，從而擠壓我們需要實現的目標的時間。我們可能會花太多的時間來實現我們目前的東西，而未來可能會更糟糕，因為我們選擇的代碼不是最容易維護的。
12、伯斯塔爾法則（Postel’s Law）
Be conservative in what you do, be liberal in what you accept from others.
對於自己輸出要嚴格; 對於他人的輸入要靈活。
在開發一個庫、一個HTTP API、一個類、一個模塊或一個函數時，我們應該提供向後的兼容性，並對接收的參數變得更加靈活。這條規則在現實生活中也同樣適用--我們應該對自己保守，但對別人自由/寬容。
13、複雜度守恆定律（Tesler’s Law of Conservation as Complexity）
Every application has an inherent amount of complexity that cannot be removed or hidden. Instead, it must be dealt with, either in product development or in user interaction.
每個應用程式都有其固有的複雜性，這些複雜性是不能被消除或隱藏的。相反，它必須被處理，無論是在產品開發中還是在用戶互動中。
14、奧卡姆剃刀原理（Occam’s Razor）
The simplest solution is most likely the right one.
最簡單的解決方案很可能是正確的。
更多請參考：《奧卡姆剃刀原理、簡單性原則與軟體開發》
15、軟體工作量估算5法則（The 5 laws of software estimates）
- 估算是浪費時間
- 估算是不可轉讓的
- 估算是錯誤的
- 估算是暫時的
- 估算是必要的
這是看似矛盾法則，但第一條法則說花在估算上的時間不會帶來任何新的功能，所以我們不能花太多時間在這上面。然而，第五條規則說它們只是必要的，所以我們應該估算所有的任務，但不要在估計上花太多的時間。