一、前言
想要优化一个流程，首先要熟悉这个流程以及流程中的问题和痛点。然后有针对性的去解决问题和优化流程。
1.1 传统开发模式 1.1.1 瀑布模型
瀑布模式严格遵守预先定义的需求分析、设计、编码、集成、测试、上线、维护的步骤顺序，是最典型的预见性方法。步骤成果为衡量进度的方法，如需求文档、交互稿、视觉稿、代码编写进度等等。
瀑布模式的主要缺点在于灵活度较低，需求一旦确定，按部就班的进行下去，后期需求有变化时就很难再灵活的调整。
1.1.2迭代式开发
迭代式开发也是目前我们常用的软件开发模式，它强调小步快跑、快速迭代的思想，每次只设计和实现产品的一部分功能。然后根据用户的使用反馈和数据分析，驱动产品的发展方向。通过多个迭代，逐步的丰富和完善产品。迭代式开发主要有以下几个优点：
1.1.3螺旋开发
“螺旋模型”的核心就在于您不需要在刚开始的时候就把所有事情都定义的清清楚楚。您轻松上阵，定义最重要的功能，实现它，然后听取客户的意见，之后再进入到下一个阶段。如此不断轮回重复，直到得到您满意的最终产品。
螺旋模型很大程度上是一种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评估。
1.2 敏捷开发模式
敏捷开发是一种应对需求快速变化而产生的一种软件开发能力。它强调开发团队与业务专家之间的紧密沟通协作，形成紧凑而自我组织的团队。
敏捷开发小组主要的工作方式可以归纳为：
二、需求阶段 2.1 需求评审
在开需求评审会之前，先阅读需求文档和交互稿，大家都带着问题去参加评审会，这样开会的效率会大大提高。笔者见过很多在评审会上不认真听，甚至玩手机的同学，在开发的时候才发现需求有问题去找产品，甚至开发完了才发现和产品的想法背道而驰。这不仅浪费了自己时间，也浪费了产品、测试以及整个团队的时间。
2.2 任务分解
任何复杂的工作都可以分解成一个个小任务，再讲小任务合理的组合，便成了完整的成果。就像一个复杂的页面，可以分解成不同的功能模块，各个功能模块又能继续分解成一个个功能组件。
合理的任务分解，有利于减少重复的工作，提高任务并发处理的能力。
2.3 职责明确
明确开发任务的界线，防止后面扯皮。就像当年的家庭联产承包责任制一样，大家明确了自己的责任后就会尽可能的去完成。如果出现一些划分模棱两可的功能，大家都不愿意主动去做，互相之间踢皮球，这就出现了项目的风险点。
三、开发阶段 3.1 代码规范 3.1.1 意义
促进团队合作
减少bug
降低维护成本
有利于代码审查
有利于交接
3.1.2 工具 3.2 协作
开发一个项目或者一个大版本时，会用到方方面面的东西。这个时候就可以让擅长某方面的人去提供这方面的能力，例如
同学A对前端的工程化理解颇深，项目前期的代建可以由他来完成
同学B擅长基础功能组件的开发，那么首先根据交互，把这一期需要用到的公用组件交给他开发
同学C对这块的业务比较精通，那么就可以把整个功能模块交给他，或者由他来主导，给他加两个人支援一下
3.3 接口文档 3.3.1 意义
在开发阶段，规范的接口文档可以很大程度上的降低联调的时间和成本。如果接口文档定义的好，前后端都严格按照接口规范来开发，那么联调几乎不需要花费多少时间。
3.3.2 工具
接口平台
mock数据
3.4 开发自测 3.4.1 意义
切记功能开发完成之后不自测就直接联调，这样会浪费双方的时间。本人就经历过好几次一个接口能联调一整天的情况，原因就是后端接口压根没有自测过，完全调不通。且他们所依赖的第三方接口，也没有测试过。
整个联调的过程就是前端在帮助后端测接口，这个不能将就，做为前端我们应该保留我们的原则和底线，强烈要求后端经过接口自测后才与他们联调。
3.4.2 工具
单元测试
自动化测试
mock平台
作为前端开发，在联调开始之前，我们就应该利用mock平台，将交互全流程测试通过，这是对联调阶段基本的质量保证，也是对后端同学负责任的根本态度。
后端同学更加要重视接口的自测，否则在联调时，接口各种调不同，很是让人火大。
四、联调阶段 数据准备
在开始联调之前，服务端应该将需要用到的数据提前造好。
切换分支
避免频繁的切换分支，去和不同的后端联调不同的功能
五、测试阶段
六、部署阶段
持续集成
回滚方案
工具
前端工具集发新版啦~
支持编辑器内直接查看yapi文档啦
发表回复