高效能程式設計的七個好習慣[節選]

原文請看——http://blog.youxu.info/2008/10/29/seven-habits-of-highly-effective-programmers/

--------------引用------------------

5. 必要的時候, 程式要使用清晰的, 自我解釋的文本檔案作為日志輸出. 

不知道各位調試程式的時候是不是和我一樣, 看到不确定的和要跟蹤的變量就直接插入一行 print. 我以前一直這樣做, 但是頻繁的插入這樣的列印會使得螢幕的輸出很亂, 不知道哪行是什麼意思. 一個更加好的辦法是寫一個日志函數, 可以分也可以不分優先級, 總之保證 Debug 的時候的輸出以一種統一的, 可管理的方式出現. 這樣, 在最後釋出穩定版本的時候, 隻需要簡單的幾行指令就可以從代碼中剔除所有的日志列印行. 

如果必然要輸出日志, 最好要配置設定一個單獨的指令行參數, 用來控制程式究竟輸出不輸出日志, 輸出哪些日志. 一開始看上去這個是費時費力, 越到後來日志越多的時候, 就體會到友善之處: 有時候你隻想要某一類日志, 可是其他的記錄偏偏來搗亂. 多加一個參數可以使得程式更加靈活, 根本不需要去修改代碼或者條件編譯就能得到不同級别的程式日志.

日志和程式的輸出結果一定要清晰且能自我解釋, 否則不如沒有日志. 我切身經曆是這樣的: 幾個月前, 我一個程式跑了大約一天, 最後輸出了很大的日志和結果. 但是很不幸的是, 結果裡隻有數字, 沒有任何說明. 我自己都忘了每一行是什麼意思. 而且更加麻煩的是程式的輸出藏在重重判斷和循環之内, 使得根本沒有辦法分析這一行輸出對應的輸入是什麼. 于是, 最終隻能再次浪費一天的時間讓程式再跑一次.  經過這次教訓, 我的程式日志和結果中插入了不少讓人可讀的内容. 這樣, 即使程式丢失了, 結果還是能夠被人解讀的. 

更多的關于資料和程式結果要能自我解釋的精彩論述, 可參見 More Programming Pearls 第四章.

7. 程式能跑就是萬歲. 除非萬不得已, 盡量不要在性能上優化你的代碼

Knuth 名言: Premature optimization is the root of all evil. (提前優化是萬惡之源). 一般我們寫代碼的時候, 不知不覺的就會覺得, 哎呀, 這樣寫效率不高, 我要構造一個資料結構啥啥. 随機通路一定要哈希表, 排序一定上快排, 查找一定要二分, 強連通分量一定要用 Tarjan 算法, 動規一定比窮舉好等等, 這些競賽的時候極限情況下正确的論斷其實在實際環境中并不重要, 因為做程式設計的一開始關鍵是能跑, 而不是跑得快. 往往這麼以優化, 程式很難 debug, 倒是還要去翻算法導論和TAoCP 看人家的二分怎麼寫的等等. 

在程式能跑的情況下, 優化也要特别小心. 我曾經有一個程式, 大約有 90% 的運算是查表, 隻有 1% 的是乘法, 另外是一些判斷和把插到的結果插入到一個集合中. 我的查表是用的最土的 list.index. 按照正常的想法, 應該把這個優化成哈希表. 而實際上我用 profile 工具一看, 才知道, 原來是插入到一個集合的操作費時間, 因為每次都需要 extend, 涉及到很多記憶體配置設定的操作. 我做過非常多的 profile 測試, 沒有一次不出乎我預料的. 程式運作時間總是在自己不認為浪費的地方被浪費掉. 是以, 就算萬不得已優化, 也務必要先做一下 profiling. 我喜歡 python 的地方就在于, 他的 profiling 隻需要一行語句就完成了, 而且結果具體幹淨. 其他的語言, 至今沒見到這麼簡單的 profiling 工具.

------------------------引用結束--------------------------------