標籤：管理 經驗 電腦 軟體
這是摘抄自《編程珠璣II》第六章的一些比較有趣的話，加上了一些自己的感想或理解。
編碼篇
- 迴歸測試能將測試區間減半。
—Larry Bernstein，貝爾通訊研究院
- Π秒就是一個納世紀。
—Tom Duff，貝爾實驗室
- 如果還沒想清楚，就用蠻力演算法吧。（自己想了之後，蠻力之前，請別人幫自己想想）
—Ken Thompson，貝爾實驗室
- 避免不對稱結構。
—Andy Huber，Data General公司
- 你用英語都寫不出來的東西就別指望用代碼寫了。
—Peter Halpern，貝爾實驗室
- 如果代碼和注釋不一致，那很可能兩者都錯了。
—Norm Schryer，貝爾實驗室
- 如果你發現特殊情況太多，那你肯定用錯方法了。（保持簡單的設計，解決一般性問題，比解決特殊問題更容易）
—Craig Zerouni，Computer FX公司（英國倫敦）
- 先把資料結構搞清楚，程式其餘部分自現。（所有的演算法，都與相應的資料結構配套，選擇一種合適的資料結構，好的演算法才可能出現）
—David Jones，荷蘭阿森
- 代碼寫得越急，程式跑得越慢。（先思考，看看是否有更好的演算法，編碼的過程寫出便於編譯器進行最佳化的代碼）
—Roy Carlson，威斯康辛大學
使用者介面篇
- 【最小驚異原則】儘可能讓使用者介面風格一致和可預測。（人們的習慣是很難突然改變的，如果使用者做到了，很可能是不愉快地做到的，更可能的是使用者根本不想去做；如果要讓使用者等待，要麼告知使用者還要等待多久，要麼主動讓使用者忘了等待這件事）
- 電腦產生的輸入通常會讓一個原本設計接收手工輸入的程式不堪重負。（嗯，這肯定不是在說程式崩潰，而是電腦輸入太快了）
—Dennis Ritchie，貝爾實驗室
- 80%的表單會要你回答沒有必要的問題。（保持簡單的設計吧）
—Mike Garey，貝爾實驗室
- 不要讓使用者提供那些系統已經知道的資訊。（電腦能做的事，就別用手工做了，即使那些手工不是你的）
—Rick Lemons，Cardinal資料系統公司
- 所有資料集的80%中，有95%的資訊量都可以用清晰的圖表示。
—William S. Cleveland，貝爾實驗室
調試篇
- 在我所有的程式錯誤中，有80%是語法錯誤。剩下的20%裡，80%是簡單的邏輯錯誤。在剩下的4%裡，80%是指標錯誤。只有餘下的0.8%才是困難的問題。
—Marc Donner，IBM沃森研究中心
- 在系統測試階段找出並修正錯誤，要比開發人員自己完成這一工作多付出兩倍的努力。而當系統已經交付使用之後找出並修正一個錯誤，要比系統測試階段多付出9倍的努力。因此，請堅持讓開發人員進行單元測試吧。
—Larry Bernstein，貝爾通訊研究院
- 不要站著偵錯工具。那會使得你的耐心減半，而你需要的事全神貫注。
—Dave Storer，愛荷華州錫達拉皮茲
- 測試只能證明程式有錯誤，而不能證明程式沒有錯誤。
—Edsger W. Dijkstra，德克薩斯大學
- 別在注釋裡陷得太深——注釋很可能會誤導你，你要調試的只是代碼。（所以最重要的要理解要解決的問題是什麼，那樣就可以知道代碼和注釋哪個更可靠）
—Dave Storer，愛荷華州錫達拉皮茲
- 新系統的每一個新使用者都可能發現一類新的錯誤。（新使用者發現錯誤不是壞事，說明你的使用者正在增加，如果想要更多，愉快地修複吧）
—Brian Kernighan，貝爾實驗室
- 東西沒壞，就別亂修。
—羅納德.雷根，加州聖巴巴拉
- 【維護者箴言】如果我們沒有能力修好它，我們就會告訴你他根本就沒壞。（最好別這樣，最起碼指出錯誤在哪裡，或明確給出正確的使用方式）
—Walt Weir，美國陸軍中校
- 修正程式的第一步是要先重視這個錯誤。（然後理解這個錯誤，接下來才是修正）
—Tom Duff，貝爾實驗室
效能篇
- 【程式最佳化第一法則】不要最佳化。
- 【程式最佳化第二法則——僅對專家適用】還是不要最佳化。
—Michael Jackson，Michael Jackson系統公司
- 對於那些快速演算法，我們總是可以拿一些速度差不多但是更容易理解的演算法來替代它們。（如果可以，為什麼不呢）
—Douglas W. Jones，愛荷華大學
- 在一個非I/O密集型的程式中，超過一半的已耗用時間是花在不足4%的代碼上的。
—Don Knuth，斯坦福大學
- 在一些機器上，間接定址比基址定址更慢，所以請把結構體或記錄中最常用的成員放在最前面。
—Mike Morton，麻薩諸塞州波士頓
- 在最佳化一個程式之前，請先用效能監控工具找到程式的“熱點”。
—Mike Morton，麻薩諸塞州波士頓
- 【代碼規模守恒定律】當你為了加速，把一頁代碼變成幾條簡單的命令時，請不要忘了增加註釋，以使源碼的行數保持為一個常量。
—Mike Morton，麻薩諸塞州波士頓
- 如果程式員自己類比實現一個構造比編譯器本身實現的那個構造還要快，那編譯器作者也太失敗了。
—Guy L. Steele，Jr.，Tartan實驗室
- 要加速一個I/O密集型的程式，請首先考慮所有的I/O。消除那些不必要的或冗餘的I/O，並使餘下的部分儘可能地快。
—David Martin，賓夕法尼亞州諾裡斯敦
- 大多數的組合語言都有迴圈操作，用一條指令進行一次比較分支；儘管這條指令是為迴圈設計的，但在做普通的比較時也往往能派上用場，而且很有效。
—Guy L. Steele，Jr.，Tartan實驗室
文檔篇
- 【否定測試】如果一句話反過來就必然不成立，那就根本沒必要把這句話放進文檔。
—Bob Martin，AT&T公司
- 當你試圖解釋一條命令，一個語言特性或是一種硬體的時候，請首先說明它要解決什麼問題。
—David Martin，賓夕法尼亞州諾裡斯敦
- 【一頁原則】一個{規格說明、設計、過程、測試計劃}如果不能在一頁8.5英寸×11英寸的紙上寫明白的話，那麼這個東西別人就沒辦法理解。
—Mark Ardis，王安公司
- 紙上的工作沒結束，整個工作也就還沒結束。
軟體管理篇
1． 系統的結構反映出構建該系統的組織的結構。
—Richard E. Fairley
2． 別堅持做哪些沒用的事。（通用語）
3． 【90-90法則】前90%的代碼佔用了90%的預定開發時間，餘下的10%代碼又花費了90%的預定開發時間。
—Tom Cargill，貝爾實驗室
4. 只有不到10%的代碼用於完成這個程式表面上的目的，餘下的都在處理輸入輸出，資料驗證、資料結構維護等家務活。
—Marry Shaw，卡內基-梅隆大學
5. 正確的判斷來源於經驗，然而經驗來源於錯誤的判斷。（別怕錯誤）
—Fred Brooks，北卡羅來納大學
6. 如果有人基本做出了你想要的東西，你就沒必要自己寫一個新程式。就算你非寫不可，也請儘可能多地利用現有的代碼。（嗯，工作中可以這樣，如果是要學習理解，自己動手吧）
—Richard Hill，惠普公司（瑞士日內瓦）
7. 代碼能借用就借用。（若理解了可以這樣）
—Tom Duff，貝爾實驗室
8. 與客戶保持良好的關係可以使生產率加倍。
—Larry Bernstein，貝爾通訊研究院
9. 把一個現有成熟程式轉移到一種新語言或者新平台，只需要原來開發的十分之一的時間、人力、成本。
—Douglas W. Jones，愛荷華大學
10. 那些用手做就已經很快了的事情，就別用手做了。
—Richard Hill，惠普公司（瑞士日內瓦）
11. 那些能用電腦迅速解決的問題，就別用手做了。
—Tom Duff，貝爾實驗室
12. 我想寫的程式不只是程式，而且是會寫程式的程式。（這個目標很激動人心，值得追求，想偷懶，先變得更勤快）
—Dick Sites，DEC公司
13. 【Brooks原型定理】計劃好拋棄一個原型，這是遲早的事。（迭代初期產生的產品應該是最終系統的一部分，我更傾向下一條）
—Fred Brooks，北卡羅來納大學
14. 如果開始就打算拋棄一個原型，那恐怕你得拋棄兩個。
—Craig Zerouni，Computer FX公司（英國倫敦）
15. 原型方法可以使系統開發的工作量減少40%。
—Larry Bernstein，貝爾通訊研究院
16. 【Thompson望眼鏡學徒定理】先做一個4英寸鏡片的9（望遠鏡），再做一個6英尺鏡片的，這比直接做6英尺鏡片更省時間。
—Bill McKeeman，王安公司
17. 拚命幹活無法取代理解。（理解問題，然後理解問題，然後一邊幹活，一邊理解）
—H. H. Williams，加州奧克蘭
18. 做事應該先做最難的部分。如果最難的部分無法做到，那還在簡單的部分上浪費時間幹嘛？一旦困難的地方搞定了，那你就勝利在望了。
19. 做事應該先做最簡單的部分。你開始所預想的簡單部分，做起來可能是很有難度的。一旦你把簡單的部分都做好了，你就可以全力攻克最難的部分了。（先做簡單的事情利於理解問題）
—Al Schapira，貝爾實驗室
其他
- 【Sturgeon定律】毫無疑問，90%的軟體都沒什麼用。這是因為對任何東西而言，90%都是沒什麼用的。
——Marry Shaw，卡內基-梅隆大學
- 對電腦撒謊是要受到懲罰的。
——Perry Farrar，馬里蘭州
- 如果不要求系統可靠的話，它可能做任何事情了。
——H. H. Williams，加州奧克蘭
- 一個人的常量就是另一個人的變數。（這句話在生活中不也可以用嗎？）
——Susan Gerhart，Microelectronics and Computer Technology公司
- 一個人的資料就是另一個人的程式。
——Guy L. Steele，Jr.，Tartan實驗室
- 【KISS法則】用最簡單、最笨的方法做事。（崇尚簡單，但別被“笨”字騙了，思考創造性的方法吧，大智若愚不是做出來的，而是看起來的樣子）
結語
別輕信那些看似聰明的法則。（選擇一些能說服自己的法則去實踐，法則是可以相悖的，但是不應該因為它們的存在而搖擺自己的決策）
——Joe Condon，貝爾實驗室
電腦科學箴言集
