Home > 遊戲編程 | 閱讀 > 《修改代碼的藝術》

《修改代碼的藝術》

自從看見書評有關一本名為《修改代碼的藝術》(Working Effectively with Legacy Code, by Michael C. Feathers)的書,感覺是工作上很有需要,就急忙走上 amazon訂了這個內地中譯本。昨天收到並讀了幾章,先說一些表面的,看完後再寫讀後感吧。

如同本書的介紹說:

如果不積極地修改、挽救、隨著時間流逝,所有軟件都會不可避免地漸漸變得複雜、難以理解,最終腐化、變質。因此,理解並修改已經寫好的代碼,是每一位程序員每天都要面對的工作,也是開發程序新特性的基楚。

這些話語都像在對我說的。工作上,每天也要去修改一個很大的 code base,看 source code 好像 reverse-engineering 一樣,看到一些代碼甚至會感到沮喪。或許這也是許多這行業的人的經驗吧,可是我卻是非常缺乏這種經驗,因為以前的我比較多是維護自己設計軟件,比較少去修改別人的軟件。

遺留代碼一般所想就是沒有人維護、時代久遠、甚至是很爛的代碼。但作者對遺留代碼的定義和一般所想的很不同:

對我來說,遺留代碼就是沒有編寫相應測試的代碼。

這不是對遺留代碼字面的解釋,而是一個深切的體會。從樂觀的角度看,這定義引申,遺留代碼並不是無藥可救的東西,只是沒有測試程式而已,只要耐心加入測試機制,就可以慢慢地挽救。

作者提供了一連串的修改程式技術,這些技術沒有正統的名稱,所以每個章節的名稱也很長,例如「第22章 要修改一個巨型方法,郤沒法為它編寫測試」。從目錄看到這章的名稱,又令我回想一個月前用了一整天去理解一個幾千行的函數的遭遇。但是,很諷刺地,在這一部份的最後來一章又叫「第24章 當你感到絕望時」。昨天面對代碼而感到無助時,便立刻看了這一章,頓時覺得,我還未到絕望的境地,心態一轉,難題也解決了。

今天讀到 Fake Object 和 Mock Object,開始明白 Edwin 做的 AMOP 有幾偉大。

要寫漂亮的代碼是以往的一個目標,今天覺得,要寫不變成遺留代碼的代碼,是更重要的。如何在遊戲編程中實踐編寫測試是我今天的疑問 (對於圖像、互動的測試等…..),希望看畢本書後有新的體會,再與大家分享。

Comments:2

半路 08-03-27 (四) 16:03

看了你的心得介紹,突然對這本書很感興趣,上網查了一下,發現這本書竟然沒有繁體中文版,只好從別的管道試試了。

在修改一個龐大系統中的小組件時,真的會有如你所述的這種感觸:無助、痛苦或者憤怒,但是同樣必須前進,畢竟專案時程不會等人。

不知道你有沒有看過 Refactoring 這本書?內容也是與修改既存程式碼相關,是一本非常經典的佳作。

Milo 08-03-27 (四) 23:18

Refactoring 我有的也是台灣繁體版本。不過只是粗略地看了一遍,有時間應該重溫一下。當中覺得比較難接受就是一些對效能有影響的 rule,例如不用 local variable 記下函式的傳回值,而改為每次呼叫函式等。

有時間或者我可以開一頁記錄一下自己擁有或閱讀過關於遊戲方面的書藉。

Comment Form
Remember personal info

Trackbacks:0

Trackback URL for this entry
http://miloyip.seezone.net/wp-trackback.php?p=42
Listed below are links to weblogs that reference
《修改代碼的藝術》 from Milo的遊戲開發

Home > 遊戲編程 | 閱讀 > 《修改代碼的藝術》

Search
Feeds
Meta

Return to page top