背??景我在交接代码中进行操作删除数据库等操作。之前只是在网上听到的一个笑话，没想到上周遇到了，还亲自参与帮忙解决了。事情是这样的，一个老板接手了一个系统，可能是因为双方交接的过程中发生了一些不愉快的事情，对方没有提供源代码，只是做了一个生产环境服务器的镜像给对方。对方拿到镜像并恢复后，系统无法正常处理业务，于是找我帮忙查找原因。经排查，发现交接者对镜像进行了多次操作，多处删除核心数据和jar包操作。下面详细分析调查过程。由于在排查过程中只提供了镜像文件，所以是启动了哪些服务的问题。幸运的是，它是一个Linux操作系统。镜像恢复后，可以使用history命令查看执行了哪些命令，需要启动哪些服务。但是服务启动后，业务无法正常处理，很多业务处于中间状态。本来系统可以正常运行业务，做镜像后就不能恢复了吗？这很奇怪。所以查看项目（jar包或者war）文件，查看它们的修改时间。确实在文件的修改时间上发现了一些问题。发现在做镜像前两个小时，修改了项目底层多个项目依赖的jar包，另外修改了两个class文件。因此，他们专注于调查。先对修改后的两个class文件进行反编译，找出代码中可疑的地方。两个修改后的类中都有上面的代码。一开始我并没有太注意这段代码，但是我的直觉告诉我不对劲。一个查询业务怎么会有删除操作呢？这太不合理了。于是仔细阅读了上面的代码，发现上面红框中的代码无论何时执行，都会导致id=1。你看见了吗？问题出在三元表达式上。不管id是否为null，id赋值都是1，看到这里，我也觉得对方在关注了。为了隐藏这个目的，前面写了那么多没用的代码。但只有这个不是问题。毕竟，如果只删除id为1的值，也就只删除了一条记录，影响范围应该是有限的。然后反编译修改后的jar包，依次找到上面删除方法的底层实现，看到如下代码：前面传入的id=1是为了匹配where条件语句，传入id=1时，A条件where1=1的陈述成立。这个在mybatis中拼接多个条件语句的时候经常用到。结果是一旦执行完上述业务逻辑，就会触发删除T_QUART_DATA整表数据的操作。T_QUART_DATA表是用来存放触发定时任务的表达式的，到这里就明白了，为什么前面的业务跑不起来了，都处于中间状态。因为一旦业务逻辑中触发了开关，所有定时任务的cron表达式都会被删除，十多个定时任务全部挂起，业务开始运行。找到了问题的根源之后，再去解决也没什么大不了的。由于没有源码，要反编译原工程，然后修改修改的地方，有点困难。又是一波三折。本以为这个问题已经解决了，没想到第二天又出问题了，项目又跑不起来了。经过多方排查定位，感觉还是有定时任务才暗中操作。于是用linux的crontab命令查看是否有定时任务在执行，执行crontab-e或者crontab-l，果然看到有3个定时任务在执行。跟踪到定时任务执行的脚本中，明目张胆的命名为deleteXXX：在具体的脚本中，有如下操作：现在找出项目第二天运行不了的原因。原来linux的定时任务会把core的依赖包删除，然后重启服务。想要毁掉它真是煞费苦心。还好这个jar包前天已经反编译过了，也算是备份了。总结我本来以为程序员在代码中删库或者其他小把戏只是网上的笑话，出于职业道德或者个人素质一般人是不会去做的。没想到会出现这种情况，对方为了隐藏删除操作还做了一些小伪装，着实煞费苦心。如果你有这样的能力和胸怀，或许用它写出更好的代码或系统会更好。当然，我不知道他们在交接过程中发生了什么事，他们就这样对待曾经的伙伴。之所以写这篇文章，就是想让大家学会如何排查代码问题。毕竟要用到很多知识和技巧，但这并不是教你如何耍花样。不管怎样，起码的职业道德还是有的，这点我不接受反驳。
