在進行軟體開發和產品設計的時候，有一些經典又有重要參考價值的法則常常被忽視，而忽視這些法則又會讓開發者走一些彎路。

1. 康威定律（Conway's Law）

任何設計系統的組織，其設計的結構都是該組織溝通結構的複製品。

你可能會認為，透過不同層級的會議以及股東的更新和決策，這個狀況可以得到避免，但是實際是，衝突或分歧發生的優先順序，將導致同樣衝突和分歧的過程和結果，從而影響整個設計的結構。

2. 布魯克定律（Brooks's Law）

“給一個遲來的軟體專案增加人力會使它更遲。”

當你意識到你沒有取得預期的進展，並且管理層試圖重新分配人力資源時，那麼專案不僅會更加推遲，而且最後很可能會交付一個更加脆弱、更復雜的產品。

3. 扎溫斯基定律（Zawinski's Law）

“每個程式都試圖擴充套件，直到它包含了一個web伺服器。那些不能擴充套件的專案會被能夠擴充套件的專案所取代。”

4. 帕金森定律（Parkinson's Law）

工作完成的時間會影響工作的量"

在這裡，主要的專案管理經驗是，如果你不為概念性的里程碑設定大概的最後期限，那麼專案將永遠不會完成。這也說明了在固定的時間線上迭代最小可行產品的重要性。

當然，我們也可以根據資料、處理能力、RAM等等來調整這條法則:

在使用完所有可用的儲存空間/頻寬/週期/RAM之前，資料/CPU/記憶體的使用會一直擴充套件

實際上，32GB對任何人來說都足夠了，對吧?

5. 帕累託謬論（Pareto's Fallacy）

帕累託原則很容易被曲解，尤其是被管理層曲解。這通常會導致帕累託謬論:

“當你完成了80%時，你會認為你只剩下20%了。”

這裡忽略的關鍵部分是，這20%，其實需要你投入80%的時間。

6. 斯特金啟示（Sturgeon's Revelation）

所有部分的90%都是無用的。

是的，你的產品也包含在內。

7. 彼得原則（The Peter Principle）

在等級制度中，每個員工都傾向於升到他們不能勝任的級別。因此，隨著時間的推移，每個崗位都有可能被不稱職的員工佔據。”

8. Eagleson定律（Eagleson's Law）

任何你自己的程式碼，如果你有6個月或更長的時間沒有檢視，就好像是別人寫的一樣。

實際上，6個月已經相當樂觀了。

不過，有一點需要注意，那就是“Yo mom推論”:

只有原作者才可以批評程式碼;任何其他的負面反饋都會被駁回。

9. Greenspun程式設計的第10條規則（Greenspun's 10th Rule of Programming）

任何自定義開發的身份驗證系統都包含一個特別的、非正式指定的、充滿錯誤的、緩慢的Kerberos實現。

這可以概括為普遍的NIH規則:“任何定製開發的系統都包含一個臨時的、非正式指定的、有bug的、緩慢的執行，而這些執行的物件有一半都是你拒絕使用的工業界標準。”

10. 冰山謬論（The Iceberg Fallacy）

新軟體產品的開發成本僅佔所有權管理的總成本和預算的25%。

對於運維來說，有一句格言是這麼說的：

“如果軟體維護佔總擁有成本的75%，那麼運營支援就是剩下的75%。”

參考資料：

https://www.netmeister.org/blog/software-engineering-laws.html