軟體建構之道 (Code Complete) 第二版 第二十章到第二十六章心得

這幾章都在討論如何改善程式碼,我心得不太多,應該說重點太多,不知能說啥. Orz

第二十章-軟體品質面貌

使用者關心的是軟體好不好用,而不是程式碼用了哪些驚為天人的設計. (心酸貌)

每項影響軟體品質的參數是會互相抵制的,就跟你老闆要你在最短的時間,最少的人力下,做出效率最高的應用程式.

第二十一章-共同構築

兩個 RD 一起趕一個專案. 雖然書上說好處多多,但我當初被電很慘. 由其一開始沒導入 CVS ,版本的統整根本是惡夢一場.

第二十二章-開發人員測試

RD 自己測自己寫的程式. 這應該是很多 RD 每天都在做的事吧. 我通常只有在重要的子系統部份會做先行測試,先寫出測試程式,等等寫完系統就能馬上測試. 雖然有些人會覺得寫一份 Code 還嫌不夠多嗎? 但說也奇怪,寫完馬上能測還真的怪爽的. 我自己覺得先行測試好處如下:

• 撰碼前先寫測試程式,不會掉入已經熟悉功能而寫些無關痛癢的測試方法.
• 以使用這個功能的角度來測試,讓程式的介面更容易被使用(更有模組的感覺).
• 寫完可測,亂爽一把.
• 之後修改或重構功能,馬上能用測試程式驗證.

第二十三章-除錯

請利用 Debug 工具,縮小錯誤可能發生的範圍,不要用心電感應來找到錯誤.

花費了大量的時間來除錯,若可以請認命重寫程式碼比較好(尤其是在一大塊爛 Code 中找 Bug).

了解問題所在,才開始修改程式碼. 不要用 +1 不行那我 -1 看看能不能跑的烏龜心態. 這不叫 Debug ,這叫碰運氣!

第二十四章-重整

這章要自己看啊! 書上寫了很多關於需要重整程式碼的線索(比如: 不斷看到相同的程式碼片段...etc). 若確定寫完的 Code 不會再被射回自己臉上者,可跳過此章節.

第二十五章-程式碼微調策略

不要太早最開始最佳化. 你這個月房貸都快繳不出來了,你還在想要買什麼 3C 產品來提升自己的生活品味嗎.

正確的程式比快速的程式重要.

只有經過實際測試,才能得知是否真的最佳化. 沒有數據,一切都是瞎猜!

第二十六章-程式碼微調技巧

就說是微調了,我不知有啥心得啊! 超多~小重點啊!