本文转载自微信公众号《关于SQL》，作者是关于SQL的。转载本文，有关SQL公众号请联系。小C今天很不正常。以前，她绝对不会一大早就一脸难过的样子，好像星巴克还没喝够兴奋似的！现在是11点30分，她难得听到她的HHKB键掉落的清脆声响，一定是遇到问题了！“怎么，今天的热娇妈，感觉有点不精神啊？”我走近小C。”L，面对满屏的SQL，谁也提不起精神来，更何况，这近5000行的代码，你怎么看得见呢！看了中间就忘了开头，后面的都忘了以前看到结尾的时候。太烦人了。”小姑娘毫不马虎地抱怨道。“嘿嘿，恭喜你，遇到了这么牛逼的sp，印象中，重构了两次，也就几千行代码，今天就遇到了，我看看是哪一个。”心想是一个非常简单的AddUpdate。谁能想到逻辑这么复杂，涉及的表也太多了。有的表有几百个字段，我都看不懂。”小C鼠标满屏走来走去，能看到我300度的眼睛，有点吃力。“你这行有一个字段，你自己设置。其实不用那么格式化，只是更简单。你看，一个Insert被几十个字段分成两屏，很容易造成思维停顿。两条线就做好了。做起来很复杂。好像代码量也很大，有点不耐烦了。”“然后我把它恢复成原来的格式，有将近3000行，还是很多的。”“阅读源代码是一种技能。我可以和你分享三点。他们是通读、联想、批评。”“第一点是通读，非技术性的通读。首先，告诉自己，5000行代码的细节，读一遍是不可能看懂的。阅读代码之前，先耐心等待。然后开始第一次阅读。这个时候我们不会停留在具体的技术细节上，比如unpivot的语法是怎么实现的，为什么里面嵌套三层，外面嵌套三层，这里为什么要用动态SQL来拼接。再比如XML节点铺设，为什么要这样定义，一共有多少层。这些留在最后。”“我们在看代码的时候，尤其是第一次看代码的时候，首先要了解清楚的是业务的数据流，比如订单是怎么触发的，涉及到哪些主体、人、事、钱、时间。知道这些数据流存储在哪些表和表中，存储的顺序是什么，会记录哪些日志。我们的sp逻辑结构比较简单，一个事务一个存储过程。所以第一次，通读一遍，越早理解涉及的所有业务流程，最重要。也可以随手画个流程图帮助记忆。“看着小C若有所思的眼神，我能明显感受到她脑子里抽象的曲折，所以我在上面画了一张流程图。”第一次看代码的时候，可以清楚的画出像上图这样的东西，知道数据存在哪里就够了。“嗯，原来是这样啊，难怪联系不上，看完了，脑子里怎么也留不下印象！第二点呢？””第二点需要联想，也就是想象。读完第一遍后，不要急着看第二遍，脑子里回忆一下第一遍的过程。把你认为需要记录的信息标记出来创建一个订单，把流程图上的细节尽可能的规范化，就像人一样，什么时候需要记录人的信息，就需要查人的信息；再比如货物，什么时候分节，要查库存商品的属性，记录商品的哪些属性，单价还是SKU，如何更新商品的库存，更新失败怎么办？”光谱。工作记忆只有15分钟长。看了一遍，叫你去开会，回来可能不记得了。所以及时把刚看的SQL倒出来，问问自己数据是怎么流下来的，画个流程图，把自己的思路规范一下。越清楚，问题越多，对接下来的阅读越有好处……”“我明白了，我明白了，我只是带着问题主动找答案！”“明白了到位了，就是这样。自己找问题，不要一遍一遍的看代码，什么都不剩。然后，你可以看第二遍，第三遍，甚至第四遍。”“那第三点呢？”小C似乎很兴奋。“第三点最重要，批评。如果你对你阅读的代码没有任何抱怨或疑惑，那说明你还没有看懂它。当你看到这些代码的时候，你就想，嗯，这一段写的好，这一段写的好，就是这些恭维，那就完了，你没深入。您可能会对unpivot、crossapply、openXML、OffSet感到兴奋，并阅读代码的真实版本。如果你觉得这个sp写的很好，那你对SQL的理解就太肤浅了。》在报刊上，会有很多评论家会对重要的新闻做二次分析，比如?的作者曹林，就擅长对每条新闻做双面分析。不仅讲述了新闻原作者的报道方式，还评价了原作者的目的和动机，最后加入了自己的观点，非常有趣。”“在我们的编程圈子里，也有很多专门讲这方面的书。给大家推荐几本书，《编程珠玑》，《CLR Via C#》，特别是SQL数据库，《数据库索引设计与优化》，《Oracle 优化日记》，《T-SQL Querying》，《T-SQL 性能调优秘籍-基于SQL Server 2012 窗口函数》”“这些书都很基础，看了不止一遍.可以帮助你快速提高内功。而且，这本书的好处是作者就像一个代码评论家，告诉你为什么SQL或者代码这样写，没有那样高效，背后的原理是什么。这些是您在分析具体代码时可以学到的真正有用的东西。我们应该在任何一段SQL中找到可以学习的东西。最好找出这段代码的设计弱点，比如子查询嵌套太多，不够简洁；比如过滤条件不够优化，需要重构代码。三分，批评的本质。“又是推荐书，上次推荐的那本我还没看呢。””“书在用，方恨少。“
