记录一次填坑的通过

若是你写的代码不通过正式上线运行的过程，你永远不知道本身写得东西有多优秀或者多糟糕。

此次项目本身是从半路参与的，在项目到正式上线前 小组人员被调组或者离职 这个项目只有两我的了，我是其中之一

近期项目正式大批量客户切入，与此同时，伴随着的是各类问题的出现。

首先 

被反应的是性能问题，导入数据上千条特别慢。（从这个时候我就进入了优化别人代码的痛苦历程，也就是填坑的过程。）

for 套着 for 多是业务须要，但每个for里都执行一次数据库操做 这是大忌 。链接一次数据库耗时，大量的数据很快就会把数据库链接资源耗尽，可能会出现事务套着事务，出不来就会致使数据库死锁

解决办法:在for里组织数据，出for再去批量执行。若是有不得以的数据库操做，有一句也是不要紧的。

还有一方面影响速度的就是 数据校验，与所有的数据进行对比校验这个不多 通常都是对数据库中部分符合条件的数据进行对比校验，咱们这个项目是后者，因此无需查询所有（随着数据的不断增长 这种查询所有的操做会愈来愈慢），改改改。。

通过测试 刚开始导入21秒 优化后8秒，这个速度比较能接受了，不过还不是很快。由于业务的复杂度很高，校验的很严格，暂且优化为这样。

其次

代码逻辑问题。业务需求不变，能够有多种方式实现，最终都能达到想要的结果。每一段代码逻辑也是一我的大脑对业务的分析结果，分析的清晰 写出来的一目了然

在我优化的过程当中 发现不少重复代码，甚至是重复的保存数据操做，虽然这些不会形成灾难，但也是影响性能的一部分。这样的程序 读起来很伤脑，若是不彻底的读懂看明白 那修改的过程也是出bug的过程。当彻底读完以后 发现不少是不必的，彻底是冗余  就感受太坑。

最后

代码规范 驼峰命名就不说了， 注释聊聊无几，致使维护起来很吃力

总结：为何这些问题在项目测试过程当中没有发现？

1：由于项目特殊 没法彻底按线上作测试

2：没有进行严格的code review，这个多是项目进度很紧，开发人员又都不是0经验 

还记得本身第一次参与code review的时候还有点抵触，由于惧怕犯错，如今想一想真好笑，不纠正本身的错误 那就不会有进步。

总之：

填坑结束！

要对本身写得每一行代码负责到底，不给本身挖坑，不给别人留坑，多读书，不断提高本身。。。