外刊IT評論:軟體編程21法則

任何一個有經驗的程式員都知道，軟體開發遵循著一些不成文的法則。然而，如果你不遵循這些法則也並不意味著會受到懲罰；相反，有時你還會獲得意外的好處。下面的就是軟體編程中的21條法則：

 

 

任何程式一旦部署即顯陳舊。

修改需求規範來適應程式比反過來做更容易。

一個程式如果很有用，那它註定要被改掉。

一個程式如果沒用，那它一定會有很好的文檔。

任何程式裡都僅僅只有10%的代碼會被執行到。

軟體會一直膨脹到耗盡所有資源為止。

任何一個有點價值的程式裡都會有至少一個bug。

原型完美的程度跟審視的人數成反比，反比值會隨著涉及的資金數增大。

軟體直到被變成產品運行至少6個月後，它最嚴重的問題才會被發現。

無法檢測到的錯誤的形式無限多樣，而能被檢測到的正好相反，被定義了的十分有限。

修複一個錯誤所需要投入的努力會隨著時間成指數級增加。

軟體的複雜度會一直增加，直到超出維護這個程式的人的承受能力。

任何自己的程式，幾個月不看，形同其他人寫的。

任何一個小程式裡面都有一個巨大的程式蠢蠢欲出。

編碼開始的越早，花費的時間越長。

一個粗心的專案計劃會讓你多花3倍的時間去完成；一個細心的專案計劃只會讓你多花2倍的時間。

往大型項目裡添加人手會使項目更延遲。

一個程式至少會完成90%，但永遠完成不了超過95%。

如果你想麻煩被自動處理掉，你得到的是自動產生的麻煩。

開發一個傻瓜都會使用的軟體，只有傻瓜願意使用它。

使用者不會真正的知道要在軟體裡做些什麼，除非使用過。