开发的贴身保镖：清晰多角度的验证程序正确性

昨天一个小小的习惯，可以说是避免了一个潜在会很难处理的资源释放的问题。
就是新开发的dx12的资源管理会统一在deferred delete queue中做资源的最终释放，中间会有基于fence的管理。
所以进入程序唯一释放的入口，这里就采取一个常用的使用变量来标识出这是唯一的释放点。
在resource的destructor中assert是否在释放的zone里面。
然后昨天在修改另外一个地方的资源释放的机制的时候，就因为ref count管理的问题触发了这个assert，也就及时的看到了这个问题。
其实最近在构建新的系统的时候，类似的log，抓取的capture等等都有很多帮助。
这里也小结下程序处理的思路。

整体的清晰

如在之前文章中所言，整体清晰一直是黄金法则是银弹，从设计到实现思路始终要在整体上保持一个清晰的状态。
在清晰的前提下，直接会带来开发上两个可能：

• 可以在个个阶段，使用log，数据check，assert等方式，设下大量的检查点，提供提单纯的跑游戏多得多的点来检查数据
• 在使用pix等检查工具的时候，看capture的数据直接就知道哪里对哪里不对

白盒的去检查问题，多角度检查问题

大的思路可以保证，但是在数万行的代码实现中保持程序实现的正确性，这对人类来说就太困难了。
unit test等等都不是银弹。
就需要建立在对程序的准确理解的情况下，在多个角度尽可能多的覆盖，白盒的去检查所有的数据。
这部分在不影响性能的前提下，可以说是多多益善了。