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

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

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

本章主要強調的重點是 – 程式設計師是否真的了解自己在寫什麼. 而 程式黑手 與 程式設計師 的最大差別我想也在於此 - 是否有在用腦在寫程式碼,還是不管三七二十一拼出一個會動的東西而已.

靠巧合編碼 最好的解釋情境 – 修一個關於迴圈的 Bug ,只是不斷地去調整迴圈 index 的範圍,而不是找出錯誤的真正原因. 如果在寫程式時有這樣的心態,那你就是在靠巧合在編碼.

演算法的速度 使用 O() 表示法,在編碼(或 檢視程式碼片段)的過程中就能大概知道其效率,提早察覺效能上可能會遇到的瓶頸.

重構 鼓勵程式設計師週期性地檢視過去的程式碼,昨日的程式碼不見得符合現今的需要. 不斷地透過重構來整理程式碼,而不是在歪斜的骨架上搭建新的疊層屋.

易測試的代碼 在於寫程式之前就已經準備好測試的程式碼,如此所寫的程式碼不自覺就會以好測試為目標來下筆. 理想中,程式碼的大功能會被切分成小功能(這樣比較好分別測試). 另外,測試程式是重構最好的朋友,重構完是否搞砸了原有的功能? 問問測試程式是最快的方法.

邪惡的嚮導 也就是靠 IDE 工具生成出來的程式碼. 如同靠巧合編碼,是否真的了解程式碼,是 程式黑手 與 程式設計師 的最大的差異之處. 就算只是想當個程式黑手過日子,我相信多了解程式碼還是能節省許多解 Bug 的時間,好讓你回家看老婆抱小孩就是.

第六章 While You Are Coding

Programming by Coincidence

• 清楚自己要做什麼再下去做,不要只是盲目地寫程式碼.
• 倚賴可靠的結果,而不是”假設它應該是…”,遇上 假設 請實際去驗證它.
• 不要讓 過去的程式碼 限制了 當下的程式碼! 過時了那就重構它!

Algorithm Speed

• 對於 O() 表示法有所了解,並了解自己寫的程式碼其 O() 值.
• 如果真的看不出來,可以直接調整 input 將結果做成圖表,利用圖表看出大概的效能.
• 根據實際情況選擇適當的作法即可,不需要總是使用最完美的作法.
• 確認是瓶頸後再去優化它,而不要掉進過早優化的陷阱中.

Refactoring

• 與其說寫程式是在蓋房子,更不如說是在規劃你家花園,花草會爛所以你要加肥料,也許你覺得看膩了你又會買新的花回來種. 這裡要強調的是,需求及環境是不斷隨時間而變遷的,不符時宜的程式碼就可以重構之.
• 當你發現 1)重複的程式碼片段 2)正交性很差的設計 3)過時的資訊 4)效能差 的情況,這代表你該重構你所看到的問題了.
• 重構和增加新功能不要同時進行.
• 重構前先準備好對應的測試程式,這樣你能馬上知道你有沒有搞砸任何東西.
• 把重構拆成多個小步驟,每完成一個步驟就檢查一次,而不是一次重構完再來檢查.

Code That’s Easy to Test

• 若欲測試的模組有關聯到別的模組,那先從關聯模組開始測試.
• 測試程式能向別人展示如何使用你寫的程式.
• 測試程式能在你做了任何的變動後,快速告訴你是否改爛了哪些原本正常的功能.

Evil Wizards

• 了解利用工具自動產生出來的程式碼.