老手都知道「debugging」是书本很少涉及但是对生产力影响最大的编程手段。但在不断提高自身修养的过程中也听过大师告诫不要「program by debug」，令人时常前思后想不敢动手 coding 。反复调试时充满负罪感。
如果因为一句「不要 program by debug」就坚持敲代码之前要深思熟虑，那就是和自己过不去了。因为人并不擅长在不同层次进行通盘思考。花费很多精力思考的大计划在细节上必然充满逻辑漏洞。所以编程就是先让粗糙的代码在简单输入下勉强运行起来，然后这里紧一下「螺栓」，那里调一下「杠杆」，最终获得一个稳定的系统。所以恰恰就是要「program by debug」。如果重新思考这个问题，重点不在于是否让 debugger 成为 coding 的线索，而在于如何使用从 debugger 得到的信息，不应该用「头疼医头」的方式去修补问题，而是要从 debugger 暴漏出的现象扩展出一般化的问题，寻找一般化的解决方案。
大师的观点一定程度上和工具的发展程度有关。Debugging 是高度依赖工具的手段。工具永远有覆盖不到的地方，所以脱离 debuging 的慎重思考也总有不可替代的地位。不过工具发展之后，要让我们的头脑从工具成熟的领域中解放出来。
五六年前尝试学过 rendering ，还写过几篇《 OpenGL 随想 》，现在看来十分惭愧。除了熟悉基本概念之外，实际的练习都是浅尝辄止。那个时候我的印象是 GPU pipeline 的编程并不像大多数工程可以大量依靠 debugging 。今年公司给了去 SIGGRAPH 2016 的福利。为了不太辜负这次见闻，回来之后打算再进阶一次自己的 rendering 知识。总结一下前几次进阶夭折的原因，有一点在于只用下面这样的简单过程生成的模型。因为无聊而失去动力。所以我想这次要先花些力气让代码直接用上从网上下载的大量模型。
具体的目标定为 Wavefront OBJ 格式的 viewer。本着 program by debug 的精神，从网上找了几个 OBJ loader 库，然后给它们分别写些简单的测试代码来 debug ，看它们产生的结果是否好理解。然后选中 tinyobjloader 加到 Metal by Example 的例子里直接开始编码。每次 debugging 暴漏的问题的时候，不能只是把当前出错的这一个 OBJ 文件的情况糊弄过去，而是要考虑类似情况如何反映在所有的 OBJ 文件里。用点合理猜测，偶尔去查相关的 OBJ 标准，程序就一步一步的稳定起来。最后把例子一步步的 refactor 成现在的 Nuo Model Viewer 。
Parsing model 的构建诠释了 program by debug 的作用，但是这毕竟不算 rendering 本身。和几年前相比，GPU debugging 的工具也丰富多了。例如 rendering order 就不用费力猜了。
技术奇异点 
发表评论