标准的高效率开发流程
实际开发过程中，除了自身掌握的专业知识外，正确的开发流程和团队协助，也能让开发质量和速度有质的提升；以下整理了作为一名合格的前端开发工程师需要注意的的事项和标准流程
1. 为什么要做这个功能
拿到原型图时，应该先找到原型图的 「现状以及解决方案」 模块，先了解为什么我们的系统需要这个功能，这个功能又解决了用户的哪些痛点，只有了解清楚我们要做什么，你才能真正地理解需求，从而理解产品的思路，进而减少 BUG 的产生
2. 从哪里来，到哪里去
了解设计原因后，再打开原型图的 「流程」 模块，并且打开我们的项目，去按照流程步骤一步步了解这个功能的前因后果，了解这个功能从哪里来，要到哪里去；这个过程中你就会知道我们在调试的时候，数据到底从哪里来，下一步到哪里去，而不是依赖后端同事的配合
3. 交互分析
在了解功能的前因后果后我们应该干嘛呢？就是交互分析
比如哪些按钮需要做好防抖，哪些校验需要增加，哪些设计图之外的交互可以去优化
并且会引发一个新的问题 —— 需求确认
比如下面这个例子：
如图，一个简单得不能再简单的文本域；虽然产品贴了原型图，但其实这就是典型的 需求不明确
比如：
- 文本域最大支持输入多少个字？（非常重要，关乎后台存储方案的设计）
- 文本域的校验在何时触发
- 如此 “美丽的绿色” 标题是否要一比一还原
很多需求细节并不是看原型图就能确认，更不要自以为是地去当产品肚子里的蛔虫；而是在产品原型不够明确的情况下，必须要做好 需求确认，这样才可以有效地避免 BUG 的产生和提测的返工
4. 开发分析
分析完交互和确认完需求后，就要根据原型，评估哪些为系统出现过的类似的，可复用的；哪些是需要去做知识储备的
认真分析需求的好处在于：
- 能更好地评估开发时间，减少任务延期的可能性
- 提前准备好应对风险需求的措施，在开发该模块时预留更多的开发时间去确保需求的完成
而这期间如果发现需要引用一个全新的 javaScript 库 或者封装了一个可能是公用的组件，那么请在团队的交流群内提醒其他成员，以免他人重复封装，并在自己封装的方法内，提供对应注释
/*
*
*
开发者：
用途：
使用方法：
场景：
*
*
*/
在遇到计算性，权限性、复杂性的功能时，在该功能位置处写好逻辑注释，便于逻辑检查和自测
5. 数据模型设计
在分析完原型后，根据原型图去设计数据模型，在设计数据模型时，首先要知道
万物皆对象
也就是说不管我们开发常见的表格展示页，还是复杂结构的表单+表格+可视化，他们的数据都离不开最终在一个对象下
那么什么是数据模型呢
数据模型是数据特征的抽象，用来抽象定义一个业务对象
听起来很抽象那么它解决了哪些问题呢？
前后端数据结构没有解耦，前端在应对不定的服务端数据结构前提下，需要编写过多的保护性代码，不利于维护的同时，代码健壮性也不高
基础数据逻辑处理没有和UI视图解耦，容易阻塞视图渲染，同时，在视图组件上存在太多的基础数据逻辑处理，没有有效复用
我们将前端所有使用的业务数据模型都定义出来 ，那在实际应用中，有什么用处呢？
- 减少了无数的冗余代码，避免了非常多容易产生的 BUG
- 提交接口的时候日期忘记转换的问题
- 因为数据缺失导致页面报错的问题
安装
npm install js-model --save
中文文档地址：js-model
插件为我们提供了两个方法：
-
parse:
- 创建完整对象数据，让你摆脱
{{ a && a.b ? a.b.c : '' }} 这种无聊的判断 - 数据标准化转换，当数据从后台传输过来的时候，日期是时间戳，金额是以元为单位，
parse方法可以帮你转换时间戳至时间字符串，金额以一定单位转换好，并且可以帮助你补全好所有的字段
- 创建完整对象数据，让你摆脱
-
dispose:
- 在你把数据传送至后台之前，把日期转换成后端需要的时间戳，把金额转换为以元为单位的数额等；标准化数据格式，删除为空的数据
例如：通过input修改的数值为String, 但是我们可以通过 dispose 转换成数字格式
6. 正式开发
明确完需求和做好对应的技术准备后，我们就可以开始需求的开发了
但是开发期间也有可能会遇到几个问题
比如接到需求时，评估开发量需要3天，但因为种种原因才发现至少需要4天才能完成
又或者后端提供接口不及时，临近截止才提供
那这种时候我们应该怎么做呢？一步步来
6-1. 及时暴露风险
在需求完成的过程中，经常会有各种意外的小插曲出现；对于前端来说，常见的有：
- UI 稿未按时提供
- 需求变更
- 工作量评估时长不足
- 后端接口未按时、按质完成
- bug有好多，但修改不及时
这个时候，该怎么办呢？
相信不少同事都是这样处理的：咬咬牙，加加班，实在完不成了再说
但是这样处理造成的最直接的后果就是由于开发时间流程紊乱，造成开发质量低，提测后疯狂返工，导致接下来的开发工作不断恶性循环
更好的处理方式是： 及时跟项目组成员同步风险，并落实确认相应解决方案；比如适当调整排期、砍掉部分优先级不高的功能等
6-2. 流程交换但不停止
但出现因类似后端未能按时提供接口的团队协作问题时我们还有别的解决办法
后端未能及时提供接口时，前端不应该停滞不前，而是应该要利用等待的时间，完成如下事项：
- 检查前端模块，是否还有可拆分成组件的模块，将其提取封装成组件
- 检查数据模型，是否定义清楚；如清楚，利用 Mock 模拟数据完成业务的开发
- 完成业务的开发后应进行自测，检查函数等是否完成了需求
7. 自测流程
作为任何一名合格的程序员，代码质量都是衡量自己专业水准的重要指标
开发联调完成后一定要抽时间进行自测：
- 开发：是否严格按照需求文档完成功能的开发
- 联调：在与后端联调前，是否已经按流程对自己的模块进行了严格的自测
- 提测：测试正式介入前，产品是否提前部署到测试环境，并进行初步的验证
严格把控开发、自测、提测质量，这不但是能力，更是一种负责任的态度体现
如果能做到这点，不但提高项目的开发效率，更可以提高其他岗位同事对你的信任度和认可你的专业度
8. 推动解决问题
除了代码质量，解决问题的能力同样也是一位优秀的程序员必备的
那么解决问题的能力又任何体现出来呢？
8-1. 及时响应自己的 BUG
在面对 BUG 时不用刻意抵触，因为前端本来就是所有 BUG 的定位点；应该主动去跟测试同事沟通，还原场景，定位 BUG 的归属
在完成 BUG 的修改时，本地自测通过后再发布到测试环境，发布完成后再到测试环境进行自测，确认没问题后再找到测试同事进行回测
事后进行 BUG 总结，必要时记录下来，降低后续开发的 BUG 率
8-2. 协助他人解决 BUG
在任何一个项目中，团队协助都特别重要
当同事出现开发风险的时候，可能会有不少同事这么想：
又不是我的任务，干嘛操那份闲心，需求如果延期的话，那也是他的问题，跟我无关
但是这种想法却不仅消极，而且很不职业
同在一个项目组，得要有团队意识、整体意识；需求延期，首先是所有需求相关人的责任，是要一起打板子的；然后，才会对具体的责任人进行问责
更好的处理方式是：做好沟通工作，主动推进问题解决
- 了解同事没有及时改bug的原因：有可能太忙、bug不好改、没有意识到那是自己的bug
- 主动跟上级提出分担同事压力，及时把问题解决完毕
而作为需要别人帮忙的同事，也需要在开发中做好注释编写工作，不要让别人觉得看你的代码很痛苦
9. 关注线上质量
这一点非常重要，但却又是容易被忽略的一点；需求发布上线，是个重要的里程碑，但并不意味着需求的终点，还得时刻关注以下事项：
- 功能是否正常运行？
- 各项指标是否正常？比如产品上报数据、性能监控数据、错误监控数据等
- 有哪些可以优化的点？优先级多高
只管功能开发，一旦需求上线，立刻做甩手掌柜，同样是缺乏责任意识的表现；试想一下，如果你是团队的管理者，你会放心把重要的需求交给一个“甩手掌柜”吗
