LtRay的艱難重構（一）

從去年九月份開始，我就在着手實現一個光線跟蹤器：LtRay。剛開始進展很快，差很少三天的時間，光線跟蹤器的雛形就已經具有了，可以對一些簡單的圖元好比球體、平面等進行渲染，而且還具備反射、陰影效果。可是越到後面，開發的進度就愈來愈慢了，近兩個月幾乎就是作些填補工做。如今每改一個地方，幾乎就得花費一兩天的時間來修復相關的代碼。前不久剛定下v0.1.7版本，渲染的效果以下：

而這跟我兩個月前的版本相比，幾乎就只是把光線跟蹤的核心分離出來，另外把場景文件的格式從json改爲了toml。每遇到一個問題，我都在糾結到底該哪種方式來解決，實際上，這種猶豫耗費了大量的時間。擺在我面前的方法彷彿有無數種，但就是無法肯定哪種是最好的，結果就是反覆修改來修改去，好比我遇到的有這些坑：

第三方庫

針對於第三方庫這個問題，其實一開始我是拒絕使用的。我使用的是CMake構建工程的方式，由於大量使用第三方庫的話會致使環境配置麻煩，CMakeLists編寫複雜，爲此花費了不少時間。而不少庫其實只用到了功能的一小部分，徹底能夠本身實現，好比PBM和PGM圖片的讀寫，這個很簡單，我就直接本身寫了。到後面，須要用到json來定義場景文件的時候，我是依然選擇了本身寫json解析器。這真是已經費力不討好的事情，我花了不少時間編寫完善json解析器，到後面發現用json定義場景文件並非很方便，轉而又使用toml。先後一折騰，那些工做就至關於白乾了。

工程構建

我曾算是Linux和開源精神的簇擁，就連一個很小的程序都要寫個CMakeLists，時時刻刻注意着跨平臺。但如今讓我去寫代碼，我會堅決果斷選擇Windows和Visual Studio，由於Visual Studio實在是太方便了，特別是結合NuGet來管理第三方庫，簡直暢快無比，不再用手動去配置和管理第三方庫了。因此我如今是大膽使用第三方庫，只要這個庫是比較穩定的有人在維護的就好，好比如今LtRay中就用了glfw來顯示窗口、FreeImage來加載圖片、cpptoml來解析toml文件。效率就是生產力，在生產力面前，那些Linux情懷就免談了吧。

規範

代碼規範很容易解決，難的就是C++多範式帶來的選擇困難。同一個問題有無數種解決方法，而我每每是實現了一種，後來又發現不怎麼好，又回過頭來修改，就這樣反反覆覆不知道修改了多少次。期初代碼量不多還好，到如今幾乎全是改代碼了。

該不應用getter，setter？

我起初是恪守「類應該對外部只應該暴露接口函數」這一規則的，可是到後面發現這真是太繁瑣了，可讀性和可維護性都大大下降了。好比Point、Vector、Color這些類，只有三四個成員變量，並且這些變量是不受約束的，原本一個很簡單的struct Color{float r,g,b};結果用getter、setter包裝起來後，代碼真是變得囉嗦無比。我我的以爲對於簡單類使用這種getter、setter方式無異於掩耳盜鈴。

該不應用所有改用智能指針？

C++11中的智能指針確實很方便，但其實質仍是個資源管理的工具，若是把全部的指針都用智能指針代替，那就會使得資源的生命週期難以掌控。最好的方法就是隻在須要自動回收資源的地方使用智能指針，對於那些只是暫時借用對象的指針的函數，直接傳遞指針就行了。

C++入門並不難，但這些尋求「最佳實踐」的過程可能會永無止境。