从业务开发到业务开发的思考

最近业务上遇到一些问题，引发了我的一些思考。

---

前言

有这样一个场景，当你需要和外部系统交互的地方有很多时，一般都是你先落表，然后推送给外部系统，这时实现方式你该怎么选择？是让业务方自己去与外部系统交互，还是在落表的地方实现几个统一的方法让特定的人去做推送这一块的业务。

---

我们遇到的困惑是这样的，我们的业务中有库存信息，但是有另外一个系统相当于我们的缓存面向用户提供下单服务，我们库存的变更需要实时推送给这个另外的系统。这时我们重构系统实现的方式就是让有变更库存的地方自己去推送给这个外部系统，后来实践了一段时间，发现推送给外部系统的地方推送的错误太多，于是外部系统想要给我们对账，这时我们我们推送给外部系统的地方分散在各个业务中，对账实现难度很大，需要联系各个业务模块。原本与外部系统交互时设计的很复杂，然后各个业务都需要自己去了解如何和外部系统交互细节，但是随着新人的增多，理解的成本增大，这时这一块业务变得很是棘手。所以这里我的建议是与外部系统交互尽量做成统一推送，这样无论是后期和外部系统的对账，还是各个业务了解与外部系统交互的细节成本都会大大降低。

总结

这里各个业务去与外部系统交互，难免造成各个系统的业务开发人员需要清楚的了解与外部系统交互的细节，而如果需求迭代很快，新人很多，这时就会造成了解这一块业务的维护和迭代难度加大，而如果做在统一的地方，这样就可以与外部系统交互的成本变低，节约了各个业务去了解与外部系统推送的逻辑。总之这样做，有弊有利，选择的方向不同面临的结果将会很大的不同。最近我总是在想，一个好的方案设计必须要考虑一点进去，那就是实现这个方案的开发人员的能力，你设计方案时尽可能的要考虑开发人员如果不给力这时怎样设计好一些，怎么降低由于开发人员不给力带来的问题。