开发工作中，从需求评审到项目上线，这几乎是每个坑都要经历的一轮轮大战。不得不承认的是，需求和最终实现，每次复盘后得到的差值，几乎次次有的没的总是会来点疑难杂症没办法1:1还原实现的，那在这一条工作流中，能做的无疑就是再确认，再修改，再完善，再攻克。
阶段一 需求评审
每次接到需求的时候，都需要了解需求，了解设计背景和细节，并主动去了解和理解。产品是需求方，他只管要个好看的“玩具”，可不管怎么做好“玩具”的这个过程艰巨，开发还是要为自己考虑考虑的呢~
细节决定成败，一般大痛点，都藏在产品经理一句：就加一个xxx（嗯~就...）。对需求评审会议该有的重视程度要把握好，否则，开发过程中，暴雷的痛点加班，能致死。
在开发过程中，有些人以“能简单做就不要自己揽活”这种思想一直“苟活”着，其实不然，要想下次工资翻番，一定要学会自我吸收和成长。做好的需求，了解需求并主动去优化，不仅是工作更出色，也是下份工作的敲门砖~
阶段二 UI评审
优秀的前端开发同学，入职后能在短时间内能和UI同学达成优秀的默契程度，决定了后续开发工作的顺利和好心情哦~
UI评审在一般情况下，该环节由产品+UI+前端三方过稿，没有意外的情况下，风格基本由UI之前的设计稿决定，所以，UI评审这个时间，在默契度够的情况下，脱稿开发争取时间做紧急开发，也是大差不差的~
阶段三 需求拆解和技术方案制定
该阶段主要保证后续开发任务，多人协作的独立和共识。
对新项目这种特殊情况，还包含了基础环境的搭建和开发规范等基础工作协商和定制。
在这个过程中，前期做好的或者正在准备优化的前端基建，显得尤为重要了。前端工程化、前端监控、工作流、部署、性能等待，这些做好的基建工作，能给这一阶段带来高效的帮助。
- 技术选型；
- 开发规范；
- 前端监控：错误、性能、数据统计等；
- CI/CD：持续集成和持续部署，主要包括版本控制、代码合并、构建、单元测试、部署等一系列前端工作流；
阶段四 需求对齐
了解和分析需求原型后，对各功能点存疑的地方，要积极进入沟通阶段。
需求通常情况下影响因素很多，在一般设计和客户反馈、领导要求等因素影响下，一些设计交互和业务流上未必是正常思维产物，所以，多存疑、多了解、多确认，能给开发工作带来更顺利的帮助。
阶段五 接口设计方案对齐
同样的，同和UI的默契要求一样，和后端同学的默契程度，在一定情况下，也是能实现快速开发的效果。
后端同学在设计接口的过程中，会根据以往经验或者项目对每个功能块提供需要的接口。但是，对于一些复杂或者较深的业务流或者交互实现，又或者是数据结构设计上的考虑等，所以，接口可能存在过于耦合或者太细分的情况，所以需要做好确认和对齐工作，提前了解，帮助后续组件封装等工作的提前准备。
此外，开发过程中一般都是双向进行，因此，必要的接口文档提供，能帮助前端提前做mock测试，帮助后续联调工作的更顺利进行。
阶段六 开发
准备工作就绪，就进入开发阶段了。
- 项目初始化
- 项目环境搭建：版本管理、脚手架、UI框架、开发规范等；
- 组件、模块开发
- 数据mock，本地测试（等后端出接口调试，还要一段时间的~）
- 接口联调：出问题，记得笑着找人看，别挨揍
阶段七 测试、完善
哪个开发不是bug修复狠角色？(。-ω-)zzz
良心建议：做好的需求开发，都需要去了解结果。这个功能做好之后，使用和效率、数据是怎么样的，都能对后续开发和业务了解提供一定的辅助。
阶段八 部署上线
由常规部署情况下，很多资源和功能存在谁先更新部署的情况，视情况会 出现一些旧缓存、新资源错乱、覆盖等情况。上线过程中，因此，覆盖式发布方法就显得尤为重要。
用文件的摘要信息来对资源文件进行重命名，把摘要信息放到资源文件发布路径中，这样，内容有修改的资源就变成了一个新的文件发布到线上，不会覆盖已有的资源文件。上线过程中，先全量部署静态资源，再灰度部署页面。
灰度系统
通过灰度系统上线新版本代码，能有效降低发布问题。灰度系统可以把流量划分为多份，一份走新版本代码，一部分走老版本代码。而且，灰度系统支持设置流量的比例，比如可以把走新版本代码的流程设置为5%，没啥问题了设置为10%，依此类推至100%全量。
阶段九 复盘
阶段复盘鄙人认为还是有必要的。复盘不是甩锅，是为了下一阶段更优更快的进行。
复盘工作一般针对业务、设计、开发、协同4个方面进行。尊重一切，也要为了更好而合理质疑和提出建议和意见。
提问题可以，但是要带着解决方案和合理有效建议提问题，不要做“找事”的家伙。
以上是个人日常工作做的粗略简要，待完善之处吧应该还有很多，希望大家踊跃发表意见，帮助小菜鸡更上一层楼，(～￣▽￣)～
