程序員修煉之道 (The Pragmatic Programmer From Journeyman to Master) 第四章讀書心得

續上一章 程序員修煉之道 (The Pragmatic Programmer From Journeyman to Master) 第三章讀書心得.

此為讀後重點筆記,好書值得大家購買閱讀.

本章終於開始進入寫程式的階段,利用語言或是外掛提供的功能,在進入程式實作之前建立一些規則/定義,讓潛在的問題提早在開發階段發生,而不是出包會黑掉的部署階段. 囧rz

按合約編程在實際開始編碼前,先規定好預期的 input 和 output ,我剛開始寫程式似乎都是用此想法開始,但後來我比較喜歡用測試先行的方式來寫碼.

死掉的程式就是死了! 換句話說有問題就讓程式早點死掉,忽略問題雖然可以讓程式繼續執行,但有很大的可能它已經是個活死人了(而已你也只會覺得它怪怪的),人死了才會讓程式設計師去正視問題!

斷言編程 不同於 合約編程,合約編程定出預期的事物,斷言編程用於檢查程式設計師(不要相信自己是本書的中心思想之一)認為不會發生的情況. 現實生活中,我還是習慣用 測試先行 來包含 合約編程 + 斷言編程 這兩種作法.

例外 是 Java 處理錯誤的方式,我只知道 1)不要亂隱藏例外,2)要寫有可讀性質的例外,3)將例外用於真正異常發生的時候,而不是當作 true/false 的昂貴代替寫法.

Java 有垃圾回收機制,所以資源部份我就不亂發表心得了! 以後我若改去寫 C 的工作,我相信我要重花一段時間好好學習這一塊. XD

第四章 Pragmatic Paranoia

Desing by Contract

• 正確的程式就是”不多做事! 也不少做事!”.
• 寫出懶惰的片段程式碼 - 也就是專注做好一件事的程式碼.
• 合約 會定義出 進入條件 和 結束時會得到的結果.

Dead Programs Tell No Lies

• 利用 例外機制 盡早在開發階段就發現錯誤.
• 一旦在某個地方發生了自以為不會發生的錯誤,這之後的程式也就不能夠被保證是正確的.
• 假裝還活著的程式(對問題視而不見) 比 早點死掉的程度(強迫中止讓開發者察覺) 造成更大的傷害.

Assertive Programming

• 若你肯定不會發生,那就加上 Assertion 來確保真的不會發生.
• Assertion 是用來檢查不會發生的情況,而不能當成程式流程的一部份(若關掉 Assertion 就會造成流程錯亂).
• 出貨時,在講求效能的地方關掉 Assertion ,其它地方則持續開啟 Assertion .
• 若檢查行為會影響程式的行為(Side Effect),這就是有問題的程式.

When to Use Exceptions

• 觸發例外的時間點: 當未預期的事情發生. 換句話說,你預期發生的事情並沒有發生. ex: 開啟一個系統內應該要存在的檔案.
• 如果你不確定這件事該不該發生,那 不觸發例外 是合理的作法. ex: 開啟一個使用者指定的檔案.

How to Balance Resources

• 拿到資源要記得把資源還回去(有始有終).
• 由拿到資源的人(方法),在離開時負責釋放資源.
• 釋放資源的順序 要跟 取得資源的順序 相反.
• 若程式在不同的地方,都有取得同一組(多個)資源的需求,取得資訊的順序要一樣,可以減少死結的情況發生.
• 巢狀資料結構適放資源的三種策略:

1. 最上層 必須負責 其擁有的資料結構的釋放資源動作.
2. 最上層 只釋放自己所佔用的資源.
3. 如果最上層其下擁有資料結構,便不允許釋放資源.