博客

如果你写的代码不经过正式上线运行的过程，你永远不知道自己写得东西有多优秀或者多糟糕。

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

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

首先

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

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

解决办法:在for里组织数据，出for再去批量执行。如果有不得以的数据库操作，有一句也是没关系的。

还有一方面影响速度的就是 数据校验，与全部的数据进行对比校验这个很少 一般都是对数据库中部分符合条件的数据进行对比校验，我们这个项目是后者，所以无需查询全部（随着数据的不断增加 这种查询全部的操作会越来越慢），改改改。。

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

其次

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

在我优化的过程中 发现很多重复代码，甚至是重复的保存数据操作，虽然这些不会造成灾难，但也是影响性能的一部分。这样的程序 读起来很伤脑，如果不完全的读懂看明白 那修改的过程也是出bug的过程。当完全读完之后 发现很多是没必要的，完全是冗余  就感觉太坑。

最后

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

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

1：因为项目特殊 无法完全按线上做测试

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

还记得自己第一次参与code review的时候还有点抵触，因为害怕犯错，现在想想真可笑，不纠正自己的错误 那就不会有进步。

总之：

填坑结束！

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