前端项目开发之经验之谈

煲仔明
685 阅读6分钟

前言

在不同的开发开发不同复杂程度的项目，一直想写一篇项目开发中的一些个人总结以及经验分享，本文主要讲述我们作为前端开发在项目中需要注意的点以及一些个人的经验之谈。

关于流程

每个公司都有自己的开发流程，在流程中需要注意的事项有很多，尤其面对较为复杂的项目，一个不注意，可能就会给自己挖坑，例如：对需求解读的不彻底，导致时间预估严重不够等，因此，每个环节都建议大家严谨认真，切不可粗心大意，一年之中，一个失误就有可能让你一个季度或者一年的努力白费，下面我罗列下个人认为每个环节需要注意的事项。

评审：

  1. 需求评审前尽可能先仔细解读需求，了解需求产生的背景、作用、价值以及具体所需要做的事，了解每个需求背后的背景、价值等有助于你培养对产品的大局观，了解需求的详细内容，有助于你更好的把控这个需求，掌握其所需的工作量和难度以及风险。
  2. 交互评审时，明确每一个交互点以免遗漏导致工时评估不准确，若项目紧急可适当拒绝一些不必要的交互，此外，针对页面初始化时的展示，最好跟交互明确下，是先出来页面展示占位数据，还是页面数据回传前使用加载中动画不显示页面或者是否需要启用页面龙骨架展示，这些细节都需要跟交互明确好并让ui设计。
  3. ui评审时，根据需求尽可能对有疑问的点进行提问解决，针对一些场景，确认所有的交互点，以免对我们的设计开发造成影响，必要时可适当拒绝一些不必要的ui需求，减少工作量，原则上只要有助于提高产品体验的ui需求都尽可能满足。

技术方案：

技术方案尽可能的详尽，让人直观的能了解到你对这个业务的整体设计、分层、封装等。技术方案是在不断完善的，因此开发的同时，也尽可能的去同步更新你的详细技术方案，以便于在代码检视的时候去为同事讲述。个人认为前端的技术方案设计应该包含以下几点：

  1. 需求简述：
    简单描述需求的背景、价值以及前端的开发需求；
  2. 需求涉及的项目，是否需要启动新项目，或者项目拆分等；
  3. 整体的业务流程图；
  4. 整体的技术方案：
    路由规划、全局组件、模块通用组件、通用方法、通用hook等，重点描述下复杂的组件和方法的设计；
  5. 风险评估以及回退方案；
  6. 测试注意点；
  7. 其他；

开发

开发中一些经验之谈：

  1. 不着急写代码，先充分解读需求和ui，在脑子里有个大致的图；
  2. 总览所有ui，提取通用部分，将组件或者方法设计的更具有通用性；
  3. 根据路由规划设计整体的目录结构，或者先构建目录结构再设计你的路由规划，做好结构的分层；
  4. 涉及到接口返回的枚举变量，尽量把使用到的枚举定义成有意义的变量或者map再使用；
  5. 高阶容器组件尽可能封装完善；
  6. 开发评估时间时，尽可能给予对产品需求的一定理解，了解其复杂度，作者之前在一个项目上就犯了这个错误，只是简单过了一遍ui去预估了工时，当详细了解他的需求时才发现需求复杂程度之高远非看到的ui那么简单，导致时间预估太少，只能自己拼命加班赶工，因此面对稍微较大的需求时，严谨认真；

目录结构

项目开发的目录结构至关重要，个人习惯喜欢将目录跟路由挂钩，目录结构直观能看出路由规划，因此在开发前，个人会先根据ui设计创建页面的整体目录结构，根据整体结构来设计路由。

枚举配置

项目中时常会有许多枚举变量，例如状态、类型等，个人建议将这些状态定义成有意义的枚举变量再进行使用，不要直接拿来用，防止过段时间回过头来看代码时，一脸茫然，在定义枚举时，建议简单枚举平铺定义，针对一个类型枚举过多的情况可以使用map，例如：

const TYPE_ENUMS_MAP = {
  going: 1,
  willBegin: 2,
  finished: 3,
  ...
};

// 少量时，平铺定义;
const WORK_HAS_FINISHED = 1;

组件拆分

当下前端开发开发，通常都会使用vue、react，使用组件化的开发方式，个人建议合理把握组件拆封的颗粒度，不用太小，也不能太大，太小可能导致传参的层级过多，太大可能导致单个组件或者页面内容太多，不利于维护或者复用，合理把握颗粒度，合理规划目录，遇到模块内几个页面通用的组件提取为模块组件，遇到可能全局都会用到的组件提取为全局组件，页面私有的组件放在页面目录下，设为普通页面组件，合理的颗粒度划分，合理的存放结构有助于你代码的合理复用和维护。

mock开发

mock开发是高效联调的必要条件，后端接口未完全开发完成前，我们可以利用mock平台先使用mock接口调试代码，个人推荐公司部署yapi平台。此前，需要前后端先定义和约定好接口入参和反参的结构，这一步很重要，一定要在开发前提前让后端同学录入接口并check接口的可用性和合理性，再投入开发，开发时，为了避免接口路径的替换，我们通常会给脚手架提供mock环境，mock环境下接口走mock代理到mock平台（yapi），这里有两种方法来区分路径：

1. 通过环境变量来区分接口路径：

const serviceConf = {
   url: '/user/getUserInfo',
   mockUrl: 'http://mock.yapi.com/10/user/getUserInfo',
};

2. 通过代理的方式：
配置接口代理(以yapi为例，yapi的接口规则, https://yapi.dev.com/{项目编号}/{接口相对路径})：
mock.conf.js:
module.exports = {
  100: [
    '/user/getUserInfo',
  ]
}
配置完代理配置，再动态的读取代理配置，生成接口代理传入脚手架的proxy中。该方法的好处是不会将调试的
mock代码打入最后的包中，相比于第一种方式更合理。

此外，为了能动态响应配置的变更，我们可以使用nodeMon来监听我们的配置并动态的重启项目；
nodemon --watch mockProxy.conf.js --exec .....
avatar
文章
阅读
粉丝