今天来吐槽一下多业务协作的坑，最近一周几乎都杠在这些协作问题上。

首先有几个前提，一个是小程序A，一个父级小程序B，两个都是小程序，只是B中会有A的子包，这个做小程序开发的应该了解；另外就是多个业务了，模板和组件，模板偏UI，是公用的，组件偏流程，是自定义的。

问题1：我在调试小程序A的时候模板正常， 在调试B的时候模板始终不展示。

问题2：线上出现一个模板异常展示，不该展示的地方展示出来了；

问题3：有个组件在B小程序死活出不来。

我先说说问题一，A小程序有使用的模板，当然B也有了，这个模板在测试环境中是公用的，并且历史版本都存在，小程序调用的时候会根据模板下限进行拉取，拿到最近的版本，模板侧同学在开发调试的，但是我不知道他们调试的模板是跟当前的库文件不对应的，也就是说我不能使用他们的最新模板，所以当我下线最新版本模板，使用旧版本就没问题。

再来说下问题三，工程构建打包的时候会引用index.json，构建过程有这样一个功能，就是同样引用index，但是小程序B构建的时候会引用到index.B，最终发现，我的组件配置信息在index.B中是没有的，我猜测是第一天我在index中新增配置，第二天有人拉取master并新增了index.B，第三天我的代码才合并到master，这样他在code review的时候，两个文件都没问题，而我并不知道这个新增的配置，更不知道新增的配置里没有我新增的数据。

我没有说问题二，是因为问题2出现得比较早，当时是紧急修复的，等我经历问题1和3，才发现这个问题的原因是问题3引起的。

我把遇到的问题阐述出来，一方面确实想吐槽一下，在业务协作过程中，由于没有得到及时的信息共享，导致花费太多时间排查，而最终问题不在自己的业务，实在是头大，另一方面也是想通过这些经历，总结一下后面遇到问题的思路：
1、遇到问题的时候可以先思考可能的原因，这样会减少后面试的操作。但是通常这个比较难，因为大多数都是线上问题，一时间头脑发热，大家尽量吧；
2、大家可能也有这样的体会，越是诡异的问题，它的错误可能越低级。比如问题2，明明测试和上线都没问题，怎么突然组件没了，最终只是配置丢失造成的；
3、多留意相关业务的需求开发，这样可以在处理问题的时候多一些思路。如果我知道他们模板的改动，知道协作同学新增了配置的目的，可能这些问题都不会耗时这么多了。

寄语：当下互联网行业越来越卷，难免人性异动，希望同学能坚修技术，持正本心，将来就算分道扬镳亦是志同道合。