軟體開發的基本法則

墨菲定律
“任何可能出錯的事情都會出錯。”
可能是所有法律中最著名的法律之一，主要是因為它不僅適用於軟體開發。

1. 第一個推論：如果它起作用，可能不是你寫的。
2. 第二個推論：罵人是所有程式設計師唯一能說流利的語言。
3. 結論：計算機會做你寫的東西，而不是你想做的。

布魯克斯定律
“為後期專案增加人力會使其更晚。”
Fred Brooks 於 1975 年撰寫的神話人物月是 Brooks 定律的來源。它的運作前提是團隊成員和所需的月數可以互換。這是不正確的，尤其是在開發軟體（或任何產品開發，就此而言）時。為什麼？由於需要時間來通知和更新專案的個人。

康威定律
“任何軟體都反映了產生它的組織溝通結構。”
這條軟體開發規則是梅爾文·康威在 1967 年提出的。產品設計與康威定律有關。通訊架構對軟體生產的影響是一個觀察到的現象。
因此，一個緊密團結的團隊齊心協力開發具有相互交織的功能和程式碼的軟體。
與此同時，一個更鬆散、去中心化的團隊會生產更多模組化的軟體。

霍夫斯塔德定律
“它總是比你預期的要長。（即使考慮到霍夫施塔特定律。）”
軟體開發中最擔心的問題之一是“需要多長時間？” 霍夫施塔特定律給出瞭解釋。
這與另一條被稱為帕金森定律的規則有關，該定律指出，工作會擴大到佔用完成它所需的所有時間。由於帕金森定律和霍夫施塔特定律，很難預測完成時間。

萊納斯定律
“只要有足夠的眼球，所有的bugs都是淺的。”
這一定律是用著名的《大教堂與集市》一文來描述的，解釋了兩種不同的自由軟體開發模式之間的對比。

• 大教堂模式，在這種模式下，每一個軟體版本都有原始碼，但在兩個版本之間開發的程式碼只限於一個專屬的軟體開發者群體。
• 集市模式，在這種模式下，程式碼是在公眾的視野中透過網際網路開發的。

古德哈特法則
"當一個措施成為一個目標時，它就不再是一個好的措施"。

古德哈特定律在軟體開發中的一個例子是程式碼行。程式碼行提供了一種衡量軟體產品規模的方法。但是，當被用作目標時，程式碼質量就會下降。本應需要精煉或從軟體中刪除的行，反而被建立起來，形成一盤混亂的義大利麵條程式碼。

Gall蓋爾定律
"一個有效的複雜系統是由一個有效的簡單系統演變而來。一個從頭開始建立的複雜系統不會工作。"

蓋爾定律，如果它成立的話（似乎是這樣的），是以最小可行產品（MVP）開始軟體產品開發的一個好理由。

Zawinski定律
"每個程式都試圖擴充套件，直到它能閱讀郵件。那些不能擴充套件的程式會被能擴充套件的程式所取代"。

說到複雜性，扎溫斯基定律表明，產品一旦建成，就會繼續擴充套件。它們會增加更多的功能領域，直到它們無法再擴充套件為止。功能蠕變的例子說明了軟體開發中的扎溫斯基定律。臃腫的程式很快就會被放棄，轉而選擇更精簡的方案。

伊格利森定律
"任何你自己的程式碼，如果你有6個月或更多的時間沒有看，可能還不如別人寫的好。"

許多人認為Eagleson是個樂觀主義者--認為6個月是一個慷慨的時間框架。不管怎麼說，Eagleson的法則強調了清晰、有效的評論和明確的編碼標準的必要性。畢竟，即使是原來的程式設計師也無法在以後的工作中破譯混亂的程式碼。

盧巴斯基定律
"總是有一個更多的錯誤。"

最後，對於你所有的程式設計最佳實踐、更新和維護，總是有一個更多的錯誤要修復。或者還有一件事需要調整，或者增加，或者學習。畢竟，程式設計師的工作是永遠不會完成的。所以，請記住，當涉及到軟體開發時，完成總比完美好。

九十法則
"前90%的程式碼需要10%的時間。
剩下的10%需要另外90%的時間！"

克努特的最佳化原則
"過早的最佳化是萬惡之源！"

如果你試圖在最佳化時考慮到未來的狀態，試圖考慮到未來的邊緣情況，那麼你就會在本質上不斷增加系統本身的解決方案的複雜性，同時甚至不能正確地知道未來的問題狀態到底會是什麼。