5000行的 SQL 源代码，怎么读？

今天的小 C 很不在状态。昔日的她，一大早肯定不会愁容满面，似乎像是星巴巴没有喝够的样子，兴奋不起来！11:30 了，很少听到她 HHKB 落键的清脆声，一定是遇到难题了！

“怎么，今天的热焦玛少了点劲儿嘛，感觉？”我走近了小 C。

“L, 面对着满屏的 SQL，谁都会提不起精神啊。何况这近 5000 行的代码，怎么看得过来嘛！看了中间忘了开头，看到结尾，前面的全忘光了，好烦呀” 小姑娘抱怨起来也是毫不拖泥带水。

“哟，恭喜你，遇到这么极品的 sp 啊。在我的印象里面，经历了两次重构之后，上千行的代码，就那么几个，今天被你遇到了。我看看是哪个”

“原本我以为很简单的一个 AddUpdate, 谁想逻辑这么复杂，牵扯的表也太多了，其中几个表还有上百个字段，这都没法看了” 小 C 的鼠标满屏的乱走，看得我 300 度的眼睛，有些吃力。

“你这一行一个字段，是你自己设置的吧，其实不需要那么格式化，反而更简单。你看啊，一个 Insert 被几十个字段隔成了两屏，容易造成思维停顿。两行搞定的事情，做复杂了。还显得代码量大，失去耐心。”

“那我还原成原先的格式，也有近 3000 多行，还是多啊”

“这阅读源代码啊，是有技巧的。我可以分享三点给你。分别是，通读，联想，批评。”

“第一点，通读，非技术性的通读。首先告诉自己，一遍读完就能通晓5000行代码细节，是不可能的事情。读代码前，耐心先行。接着就是开始第一遍的阅读。此时的代码走读，我们不停留在具体的技术末节上，比如 unpivot 的语法是怎么样实现的，为什么有里三层外三层的嵌套，为什么这里用了动态 SQL 去拼接。再比如，XML 的节点铺设，为什么要这么定义，共有多少层。这些留在最后。”

“我们在走读代码的时候，尤其是第一遍，首先要理清的是业务的数据流，比如订单是如何触发的，分别涉及到哪些主体，人，物，财，时间。知道这些数据流分别存在哪些表里，存储的先后顺序是什么，会记录哪些日志。我们的 sp 逻辑结构相对简单，一个事务一个存储过程。所以第一遍，通读，越快了解所有涉及到的业务过程，最重要。你也可以在手边，画画流程图，帮助记忆。”

看着小 C 若有所思的眼神，分明能感觉到她脑子里抽象的拧巴，因此顺手我画了一张上面的流程图。“第一遍走读代码，你能清晰的画出类似上面的图，知道这些数据存在哪里，就足够了。”

“嗯，原来是这样，难怪我老是连接不起来，看过了，脑子里留不下印象！那第二点呢？”

“第二点，需要联想，也就是想象力。看完第一遍，不要急着看第二遍，就在脑子里，回想第一遍的过程。把你认为创建一个订单需要记录的信息给标出来，尽可能详细的在流程图上标准细节，就好比人，在什么时候需要记录人的信息，需要检验人的信息；再比如货，什么时间段，要检查货的库存，要记录货的哪些属性，单价还是 SKU，怎么更新货的库存，更新失败了怎么办？”

“如果你看到长篇的 SQL ，还只停留在脑子里，不靠谱。工作记忆永远只有 15 分钟。读完一遍后，你被叫去开个会，回来你就可能记不清了。所以及时的倾倒出来你刚才读到的 SQL，多问问自己数据是怎么流转下来的，画好流程图，标准自己的想法，越清晰，问题越多，越有利下一遍的阅读...”

"我知道了，我知道了，就是带着问题，主动去寻找答案！"

“理解到位，就是这样。给自己找问题，千万别一遍看完代码，什么都没留下来。接着，你可以去阅读第二遍，第三遍，甚至是第四遍了”

"那还有第三点呢？" 小 C 似乎来劲了。

“第三点最重要，批评。如果你对读到的代码，没有任何要抱怨，没有任何疑惑，那说明还没理解到位。当你看到这些代码，你认为嗯，这段写的很好，这段写的在理，都是这些溢美之词，那完了，你没深入。你可能对 unpivot , cross apply, openXML, OffSet 读到真正实战版代码而感到兴奋，觉得这段 sp 就写的很好，那对 SQL 的认识就太肤浅了。”

“新闻界，会有很多评论家，对重大新闻做二次剖析，比如曹林，《时评写作十讲》的作者，擅长对每篇新闻做双面解析。既讲述原新闻作者的报道手法，也评价原作者的目的与动机，最后还补充自己的观点，非常有意思。”

“在我们编程这个圈子，也有很多书，专讲这方面的。我给你推荐几本吧，《编程珠玑》，《CLR Via C#》, 尤其是 SQL 数据库方面，《数据库索引设计与优化》，《Oracle 优化日记》，《T-SQL Querying》,《T-SQL 性能调优秘籍-基于SQL Server 2012 窗口函数》”