Objective：事实
做了一些优化的小功能。其中有一个印象深刻的是关于效能的那张票。通过周五有一个 sql 分享课 以及老师的 sql 分享课，大致有了些思路去解。但是发现 sql 方面以及 index 等地方都使用的不错，单单是因为 a 表和 inner join 的 b 表量都很大。然后讨论时打算用只展示最近一周或者一段时间的记录来解决。但是后来老师帮忙写了结论，a 表 和 b 表都属于 user，但是 user 中却使用了 has_many :b, through: :a，完全没有这个必要了。直接 has_many :b 即可。这样就减少了 inner join 的速度。
Reflective：感受
老师挺厉害的，我解这个问题花了好几个小时从代码以及 sql 的层面分析，但最后都没有跳过「之前写的就是对的」这一层。当我没有想到时，老师结论出来了，还是很惊讶的。因为我没有想到哪里可以优化了，只能从业务上优化了，但是老师却想到了原因。
Interpretive：想法
我们几个在解这个问题的时候，都看到 inner join，也好奇哪里产生了 inner join，去 user 中也找到了这个 has_many through 的结构，但是我们都默认之前写的是对的，也没有想到可以直接建立关系这一层。所以，有时候并不能默认以前的代码就是正确的或是考虑周到的，不然之后来优化，就可能达不到效果了。感受还是听惊讶的，老师就能跳出这一层不受束缚。
Decisional ： 决定
下次再解票时，不要把之前写的就是对的作为前提。要跳出来看问题。
