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++入门并不难，但这些寻求“最佳实践”的过程可能会永无止境。