Home > 閱讀

閱讀 Archive

《程序員修煉之道》、《代碼之美》、《Real-time Rendering 3rd Edition》、《Physical-based Rendering》

新年過後,Mil的開發進度有點慢,花了斷斷續續一個月才完成了一個簡單的 translate gizmo。要長期維持熱情真的不容易。由於沒甚麼Mil的進展可以看,今天也未想到做那個 story,就在此和大家分享這幾個月看過的書。

程序員修煉之道 (英文注釋版)
The Pragmatic Programmer: From Journeyman to Master

我對這書本來沒有很大的期望,而且它的書齡比較大,只是當作休閒讀物,但閱後喜出望外。除了有不少有用精闢的題示,還真的有不少能激發思考的寓言。分享幾個和程序員心理有關的例子,一個提示為

Tip 4: Don’t Live with Broken Windows

說的不是M記的Windows (笑)。故事是說一些研究人員發現,一個漂亮整潔城區如何開始衰落──當一個窗子破了沒修,就會令人覺得業主不關心那大廈,其他人就開始亂拋垃圾、塗鴉,不斷惡性循環,最終變成腐敗地區。

在我的過去,也有不少類似的項目。有時候不是時間的問題,而是心理上的問題。面對寫得不好的東西,沒心要把它弄好,最終只會是一些被廢棄的代碼。又或是,看到一些小bug沒去查,最後要花更多的時間精神去修正,或又是把它放棄。

每看到程序中有問題的地方,就不要容忍。問題可以是設計上的、編程上的。時刻要想著 refactoring。 不要把系統惡化。

另一個提示

Tip 30: You Can’t Write Perfect Software

這個也許是一個顯淺的提示,對我來說郤是一個反省的機會。從來,我希望可以寫出好的程式、好的代碼,希望可以追求完美。但這是不實際的。從來沒有完美的軟件,將來也不會有。軟件內不完美,使用軟件的人或軟件也不完美。要接受這個現實,並反過來令程式在不完美下完成工作。編寫 defensive coding、unit testing。不要為了避免有bug而寫一些「不對的保護」(例如函式內參數不對就直接返回),如果是有問題的,就讓它 crash (或assert等) 並找出問題來源,比匿藏那些問題好。

Beautiful Code: Leading Programmers Explain How They Think
代碼之美

相反,這本原來比較有期望的著作,閱後(沒有全部讀完)有點失望。

有些文章是有些趣味,有些覺得非常沉悶。總體來說,看不到作者們對「美」的看法。一些簡短程式做到比較複雜的功能 (例如 quick sort、regular expression),看上去是不錯的,雖然也不知道簡單是否是美。一些大系統 (例如 ERP…… 囧) 完全不知道他們從那個角度看到它的「美」。

或許,

Beauty is in the eye of the beholder

代碼需然用文字寫成,但是否和詩詞一樣,應用、或可用「美」這個形容詞去度衡量,是一個問題。

買這本書的人或許要三思。

Real-Time Rendering 3rd Edition

毫無疑問,這是一本非常好的書。1027頁、1416個參考文獻、全彩印刷、幾乎沒有廢話和無用插圖(嗯……第三版是有一些比較大的遊戲截圖)、非常全面的內容。開賣時 amazon還打折比買第二版還平宜,是超值的珍藏。第一次擁有這本經典 (第一版在大學圖書館借過,第二版在以前工作上採購過),第一次由頭到尾去閱讀,每個章節都看到自己不懂的新事物。第三版新加入的內容也對我有吸引力。雖然看過一次,但一次絕對不夠,有時間會再讀,再加深理解。

Physically Based Rendering

我在大學沒讀過計算機圖形學、沒寫過 Offline Renderer,所以想多學一些這方面的知識。而另一方面,也憧憬未來計算機圖形的硬件發展,Real-time Ray-tracing、Radiosity 也許會變成主流。這本書提供了理論基楚,和一個 Offline Renderer 的實作 (pbrt),是少有的理論與實際並重的書。

嘗試從頭到尾看一篇,但是後面關於 Monte Carlo Integration 和 Light Transport Equation 對我來說是很難。有時間會再看。

這本書的一個缺點是異常重 (5.5磅 = 2.5 公斤),在床上看腹部會感到很大「壓力」;相對的優點是可以訓練手部肌肉。

閱讀計劃

由於看過《程序員修煉之道 (英文注釋版)》,想繼續看幾本類似的原文書,包括 Kent Beck 的注釋版:

  • Implementation Patterns
  • Test-Driven Development by Example

注釋版是挻方便的,英文生字也不用查字典。

最近還發現剛剛這兩本 Morgan Kaufman 的大陸版英文原文版:

  • 3D Game Engine Design 2nd Edition
  • The Art of Multiprocessor Programming

第一本是剛2009年出版的,現在還斷貨。這書值得參考,尤其是數學部份。

第二本的原書是上年出版的,大陸版也是上年出版。這新書一直想讀,因為自己在這方面比較弱,面對 multi-core 的年代,一定要多多學習。

英文版除了原汁原味,還可以溫習英語,而且有些大陸版的原文書的人民幣價格比原書美金價格還低。真好。

遊戲開發書庫開張

這幾天花了些時間,整理了一個遊戲開發書庫 (還未完整,有時間會更新及加入短評)。

書對我來說是生活的一部份。自修是最基本的學習方法。有些想讀但未讀,有些讀過又忘記,所以在這個 Blog 裡記錄了一些遊戲相關的書目,方便回顧及展望。當有一天心血來潮,就會重溫過去的書,或者買一些想讀的書回來。

回看這個書目裡面,我第一本買的是 Computer Graphics: Principle and Practice。當時應該就讀高中,書中的內容許多都不能理解。但是一點一滴的累積閱歷,也許可以慢慢地把內容吸收。

在之前數年的工作裡,我可以申請購買許多遊戲相關的書籍(多是頗貴的原文書)。有些讀了一遍,有些我自己沒有讀。現在離開了那些書籍,偶然間,又想重拾起來。

在我這個遊戲書庫內暫時有大約100本書,保守估計平均每本書300頁,而每天能讀 50 頁的話,讀一遍便要 600 天,但這個書庫的內容又會不斷增加…… 突然想起中學讀莊子說的

吾生也有涯,而知也無涯。以有涯隨無涯,殆已!

《修改代碼的藝術》

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

如同本書的介紹說:

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

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

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

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

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

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

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

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

Home > 閱讀

Search
Feeds
Meta

Return to page top