作者 | Jan Schaumann
譯者 | 王者
策劃 | 萬佳
與其他領域一樣,軟體開發領域也有一些非常經典的定律。這些定律包括了一些法則或軟體開發大神的名言。
康威定律
也就是所謂的“按照組織架構來交付軟體”:
“任何一個組織在設計一個系統時,這個系統的結構與這個組織的溝通結構是一致的”。
你或許認為可以透過一些方式來避免這個定律,比如跨功能團隊的站會、進度更新和決策矩陣,但最終都不可避免地會發生衝突和分歧,而這些將導致衝突和分歧的過程和結果。
布魯克定律
這個定律來自《人月神話》:
“在一個已經延期的專案中增加人手只會讓專案延期更長”。
當你意識到專案沒有取得預期的進展,並嘗試從其他地方調取更多的資源,不僅會讓專案延期,而且更有可能交付一個更脆弱、更復雜的產品。
Zawinski 定律
“每一個程式都會膨脹到需要加入 Web 伺服器,不膨脹的程式最終會被膨脹的程式所代替”。
對 Web 服務來說,就是“膨脹到需要使用者賬號登入並收集所有使用者的資料”。對物理服務來說,就是“膨脹到需要加入一個不安全的 WiFi 訪問點,設定了你無法修改的預設密碼,以及一個 Web 伺服器”。
帕金森定律
“一項工作會佔用掉所有用來完成它的時間”。
如果你不給一個專案的里程碑階段設定截止日期,這個專案就永遠完成不了。這就是為什麼一定要給一個 MVP(最小可行產品)定一個固定的截止日期。
當然,這個定律也可以用在資料、算力、記憶體等方面:
“程式最終會把所有可用的儲存空間、CPU 時間和記憶體用光”。
帕累託謬論
帕累託原則很容易被曲解,尤其是被管理層曲解,這通常會導致帕累託謬論的出現:
“當你完成了 80% 的工作,你會認為真的只剩下 20% 的工作要做”。
但你可能低估了剩下的 20% 工作,因為它可能佔用你 80% 的時間。
史特金定律
“90% 的東西都是垃圾”。
是的,包括你的產品在內。
皮特定律
“在一個等級制度中,每個員工都傾向於升到他們無法勝任的職位。因此,隨著時間的推移,每個崗位都有可能被不稱職的員工佔據”。
伊格爾森定律
“你寫的任何超過 6 個月沒有看過的程式碼,有可能已經被別人改過了”。
這裡說的 6 個月已經是一個很樂觀的數字了。
不過,有一點需要注意,那就是“Yo Momma 推論”:只有作者才可以給程式碼提出批評,任何其他的負面反饋都將被駁回。
格林斯潘第十定律
用在認證方面:
任何一個定製開發的認證系統都包含一個臨時的、非正式的、隱藏缺陷的、執行緩慢的 Kerberos 不完整實現。
這可以概括成一般性的 NIH 規則:“任何一個定製開發的系統都包含一個臨時的、非正式、隱藏缺陷的、執行緩慢的行業標準的不完整實現(因為你拒絕直接使用標準實現)”。
冰山謬論
“一款新軟體的開發成本只佔管理層預算的總成本的 25% 左右”。
運維界的一句格言:
如果說軟體維護的成本佔了總預算的 75%,那麼這 75% 都應該是運維支援。
LGTM 困境
“如果你想快速提交 10 行程式碼變更,可以把它隱藏在一個 1500 行的 PR 中”。
https://www。netmeister。org/blog/software-engineering-laws。html