写好上千行的 SQL 存储过程

合，有生命力的代码也一样。

但装和拆并不是一个逆反的过程!

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 年了，别偷

（编辑：开发网_郴州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!