技术奇异点

很多程序员自嘲「数学不好」。反过来看就是在憧憬基于数学理论写就的程序一定完全正确。其实并非如此。比如说，简单的 parser 可以严格基于有限态自动机和 LL(n) 理论，但写过的人都知道调试起来并不简单，即便充分测试也不能达到 100% 正确。

另一个例子是 3D renderer。无论是物理真实的 ray tracing 还是简单的 phong model，renderer 就是数学公式的代码实现。最近用 Metal by Example 的例子作为起点写程序。一开始还运行得不错。直到加上摄像位置的变换之后，near/far 平面会切掉在 view volume 里的模型。一开始也没在意，给 near/far 参数随便加上个余量凑合用。混了两个星期后偶然想到 Metal by Example 用的 projection 和 OpenGL 的一模一样，而 Metal 的 depth 范围不同于 OpenGL [1] 。在 Twitter 上向作者确认之后果然是这个问题。Metal by Example 经过了 15 个月的开发，出版也有一年左右。但是这个基本问题一直没有被发现。

软件开发的现状略带讽刺 —— 严格依据数学理论的程序反而缺乏有效的工具来验证其正确性。但这里其实也没什么讽刺性，因为数学本身的理论正确性也并非自动获得。一个新证明的正确性必需要经过其他数学家的人工验证，有时需要历时几年，甚至在最后才发现证明中的错误。数学的正确性是依靠数学界的「社交活动」达成的 [2] 。正如测试是软件开发的「社交活动」。

那么，数学理论是不是对软件质量没有帮助呢？也对也不对。数学理论并不能直接保证正确性，无法帮助发现错误。但是一旦发现了错误，数学理论可以帮助更快的修复软件。当我们在一个复杂的 ad hoc if-else 分支群里发现错误行为之后，很难立刻理清修复方案。而面对上文的 projection 错误，立刻就可以修正错误的参数。我把这种特性称为「可修复性」。可修复性和「正确性」不是一个层面的问题。其实软件开发的很多 best pratice 并非追求「正确性」，而是去提高「可修复性」。例如提高代码的可读性，以及我以前讨论的 MVC 模式的局限和突破，都是追求「可修复性」。经常听到很多团队讨论开发流程和实践的时候以「正确性」作为争论的立脚点，讨论怎么做才能节约测试成本，这样就走偏了。

「可修复性」不是「正确性」。也没有办法直接降低测试成本。但是「可修复性」是软件的一个隐形 spec。当错误被发现的时候，「可修复性」将一切争论局限在实现层面，避免了在设计层面的争论，更不会出现 feature vs. bug 的可笑争吵。「可修复性」还避免了修改中无意引入新的 bug。就目前的软件开发现状，我认为没有任何编程行为能有效提高「正确性」，那些能产生正确代码的程序员也无非是把代码丢给测试团队之前，自己先系统测试一番。一切编程本身的实践，都应该围绕「可修复性」来讨论。一切针对「正确性」的讨论，都应该交给测试领域。

脚注：

1. Metal 的 canonical view volume 是 2x2x1，它的 z-buffer 范围不超过 [0, 1] 。OpenGL 为 2x2x2 ，z-buffer 范围为 [-1, 1] 。
2. 当然，类似 Coq 这样的形式验证工具说明有可能改变这样的现状，但是距离实现仍然有一定距离。

老手都知道「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 就不用费力猜了。