搞了快一年的接口刚稳定下来, 上下游接口的人离职了,新来的人居然从新搞了一套接口,让我适配重新开发,沉淀打磨了一年的代码怎么可能动。pk一番之后决定在原有接口上把新增数据直接交给下游处理。以后,处理接口一定把外部风险隔离了,非自己的业务一定不要去耦合,否则一旦调整,改动可能非常的大。
---
ps:负责这个接口的人已经离职了3个了,还在持续修改接口中...
----
负责接口的人又又离职了,新人完全不知道老接口的逻辑,说看不懂代码,不敢动老接口的参数,新功能和bug都在新接口里解决, 幸好我没参合接口逻辑,直接把上游json对象转到下游,他们之间的对象属性增删修改可以略过我,我就没被牵扯进去了
----
202104
最近有一个中间转化的处理逻辑需要做,但是上下游都以不是自己的业务范围推脱。后来分析了代码开发的业务知识前提,以后修改的难易,业务逻辑的集中,生产出现问题的定位维护成本,最后由领导拍板让了解业务的一方来做,另一方配合提供不含业务的原始数据。我觉得这样很好,这样表面上是一方把开发任务推给另外一方,实际上对两方都有很大好处,只有了解业务的一方参与业务,他不需要和其他人沟通,降低了双方沟通以及后期的维护定位成本,减少了扯皮。而且业务集中在他那里,新人一看就懂,比分别放两个项目里,大家都一知半解好多了。这种非自己业务的工作一定要让了解业务的一方做,这对双方都有很大好处,并不是简单的推脱,而且真正了解了开发沟通维护成本的优选。