Book Review：The Practice of Programming

The Practice of Programming(中譯本：程式設計專家手冊)講的是軟體開發實務上的一些經驗談，包括了編碼風格、效率調校、測試、除錯、表示法...等。


這些主題每個程式設計師每天都會遇到，所以每個人或多或少都慢慢有自己的一套處理的方式，有時不同類型的設計師之間對於同一個主題甚至會有南轅北轍的作法，有時各自都可以運作的很有效，但更多時候我們其實只是在多次的失敗中學到寶貴的經驗，勉力賺取經驗值，然後逐漸修正每一個細節。


如果有這麼一本書，總結了經驗值破表的編程大師的數十年心血結晶，你會不會心動？這就是這樣子的一本書。Brian W. Kermighan是C語言聖經K&R的K，並開發出許多Unix下的軟體(AWK的K也是他)，Rob Pike也是開發過數個程式語言(目前google的GO)，以及作業系統(plan 9)的大牛。他們的編碼時間比大多數的程式設計師的年紀還要大的多，所以當他們提供編程上的意見，實在值得我們好好花時間思考學習。


我簡單摘要章節內容：


第一章 風格
這章講的是coding convention，或許很多人會覺得老生常談，畢竟每天都在命名、使用函式、設計新strucure、類別、模組、為程式加上註解...連入門一兩年的菜鳥都該很熟悉吧？非也，單就命名這件事來講就大有學問，程式碼要能夠讀來簡潔易懂，第一關就是好的名稱，不好的名稱很容易誤導閱讀代碼的人，造成後患無窮的結果。從這基礎但極其重要的編程環節，你可以窺見大師是如何思考代碼的細節。


第二章 演算法與資料結構
這章比較沒有太多思想在其中，但因為基礎演算法與資料結構對任何程式都是如此重要，所以自然也佔有一席之地。作者提供了個很不錯的觀念：對某些應用來說，演算法的重要性的比重可能會佔到絕對的地位，但對絕大多數程式來說(甚至包括作業系統、編譯器)，往往大量使用的都是些基本的資料結構，或從基礎型式去做工程上的微調修改。所以別因為害怕大程式需要高深的演算法，通常都是需要時才去尋找適合的來用，畢竟，嗯...計算機科學家每天就是在搞那些東西。那麼，哪些算共同必備的基礎呢？作者列出：Big-O表示法、search、 sort、list、growing array、tree、hash table，夠基礎了吧？ :P


第三章 設計與實作
這章開始進入本書精彩的部份。在此章中，作者實地考量一個有趣的程式問題 - 隨機產生一篇看似有意義的英文文章。從無到有，從初始想法、資料結構與演算法設計、編程實作，一步一步讓我們看到如何實現出來，並且用了多個程式語言來實作(C、C++、Java、Awk、Perl)，讓你看到不同語言的表達能力與效能差異。在量測效能時，還發現C++的STL在不同的實作品中有著極大的差異，進而提出一個重要的觀念：函式庫、介面、工具變得日益複雜，因此變得更難了解與控制，當能運作時，一切都很美好，但當某個地方失去效用時，往往會有非常難以察覺的瑕疵，甚至無法處理。


第四章  介面
每個程式設計書籍必定包含介面的議題，介面的議題其實就是如何完成抽象化。最低階的抽象話或許就是命名。現今程式語言往往還有許多額外的抽象化機制可用，如何妥善運用這些機制，將決定程式的整體概念是否可達到足夠清晰、簡潔的地步。作者不打高空，舉實際的程式碼給我們看，他們試著設計一組處理CSV格式的API，從每版的改進，說明基本的函式介面設計考量，包括：資訊隱藏、資源管理、錯誤處理、規格說明...從這章我們可以看到，設計可複用的代碼的確不是件簡單的事，即使是簡單的函式介面都有這麼多面向要考量，我們是不是因此應該更小心新語言所提出的新抽象機制呢？新抽象機制帶來的是更多的好處還是更多的麻煩？Think about it before you jump. :)


第五章 除錯
除錯的最高境界就是 - 不要有錯誤發生。但這當然是不可能的，所以當錯誤不幸發生時，要用什麼樣的技巧去解決呢？作者建議：除錯程式作為輔助，重點在於清晰的頭腦與對系統的理解。跟Linus的說法幾乎一致呢！！以前看到有些人很巧妙地運用gdb除錯，往往嘆為觀止，但後來發現，很多人其實只是用避掉的方式在解決問題而已，並不是真的善用gdb去分析問題。除此以外，作者還提供了很多小秘訣，有些蠻有趣的，像是：找人討論前，先找個娃娃講一遍自己遇到的問題。


第六章  測試
測試的重要性大家都知道，但糟糕的是，現實上很多程式設計師並沒有足夠的測試觀念。往往只求第1版的程式趕快動起來，卻忽略了要讓程式碼容易測試、可測試。還有，有多少人會為自己的程式建立自動測試呢？唉，這是我們每個人需努力的目標。作者強調，測試是提升軟體品質最立竿見影的手法，也可以避免付出太多除錯的高昂代價。此章一樣展示了建立不同種類測試程式的手法，都很有用，但最最重要的就是要去執行啊！！


第七章 效能
如同除錯，避免效能調校的首要準則就是 - 不要調校。但非要調校時，可以參考他們的作法。效能頻頸會發生的地方很多，從資料結構、演算法、程式語言特性、作業系統、硬體...都有可能，必須逐層分析才有可能打在痛處上，嗯...這往往也是我們最痛苦的部份。 :P


第八章 移植性
這章我讀的比較沒有感覺。似乎就只是盡可能照愈上層的規範走愈有移植性？ 


第九章 表示法
覺得算是我從這本書獲得最多的部份，因為好幾個東西我從來沒有實作過，感覺非常新鮮。作者從printf、正規表示法、簡易直譯器、compiler's compiler到JIT概念，用不同的表示法來呈現挑選適當語言的威力，並且以實例說明背後的精神，全都是一些不到百行的程式，居然可以這麼強大，極力推荐啊！！軟體設計的重點在於人，這也是為何適當的表示法對於程式設計師這麼的重要。嗯，這不就是抽象化嗎？只不過不同於語言提供的抽象機制，這章的重點在於，好的程式設計設計師可以自行打造出適合的抽象化來表示心中的想法。難怪好的程式設計師對於程式語言都有著某種程度的偏執，酷畢了！！


呼，寫完了~其實這本書從我還在學校唸書時就買了，但那時寫的程式實在太少了，總是念的沒有感覺，直到最近把它從書架拿下來整理，重新閱讀了一遍，才發現有許多經驗前人早就提醒過了。或許人真的要吃點苦頭，走過冤妄路後才會了解這些Cliche的珍貴... :)