前端代码解耦,评审

代码解耦

今天看到前端小我伙伴的代码,发现两个js之间的耦合度高,一个方法里变量,两个js相互引用,这样的代码不适合阅读,更不适合未来的交接. 具体如下:

  @action
  getList = flow(
    function* (data) {
      try {
        const res = yield modelProvider.getList(data);
        this.List = this.List.concat(.res.data);
        if (res.page) {
          this.total = res.page.total;
        }
        if (res.data.length < this.PageSize) {
          this.isMoreDisabled = true;
          console.log(res.data)
          return res.data;
        }
        this.PageNo = data.pageNo + 1;
        return res.data;
      } catch (e) {
        return handleError(e);
      }
    }
  ).bind(this)
复制代码

这里是store里的代码

  //获取设备列表下一页
  getMore = () => {
    const { PageNo, List, PageSize } = this.targetStore;
    this.setState({
      deviceLoading: true
    });
    getList({
      pageNo: PageNo,
      pageSize: PageSize,
    })
      .then(res => {
        console.log(res);
        message.destroy();
        this.setState({
          deviceLoading: false
        });
        if (res.length) {
          this.Progress();
        }
      })
  };
复制代码

这里是index.js里的文件的代码.

很正常的获取列表的内容,在index.js里调用getMore函数,获取store里的PageNo, List, PageSize,这些变量获取后传递给store里的函数getList从后端拉取数据,然后store里返回数据给index.js做判断.

以下是个人的看法 index.js里的文件引用store里的变量:PageNo,PageSize,index.js里的getList里的方法里需要接受来着store里的变量:res,两个js文件相互依赖,相互耦合,不利于后面的代码的维护,可能新增需求后要维护原来的代码会造成一定的困难,增加后续交接小伙伴交接难度. 在这里如果需要解耦的话,则index.js里面就不应该处理业务逻辑,把所有的业务逻辑都提到store里.

转载于:https://juejin.im/post/5c359d9cf265da61285a4e1d

<think>我们正在讨论前后端分离开发的协作流程与实践。根据提供的引用内容,我们可以总结出几个关键点: 1. 前后端分离的核心是职责分离,前端负责展示和用户交互,后端负责数据处理和业务逻辑。 2. 通过API(尤其是RESTful API或GraphQL)进行交互,定义清晰的接口规范。 3. 使用工具(如Swagger)来生成API文档,方便前后端协作。 4. 客户端渲染(如使用React, Vue等框架)使得前后端可以并行开发。 协作流程通常包括以下步骤: 1. **需求分析与设计**:前后端共同参与,确定功能需求和接口规范。 2. **接口定义**:使用API描述语言(如OpenAPI)定义接口,生成文档。 3. **并行开发**:前端根据接口文档模拟数据开发,后端实现业务逻辑和接口。 4. **联调测试**:前后端对接,测试接口和功能。 5. **部署上线**:分别部署前后端代码。 实践建议: - 使用版本控制(如Git)管理代码。 - 使用Mock服务(如Mock.js)模拟后端接口,使前端不依赖后端进度。 - 持续集成/持续部署(CI/CD)自动化测试和部署。 下面将详细展开。</think>### 前后端分离开发中的协作流程与实践 前后端分离开发的核心在于**职责分离**和**契约驱动**,通过清晰的接口协议实现并行开发。以下是典型协作流程: #### 一、协作流程 1. **需求分析与接口设计阶段** - 前后端共同参与需求评审,明确业务规则 - 使用**OpenAPI/Swagger**定义接口规范,包括: ```yaml paths: /users/{id}: get: parameters: - name: id in: path type: integer responses: 200: schema: $ref: '#/definitions/User' ``` - 输出标准化接口文档作为开发契约[^3] 2. **并行开发阶段** - **前端**:基于Mock服务开发UI ```javascript // 使用Mock.js模拟接口 Mock.mock('/api/users', { 'list|10': [{ id: '@id', name: '@cname' }] }) ``` - **后端**:实现业务逻辑与数据层 - 每日构建验证接口契约一致性 3. **联调测试阶段** - 使用**Postman/Insomnia**进行接口测试 - 自动化验证工具确保接口兼容性: ```bash # 使用Dredd验证API实现是否符合契约 dredd api-description.yml http://localhost:3000 ``` 4. **持续交付阶段** - 独立部署:前端部署至CDN/Nginx,后端部署应用服务器 - 容器化部署保证环境一致性: ```dockerfile # 前端Dockerfile示例 FROM nginx:alpine COPY dist/ /usr/share/nginx/html ``` #### 二、关键实践 1. **接口管理** - 采用**GraphQL**实现精准数据获取[^4]: ```graphql query { user(id: "123") { name posts(limit: 5) { title } } } ``` - 版本控制:通过HTTP头`Accept-Version: v1.2`管理接口版本 2. **效率提升** - **BFF层(Backend for Frontend)**:由前端团队主导的适配层 - 代码共享:复用DTO类型定义(TypeScript共享类型库) 3. **质量保障** - 契约测试:使用**Pact**验证消费者/提供者兼容性 - 监控:前后端统一日志追踪(如ELK体系) #### 三、优势与挑战 | 优势 | 挑战 | |------|------| | 并行开发加速交付 | 接口变更需严格沟通 | | 技术栈解耦(如React+SpringBoot) | 跨域问题需规范处理 | | 独立部署与扩展 | 端到端测试复杂度增加 | > **最佳实践**:某电商平台采用分离架构后,发布周期从2周缩短至2天[^1]。关键成功因素包括:自动化接口测试覆盖率>85%,标准化错误码体系,以及共享的OpenAPI中心仓库。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值