目标、结果、分析、总结
最近接手了一个活动玩法需求，由于在评审、开发、测试过程中存在一些问题，导致这个项目延期上线；所以个人觉得有必要进行复盘和总结，避免在后续的需求开发中遇到类似的问题，再掉进坑里。
需求评审
作为前端开发，在需求评审之前应该仔细阅读产品出的需求文档和交互图，对照测试同学的测试用例过一遍整个需求。
- 对于不确定的点一定要记录并和产品确认下来（邮件和内部沟通工具进行确认，避免后期甩锅）。
- 对于复杂效果需要和产品明确兼容性问题，如果需要有兼容方案，务必在正式开发前给出方案，如果在开发过程中再提出来会导致开发时间不可控。
- 需要提前了解目前项目的技术环境是否能够实现某个功能，这个是为了避免开发过程中实现方案改动；不能实现的，一定要提出来，不然坑的是自己。
- 没有设计稿不给开发时间。
- 开发过程中新加功能就加开发时间。
- 不能心慈手软，给1.5倍的时间，留作缓冲和做code review。
开发过程
- 不要急于上手写代码，先对需求进行分析，大概过一下需要用到哪些技术；对一些功能点需要使用何种方案进行实现，这个一定要事先想清楚，不然开发过程中发现有坑修改起来很麻烦。
- 拿到设计稿先进行观察，进行模块划分，公共部分划分。
- 如果使用react进行开发，可以思考下数据流在以上模块间传递的过程，这样对于模块间关系和业务逻辑会有更清晰的认识；避免写着写着发现两个以为没有关系的模块却有数据耦合，主要还是避免后期逻辑改动，因为总是可能修复一个bug出现新的bug。
- 使用react开发复杂需求时不要使用context，不然组件之间的数据传递会让你焦头烂额，最好使用第三方状态管理库，这样也可以避免由于数据传递频繁触发组件render函数（包含diff）的执行。
- 这些梳理过程中最好在纸笔上进行，不然脑子过一会儿就忘记了。
- 严格按照和产品确认之后的交互和设计开发，切勿发散思维，容易导致写的功能和产品想要的不一致，当然对于有争议的点可以给建议且可以强势一点。
- 功能写完之后一定要自测，自测，自测；这是给测试同学方便也是给自己方便，不然测试同学对于一些小问题老是找你，老麻烦了，让大家都心累；评估时间的时候可以把这部分时间也算上。
- 对于开发过程中经常遇到的问题或者需要做兼容处理的地方（比如移动端fastClick、水平垂直居中等），及时积累总结，前期开发的时候就要把这些加进去，减少后期修补和沟通。
- 手动测试不会经过打包的js代码的时候，一定要注意低版本手机或者浏览器会不支持某些语法，所以最好使用es5语法来进行书写；比如测试某些api的兼容性的时候，极有可能由于代码中其他的书写错误，导致自己得出错误的判断即此版本手机不支持进行测试的api。
- 一些写死链接地址的资源，灰度和上线之前一定要把资源地址改为线上的，灰度和上线之前检查测试环境资源地址有没有替换，console.log有没有去掉。
- 再快再着急的上线，也需要走流程，开发单子、邮件、通知各个相关人员，测试环境测试，上线回测，一定都是有必要的。
- 一定要做code review，敬畏每一件小事。
测试过程
- 由于bug修复的代码改动及时通过pub上传到对应环境，避免代码覆盖导致问题重现。
- 对于功能测试所需要准备的东西要提前告知测试同学，减少沟通成本。
- 和测试明确最终交互稿和设计稿，避免出现信息不对称。
其他的点
- 对于自己写的组件一定要充分考虑各种情况，要么兼容性做的很完善，要么容易扩展、插件机制要好。
- 应该自己去做的事或者属于自己的事，属于重要紧急类型，优先进行处理。
- 本职工作做好，保持专业，不要坑自己和坑人。
以上就是暂时从本次开发中总结出来的一些点，放在这里，时时提醒自己，后面如果还有新的发现再回来添加。
