2021-01-08随感

搞了快一年的接口刚稳定下来, 上下游接口的人离职了,新来的人居然从新搞了一套接口,让我适配重新开发，沉淀打磨了一年的代码怎么可能动。pk一番之后决定在原有接口上把新增数据直接交给下游处理。以后，处理接口一定把外部风险隔离了，非自己的业务一定不要去耦合，否则一旦调整，改动可能非常的大。

---

ps:负责这个接口的人已经离职了3个了,还在持续修改接口中...

 

----

负责接口的人又又离职了,新人完全不知道老接口的逻辑,说看不懂代码,不敢动老接口的参数,新功能和bug都在新接口里解决, 幸好我没参合接口逻辑,直接把上游json对象转到下游,他们之间的对象属性增删修改可以略过我，我就没被牵扯进去了

 

----

202104

最近有一个中间转化的处理逻辑需要做，但是上下游都以不是自己的业务范围推脱。后来分析了代码开发的业务知识前提，以后修改的难易，业务逻辑的集中，生产出现问题的定位维护成本，最后由领导拍板让了解业务的一方来做，另一方配合提供不含业务的原始数据。我觉得这样很好，这样表面上是一方把开发任务推给另外一方，实际上对两方都有很大好处，只有了解业务的一方参与业务，他不需要和其他人沟通，降低了双方沟通以及后期的维护定位成本，减少了扯皮。而且业务集中在他那里，新人一看就懂，比分别放两个项目里，大家都一知半解好多了。这种非自己业务的工作一定要让了解业务的一方做，这对双方都有很大好处，并不是简单的推脱，而且真正了解了开发沟通维护成本的优选。