軟件工程必看——10條你最容易忽視的經典法則
本文列出了10條經常被忽視的軟件工程法則，包括康威定律、布魯克斯定律、扎溫斯基定律、帕金森定律、帕累托法則、斯特金的啟示、彼得原理、Eagleson 定律、Greenspun 的第十條編程規則以及冰山謬論。
在進行軟件開發和產品設計的時候，有一些經典又有重要參考價值的法則常常被忽視，而忽視這些法則又會讓開發者走一些彎路。
因此，小編在這里放上10條最容易被忽視的10條軟件工程法則，大家可以作為參考：
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%。
