一次 - 编程 - 一流楼主

SQL专栏

SQL数据库基础知识汇总

SQL数据库高级知识汇总

最近一直在忙公司的一个SQL项目，好久都没有给小伙伴们写原创文章了。

趁着项目上线的空闲，给大家总结一下，在开发项目过程中遇到的一些问题。之所以说它是"失败的"项目，是因为遇到的一些问题是完全可以避免，即使最后按要求完成了任务需求。

项目背景
公司新上线了一套OA系统，希望将公司成本类的真实数据实时反应到报表上，并且使用新的OA系统来呈现。希望从各个角度监控公司在产品开发上所花的成本情况。

已有资源
成本类的部分数据已经存在于BI报表平台，每天都有更新，这些业务逻辑的指标可以直接从BI报表平台获取。

待开发内容
此次项目开发需求新增了不同时期的指标对比，部分指标的经营曲线。

遇到的问题
1、需求未明确
在项目开发过程中，因为是公司内部开发，没有明确的需求文档，都是依靠口口相传，或通过邮件等来确认指标定义。

可能有些同学对需求这方面不太了解，觉得我表述清楚，你做出来就是了呀。道理是这个道理，但是这个做出来的过程，如果有很多不确定的因素存在，那么就会极大的影响开发效率。

在每开发一个指标之前，总是需要人再三确认才能开始写代码。开发过程中还是遇到一个“我以为”是这样，而实际上并非是这样的指标。导致之前写的逻辑需求推翻重写。

2、整体未规划好
整个项目，看着不大，无非就是新增几个版本对比和一些历史记录曲线而已。正是由于这种想法，导致一开始没有一个整体的规划，代码写到哪里就是哪。

原本有一些可以复用的代码，最后还是一个个单独使用。导致后续因为修改代码逻辑，得一个一个的全部再修改一遍。

如果前期规划好，可以将能复用的代码做成视图，把其他逻辑需要的字段予以保留，在开发其他逻辑时直接使用该视图即可。

例如，有一个总成本费用，需要看到各个项目的总成本，各个区域公司的总成本，以及集团的总成本。从项目——>区域公司——>集团这是一个非常清晰的向上汇总逻辑。

只需要把项目的总成本做成视图，在取区域公司和集团的数据时，向上汇总项目的总成本即可。

但因为没有做前期规划，从一开始做成了从集团——>区域公司——>项目的逻辑，导致每一个都是独立的代码，这样就浪费了很多开发时间和后续的逻辑修改时间。

3、代码版本未控制
刚开始在没有遇到频繁的修改逻辑时，代码文件的名称直接按照代码的功能进行了命名。等到后来逻辑频繁的修改后，保存的代码文件越来越多，名称也越来越乱。因为没有使用版本控制，已经分不清最后正确的文件是哪个了。

说到底还是对项目开发不够重视，比较随性，当然这也有项目整体规划不足的原因。

如果在一开始就想到这些问题，给每个逻辑代码加一个版本编号就可以很好区分问题了，同时也可以做好版本对比。

可取之处
1、业务逻辑清晰，注释完整
不管业务逻辑如何修改，每次修改后的代码，都会在其中更新当前代码的功能和注释，以防下次更新时不知道代码片段意义。

但是与标准的代码声明还是有差别，标准的代码声明如下：
/*

代码功能：XXXX

作者：XXX

修改人：XXX

创建日期：XXXX

修改日期：XXXX

--代码片段功能注释

SQL代码

--代码片段功能注释

SQL代码 ...

由于整个项目由我负责，所以没有写作者和修改日期等内容。

2、代码执行效率较高
虽然开发的项目数据量较小，但是考虑到未来数据量增多带来的效率问题，代码统一做了优化处理。

最基本的优化处理方法就是减少返回的数据行，尽量保持代码的简洁。具体的优化方法可以查看公众号里的历史文章，这里就不赘述了。

3、将所有功能单独做成视图
由于要内嵌到OA系统，减少代码在OA系统上产生不可预见的异常，将报表的所有逻辑功能均建立为视图，OA系统直接查询视图即可返回所需的数据。

类似这种跨系统之间的数据传输，视图是比较好的规避异常的方式，在排查异常时只需检查视图上的查询逻辑即可。

反思
从上面的问题可以发现，一个优秀的项目：
首先要明确业务需求，磨刀不误砍柴工，需求不明确乃开发大忌；
其次需要有一个整体的规划然后才能实施，什么地方可以简化开发步骤，什么地方可以优化需要安排好；
最后要对代码的版本进行控制，不管是使用工具，还是在做一些小项目手动控制。

总结
从这个简单的项目中发现，我在开发方面能力尚可，但是项目管理方面的经验不足。导致开发效率较低，这也为以后开发新的项目做了一个很好的警醒。

从失败中总结，从失败中成长，希望这个“失败的”项目对你有所启发和帮助。

一次