🧱 和一个外包开发团队的对接经历：一次推送错误的排查记录

最近和一个外包开发团队对接，发生了不少让人头大的事情。今天实在忍不住，想把其中一件事记录下来，算是个小小的吐槽，也顺便复盘一下整个过程。

我们和 JG 企业有合作，他们是做影像系统的，我们负责提供底层系统支持，对接的是他们的外包团队。我们的角色是乙方，他们是丙方，除了开发工作，他们也协助我们做部分实施。

🧩 整体印象

刚开始接触的时候，外包团队给我的第一印象并不太好：

• 开发经验看起来偏少
• 沟通方式比较直接，甚至有些生硬
• 系统一出问题就直接 @ 我，连个背景说明都没有

刚开始开发接口那阵子，每天早上还会来催进度。有一次去客户现场，对方还直接告诉我要 “8 点 30 之前到”，语气挺强硬的。

其实这个事情完全可以灵活处理，只需要提前和客户沟通一下，在门口打个电话就能进去。虽然都是小事，但当这样的沟通方式频繁发生的时候，确实会让人感觉压力比较大。

🛠️ 第一个问题：推送报错排查

我负责的工作其实比较简单，就是：

定时将订单信息推送到他们的系统，他们生成在线浏览页面。
所以这部分是用定时任务跑的，需要做 增量推送。

有一天，对方在现场切换了一个环境，然后就发消息给我说推送失败了。

💬 对话过程（第一天）

他：
老师，有个报错，还需要您那边看一下。

（发来一张截图，日志里显示的大体报错是 “找不到推送表”）

我：
这个好像不是代码的问题，更像是没有那个表？

他：
有这个表。

我：
那你把具体的错误信息发一下。

他：
我拍照给你。

我：
能不能把完整日志发一下，尤其是你截图那个地方。

（他发了完整的日志，确实是查不到表）

我：
这个报错其实很明确，是在查一个叫 SYNCDATE 的表，这段代码一直没变过，之前也没出过问题。
你确认一下当前环境连的是哪个数据库？

他：
连的是这个库。

于是我发了段代码截图，解释逻辑：要么没表，要么连错库了，catch 里也没特殊处理，理论上不会报错。

他：
我这边换了一个环境就可以推送成功了。

🔁 第二天继续：重复追问

这是第一天晚上 7 点的事，我本以为已经结束了，结果 第二天一早又来了：

他：
老师，昨天那个推送错误还是想确认一下怎么解决。

我：
我这边看代码没问题。你可以试试把表删掉再跑一遍看看。
（我还引用了昨天的代码截图）

他：
怎么删表？我还没删过表……

（还打了电话过来，我没接。心里多少有点担心他真去误删库）

他：
我用 SQL 把数据删除了，还是报错。

我：
你用的是 DELETE 吧，那只是删了数据，表还在啊……

他：
不能用吗？

他：
我没重建表，报错还是一样。

（继续发日志）

我：
这个报错就是 “找不到表”。

他：
那我再建一下表。

我：
建好后，用 小写表名 查一下，有些 DM 数据库是大小写敏感的。

他：
好。

他：
我用了小写，还是这个错。

我：
那你能查出这个表的数据吗？

他：
可以查出来。 9:28
我：
我感觉你就是 连错库 了吧。

9:40 他：
我刚问了一下，确实是连错数据库了……

我：
行，确认就好。

其实在一开始我就怀疑他连错库了，但他当时非常坚定地说“没有”，我也不好直接下结论。只是没想到这事绕了一大圈，最后还是库连错了，但是真的也花了我好长时间，主要是也真生气，我觉得一个开发也不能这样吧，特别还不是我们的开发，我都怀疑他们领导把他扔过来让我带来的。。而且他这样不是一次两次了，每次都言之凿凿的说自己这边没问题，然后就让我排查，排查完了发现就是他的问题。。。 下午发一下第二件事，第二件事让我今天上午气够呛。