精益求精！记一次前端业务代码的优化探索

逃离我推掉我的手 2022-09-11 05:10 168阅读 0赞

> 关键词：需求实现、设计模式、策略模式、程序员成长

### 本篇文章由淘系新人喜橙同学撰写。 ###

### 承启： ###

本篇从业务场景出发，介绍了面对一个复杂需求，拆解重难点、编码实现需求、优化代码、思考个人成长的过程。

*  会介绍一个运用**策略模式**的实战。
 *  需求和编码本身小于打怪升级成长路径。
 *  文中代码为伪代码。

### 场景说明： ###

需求描述：手淘内“充值中心”要投放在饿了么、淘宝极速版、UC浏览器等集团二方APP。拿到需求之后，来梳理下“充值中心”在他端投放涉及到的**核心功能点**：

*  通讯录读取 不同客户端、操作系统，JSbridge API实现略有不同。
 *  支付 不同端支付JSbridge调用方式不同。
 *  账号体系：集团内不同端账号体系可能不同，需要打通。
 *  容器兼容 手淘内采用PHA容器，淘宝极简版本投放H5，饿了么以手淘小程序的方式投放。环境变量、通信方式等需要兼容。
 *  各端个性化诉求 极速版投放极简链路，只保留核心模块等。

### 解决方案 ###

需求明确了：充值相关核心模块，需要兼容每个APP，本质是提供一个**多端投放的解决方案**。那么这个场景如何编码实现呢？

#### 1、方案一 ####

首先第一个想法????，在每个功能点模块用if-else判断客户端环境，编写此端逻辑。下面以获取通讯录列表功能为例，代码如下：

// 业务代码文件 index.js
    /**
     * 获取通讯录列表
     * @param clientName 端名称
     */
    const getContactsList = (clientName) => {
      if (clientName === 'eleme') {
        getContactsListEleme()
      } else if (clientName === 'taobao') {
        getContactsListTaobao()
      } else if (clientName === 'tianmao') {
        getContactsListTianmao()
      } else if (clientName === 'zhifubao') {
        getContactsListZhifubao()
      } else {
        // 其他端
      }
    }

写完之后，review一下代码，思考一下这样编码的利弊。

**利**：逻辑清晰，可快速实现。

**弊**：代码不美观、可读性略差，每兼容一个端都要在业务逻辑处改动，改一端测多端。

这时，有的同学就说了：“把if-else改成switch-case的写法，把获取通讯录模块抽象成独立的sdk封装，用户在业务层统一调用”，天才！动手实现一下。

#### 2、方案二 ####

核心功能模块，抽象成独立的sdk，模块内部对不同的端进行兼容，业务逻辑里统一方式调用。

/**
     * 获取通讯录列表 sdk caontact.js
     * @param clientName 端名称
     * @param successCallback 成功回调
     * @param failCallback 失败回调
     */
    export default function (clientName, successCallback, failCallback) {
      switch (clientName) {
        case 'eleme':
          getContactsListEleme()
          break
        case 'taobao':
          getContactsListTaobao()
          break
        case 'zhifubao':
          getContactsListTianmao()
          break
        case 'tianmao': 
          getContactsListZhifubao()
          break
        default:
          // 省略
          break
      }
    }
    
    // 业务调用 index.js
    <Contacts onIconClick={handleContactsClick} />
    
    import getContactsList from 'Contacts'
    import { clientName } from 'env'
    const handleContactsClick = () => {
      getContactsList(
        clientName,
        ({ arr }) => {
          this.setState({
            contactsList: arr
          })
        },
        () => {
          alert('获取通讯录失败')
        }
      )
    }

惯例，review一下代码：

**利**：模块分工明确，业务层统一调用，代码可读性较高。

**弊**：多端没有解藕，每次迭代，需要各个端回归。

上面的实现，看起来代码可读性提高了不少，是一个不错的设计，可是这样是最优的设计吗？

#### 3、方案三 ####

熟悉设计模式的同学，这时候可能要说了，用**策略模式**啊，对了，这个场景可以用策略模式。这里简单解释一下策略模式：策略模式，英文全称是 Strategy Design Pattern。在 GoF 的《设计模式》一书中，它是这样定义的：

> Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

翻译成中文就是：定义一族算法类，将每个算法分别封装起来，让它们可以互相替换。策略模式可以使算法的变化独立于使用它们的客户端（这里的客户端代指使用算法的代码）。

难免有些晦涩，什么意思呢？我个人的理解为：策略模式用来解耦策略的定义、创建、使用。它典型的应用场景就是：避免冗长的if-else或switch分支判断编码。

下面看代码实现：

/**
     * 策略定义
     */
    const strategies = {
      eleme: () => {
        getContactsListEleme()
      },
      taobao: () => {
        getContactsListTaobao()
      },
      tianmao: () => {
        // 省略
      }
    }
    /**
     * 策略创建
     */
    const getContactsStrategy = (clientName) => {
      if (!clientName) {
        throw new Error('clientName is empty.')
      }
      return strategies[clientName]
    }
    /**
     * 策略使用
     */
    import { clientName } from 'env'
    getContactsStrategy(clientName)()

策略模式的运用，把策略的定义、创建、使用解耦，符合**设计原则**中的**迪米特法则（LOD）**，实现“**高内聚、松耦合**”。当需要新增一个适配端时，我们只需要修改策略定义Map，其他代码都不需要修改，这样就将代码改动**最小化、集中化**了。

能做到这里，相信你已经超越了一部分同学了，但是我们还要思考、精益求精，如何更优呢？这个时候单从编码层面思考已经受阻塞了，可否从工程构建角度、性能优化角度、项目迭代流程角度、后期代码维护角度思考一下，相信你会有更好的想法。

下面抛砖，聊聊我自己的思考：

#### 4、方案四 ####

从工程构建和性能优化角度出发：如果每个端独立一个文件，构建的时候shake掉其他端chunk，这样bundle可以变更小，网络请求也变更快。

> 等等... Tree-Shaking是基于ES静态分析，我们的策略判断，基于运行时，好像可能没什么用啊。

方案三使用策略模式来编码，本质是策略定义、创建和使用解藕，那可否使用刚才的想法，把每端各个功能模块兼容方法聚合成独立module，从更高维度，将多端业务策略定义、创建和使用解藕？

> 思考一下这样做的收益是什么？

因为每个端的适配，聚合在一个module，将多端业务策略解藕，某个端策略变更，只需要修改此端module，代码改动较小，且后续测试链路，不需要重复回归其他端。符合“高内聚、松耦合”。

代码实现：

/**
     * 饿了么端策略定义module
     */
    export const elmcStrategies = {
      contacts: () => {
        getContactsListEleme()
      },
      pay: () => {
        payEleme()
      },
      // 其他功能略
    }
    /**
     * 手淘端策略定义module
     */
    export const tbStrategies = {
      contacts: () => {
        getContactsListTaobao()
      },
      pay: () => {
        payTaobao()
      },
      // 其他功能略
    };
    // ...... （其他端略）
    /**
     * 策略创建 index.js
     */
    import tbStrategies from './tbStrategies'
    import elmcStrategies from './elmcStrategies'
    export const getClientStrategy = (clientName) => {
      const strategies = {
        elmc: elmcStrategies,
        tb: tbStrategies
        // ...
      }
      if (!clientName) {
        throw new Error('clientName is empty.')
      }
      return strategies[clientName]
    };
    /**
     * 策略使用 pay
     */
    import { clientName } from 'env'
    getClientStrategy(clientName).pay()

代码目录如下图所示：

![8f51f73503fba27ef5ccbc35ba45daa6.png][]

index.js是多端策略的入口，其他文件为各端策略实现。

> 从方案四的推导来看，有时候，判断不一定是对的，但是从多个维度去思考，会打开思路，这时，更优方案往往就找上门来了～

#### 5、方案五 ####

**既要解决眼前痛点，也要长远谋划**，基于以上四种方案，再深入思考一步，如果业务有投放在第三方（非集团APP）的需求，比如投放在商家APP，且商家APP获取通讯录、支付逻辑等复杂多变，这个时候如何设计编码呢？例如：拉起别端的唤端策略，受多方因素影响，涉及到产品壁垒，策略攻防，怎样控制代码改动次数，及时提高唤端率呢？在这里简单抛砖，可以借助近几年很火的**serverless**，搭建唤端策略的faas函数，动态获取最优唤端策略，是不是一个好的方案呢？

### 沉淀&思考 ###

以上针对多端兼容的问题，我们学习并运用了设计模式——策略模式。那么我们再来看看策略模式的设计思想是什么：一提到策略模式，有人就觉得，它的作用是避免 if-else 分支判断逻辑。实际上，这种认识是很片面的。策略模式主要的作用还是解耦策略的定义、创建和使用，控制代码的复杂度，让每个部分都不至于过于复杂、代码量过多。除此之外，对于复杂代码来说，策略模式还能让其满足**开闭原则**，添加新策略的时候，最小化、集中化代码改动，减少引入 bug 的风险。实际上，设计原则和思想比设计模式更加普适和重要。掌握了代码的设计原则和思想，我们能更清楚的了解，为什么要用某种设计模式，就能更恰到好处地应用设计模式。还有一点需要注意，在代码设计时，应该了解他的业务价值和复杂度，避免过度设计，如果一个if-else可以解决的问题，何必大费周折，阔谈设计模式呢？

### 总结 ###

理一下全文的核心路径，也是我此篇文章想要主要传达的打怪升级成长路径。

接到一个复杂的需求--> 理清需求 --> 拆解技术难点 --> 编码实现 --> 代码优化 --> 设计模式和设计原则学习 --> 举一反三 --> 记录沉淀。

当下，前端工程师在工作中，难免会陷入业务漩涡中，被业务推着走。面对这种风险，我们要思考如何在保障完成业务迭代的基础上，运用适合的技术架构，抽象出通用解决方案，沉淀落地。这样，既能帮助业务更快更稳定增长，又能在这个过程中收获个人成长。

[8f51f73503fba27ef5ccbc35ba45daa6.png]: /images/20220828/4108ec7ac297415288d1abebd007ff78.png