从 IM 通信 Web SDK 来看如何提高代码可维护性与可扩展性

最新推荐文章于 2022-04-28 11:46:44 发布

黄Java

最新推荐文章于 2022-04-28 11:46:44 发布

阅读量339

点赞数

分类专栏：黄Java的地盘文章标签： javascript websocket

本文链接：https://blog.csdn.net/weixin_42899690/article/details/120586143

版权

在架构设计和功能开发中，代码的可维护性和可扩展性一直是工程师不懈的追求。本文将以我工作中开发的 IM 通信服务 SDK 作为示例，和大家一起探讨下前端基础服务类业务的代码中对可维护性和可扩展方面的探索。

本文不涉及具体的代码和技术相关细节，如果想了解 IM 长连接相关的技术细节，可以阅读我之前的文章：

大象 SDK 是美团生态中负责 IM 通信服务的基础服务。作为 IM 通信服务的 Web 端载体，我们对不同的业务线提供不同的功能来满足特定的需求，同时需要支持 PC、Web、移动端H5、微信小程序等各个平台。

不同的业务方需求和不同的平台对 Web SDK 的功能和模块要求都不相同，因此在整个 Web SDK 中有许多部分存在需要适配多场景的情况。

处理这种常见的场景，我们一般有以下几个思路：

针对不同的场景单独开发不同的基础服务代码。这种操作灵活性最强，但是成本也是最高的，如果我们需要面对 M 个业务需求和 N 个平台，我们就需要有 M * N 套代码。这个对于技术人员来说，基本上是一个不可能接受的情况。
将所有的代码全部聚合到一个业务模块中，通过内部的 IF ELSE 判断逻辑来自动选择需要执行的代码逻辑。这种方案不会出现相同代码重复编写的情况，同时也兼顾了灵活性，看上去是一个不错的选择。但是我们仔细一想就会发现，所有的代码都堆积到一起，在后期会遇到大量的判断逻辑，在可维护性上来看是一个巨大的灾难。同时，我们所有的代码都放到一起，这会导致我们的包体积越来越大，而其他业务在使用相关功能时，也会引入大量无用代码，浪费流量。

那么，我们在既需要兼顾可维护性，有需要保证开发效率的情况下，我们应该如何去进行相关业务的架构设计呢？

在我的设计理念中，有这么几个原则需要遵守：

针对接口规范编程，而不针对特定代码编程（即设计模式中的策略模式）。我们在进行架构设计时，优先判断各个功能和模块中流转的数据格式和交互的数据接口规范，这样我们可以保证在进行特定代码编写的时候，只针对具体格式进行数据处理，而不会设计到数据内容本身。
各模块权责分明，宽进严出。每个模块都是单一全责，暴露特定数据格式的 API&

关注