多维扩展点的思考与设计——解决渠道、产品增加引发的腐化问题

最新推荐文章于 2024-03-23 22:36:25 发布

skyesx

最新推荐文章于 2024-03-23 22:36:25 发布

阅读量617

点赞数 2

本文链接：https://blog.csdn.net/skyesx/article/details/91358061

版权

本文讲述了小码同学在面对业务渠道和产品增加导致的代码腐化问题时，如何通过公用逻辑下沉和扩展点机制进行重构。通过引入扩展点，实现了业务逻辑的清晰分离，避免了IF-ELSE泥潭，同时解决了多维度扩展的冲突问题，提升了代码的可维护性和并行开发效率。

摘要由CSDN通过智能技术生成

随着业务渠道及产品的增加，你的代码是否开始陷入IF-ELSE组成的泥潭，难以脱身？
在这里插入图片描述 ### 持续增加的渠道特性
小码同学一来到新公司，就负责起了一个新开始，但具有无限想象空间的后台开发项目。就像所有的互联网项目一样，业务变化极其迅速，为了减少初期试错成本，小码同学选用了流行、便捷的贫血模型，也就是Service+DAO/RPC结构，做了简单的关注点分离——业务以及基础设施（存储/远程服务）的分离。

业务很给力，主要流程模式已逐渐成型，同时也增加了很多的营销渠道，有公司内部的 App、有公众号、小程序、H5，也有各类外部的合作伙伴的渠道，小码同学一直都在高负荷地工作着，完全来不及思考要怎么优雅地解决这些渠道增加带来的问题。然而，每个渠道会有一个渠道相关的小特性，这意味着在登录、注册、做业务等等各个Service里，每增加一个渠道时，都要增加一段关于渠道判断的IF-ELSE判断语句。量变引起质变，当渠道加到近十个时，小码懵逼了，理清代码逻辑脉络变得极为困难，因为看一遍代码，需要将要受到近十个不同渠道分支代码的干扰。同时代码也变得难以并行开发，多个渠道的拓展会因为同一个Service的修改而更容易发生冲突。

在这里插入图片描述
其实这里小码可能会采取另外一种做法，陷入另外一种困境，小