前端项目开发之经验之谈

前言

在不一样的开发开发不一样复杂程度的项目,一直想写一篇项目开发中的一些我的总结以及经验分享,本文主要讲述咱们做为前端开发在项目中须要注意的点以及一些我的的经验之谈。前端

关于流程

每一个公司都有本身的开发流程,在流程中须要注意的事项有不少,尤为面对较为复杂的项目,一个不注意,可能就会给本身挖坑,例如:对需求解读的不完全,致使时间预估严重不够等,所以,每一个环节都建议你们严谨认真,切不可粗枝大叶,一年之中,一个失误就有可能让你一个季度或者一年的努力白费,下面我罗列下我的认为每一个环节须要注意的事项。vue

评审:

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

技术方案:

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

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

开发

开发中一些经验之谈:react

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

目录结构

项目开发的目录结构相当重要,我的习惯喜欢将目录跟路由挂钩,目录结构直观能看出路由规划,所以在开发前,我的会先根据ui设计建立页面的总体目录结构,根据总体结构来设计路由。后端

枚举配置

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

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

// 少许时,平铺定义;
const WORK_HAS_FINISHED = 1;
复制代码

组件拆分

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

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 .....
复制代码
相关文章
相关标签/搜索