上千行的 SQL 代码常见，且永不过时!
经历了大大小小的 MIS 系统，小到几人用的协作系统，几十人用的 OA 系统，到上千人用的 MES/ERP 系统，再到百万人用的电商系统，存储过程的影子在半个世纪以来从未淡出它的战场。我们几个 SQL 老玩家经常自吹， SQL 是半衰期最长的编程语言。玩会它不用担心失业。
上回我们说到如何去拆一个上千行的 SQL 存储过程，提到了四大步骤：理解代码，分拆代码，改写代码和保存代码。拆过无数的代码，从上千行缩减到 2 成，也组装过无数的代码，从上百行塞成了上千行，业务所需。见过最长的 SQL 代码超 5000 行，已简无所简，那就实事求是了。人有分分合合，有生命力的代码也一样。
但装和拆并不是一个逆反的过程!
1 理解业务：
你不可能写出一个没有业务逻辑的代码。充分理解业务逻辑对你有两个好处：一)写出可执行的并且可扩展的代码;二)主动了解业务将有利于职业生涯升级。***个好处肯定不言而喻，写代码写出颈椎病的程序员，不会意识不到代码的扩展性可以让你少跑多少趟医院，让你霸屏更多次王者。第二个好处可不是人人都意识到了。虽然 SQL 是最长职业生涯的编程语言，与其一起出现的 VFP 大概 90 后闻所未闻，但显然没人一辈子愿意鼓捣 CRUD 吧。玩吃鸡的同学把你的 iPhone X 放下，家里有矿没说你。
理解了业务你就成了整个应用生态中不可缺少的一环。信息化的目的不是写代码，最终目的就是为了利润。看二爷(邱岳)就知道这话没错。
2 快速实现：
很多朋友(包括我)有时候碰到需求，苦思冥想，想的是一口气把 SQL 从头到尾完整的，畅快淋漓的写出来。“Wow” 和漂亮的回车，就是憋着这口气的期待。
但现实无数次打了我的脸!
越是有这种想法，越是憋得时间很长才写那么一点。总觉得这里不好，那里不行，这里的变量名称写得不够爽朗，那边的 Pivot 写得不够优化。结果往往是一个上午就在那里纠结，什么都没完成。
你是不是也有类似的经历?不孤独
再说一次《巴黎评论》。村上春树、海明威、博尔赫斯，书里翻翻都是***遍爽快的写下去了，一旦写得卡壳了怎么办，束之高阁，明儿继续。所以我后来明白的事情，大家都可以猜得到了。先把业务实现了再说，命名规则，变量申明，事务控制以及性能优化，统统先放起来。写好 CRUD 交上***稿，存档，Over!
3 重构与测试：
如果仅仅到了第二步，就认为高枕无忧，那会死的很惨。你会成为别人口中的“猪一样的队友，坑货……”
《巴黎评论》中，村上春树提到他的小说经常修改 4 - 5 遍才交稿，而且编辑还需要修改。我们一遍过的 SQL 就免检了?这个时候再检查命名规则，变量申明，事务控制以及性能优化。直到满足 ACID 的最小单元的 代码块完整的归整到一个存储过程或拆解成多个可重复使用的存储过程中结束。
将所有的测试分支跑完测试，提交!
4 保存代码：
如果你的团队没有 git, SVN, TFS 这些 Source Code Version Control, 赶紧上一个。没有自动化部署工具，自己想办法整一个。到 9102 年了，别偷懒吧。
摸着你的良心，看看这个图，你都掌握了?
