遇到紧急需求并且时间安排不过来的时候，应该如何去合理的安排时间和精力去平衡工作与生活呢？
一、敏捷开发过程
需求背景：
A领导要求的研发任务，计划3个月后上线
开发过程：
某程序员夜以继日，疯狂开发，但是无奈模块关联较多，导致开发过程中顾此失彼直到上线前仍然在改问题单
上线结果：
上线的日子逐渐来临，各种问题仍然被频频爆出，开发、测试、运维等人员苦不堪言，终于上线了，所有人等着这一刻，一直熬夜到凌晨两点才下班
二、需求开发暴露的问题
1、对于整个需求、上到领导下到员工。错误的预估了整个需求的技术开发周期
2、开发过程中，存在多方人员分工与协调，各个人员忙于自己负责的模块，导致公共模块验收缓慢
3、开发人员对于自身的时间安排也存在诸多问题，主要体现在以下几个方面
(1) 写代码的时间占据了80%，思考时间却只有20%，导致程序运行后bug不断
(2) 对于整个需求的开发模块，没有清晰的认识，而是边写代码边进行修改，后期才进行重构，导致代码不健壮
(3)
三、改进思路
1、代码设计
（1）目录结构设计、代码风格，这里主要包括对于需求中所涉及的模块进行分层设计，比如pages、utils等
文件夹命名：是否要按照业务逻辑划分、比如首字母是否大写等
html、class命名：dialog_wrapper、dialog_title、dialog_header_btn、dialog_body等
变量或者props命名：moal模态框区别于popup、appendoBody是否添加到body上、closeOnClickModal当点击moal的时候关闭模态框等
方法命名：handleWrapperClick处理wrapper点击事件、afterEnter/afterLeave 打开或者离开时事件处理
（2）公共组件、工具类设计、弹框设计：确保可复用、高内聚、低耦合的原则，同时满足单一职责原则，若多个弹框，要新建一个弹框基类进行控制，满足易扩展、复用性强
（3）弹框设计：如果存在多个弹框，需要设计弹框积累，设计弹框需要满足易扩展、复用性强
2、视觉构建
（1）后端在开发接口，前端可以做视觉构建、构建完成后可根据接口文档，通过mock数据方式调试接口，（2）同时书写前端逻辑；后端完成接口开发后，可以进行使用联调。
（3）像素级还原设计稿：使用snipaste截图，F1截图，F2贴图，调整贴图的透明度为50%，将贴图与前端页面进行像素级比对。
（4）及时沟通：开发视觉过程中及时与UI设计师沟通，进行样式调整，防止后期返工。
3、业务逻辑
（1）使用思维导图，梳理业务逻辑，再着手写代码，仔细思考开发中的可能关联的模块。思维导图方便理清逻辑，事后复盘，高效给他人讲解（多模块协同开发、与领导讲述开发思路），这种思想比较重要。
（2）调用接口时，要明确前端自己的安全边界，比如接口字段异常或者接口返回异常，前端要有自己的降级措施，如页面如何呈现。不能完全依赖和信任字段，不能让页面白屏。交互异常，控制台报错等异常场景
（3）除了完成产品要求的业务逻辑外，还要时刻考虑异常流的设计和容灾，简单来说就代码执行的异常场景下，逻辑是否还能继续执行，如try-catch-finaly，promise.then.catch.finaly 等机制，保证页面正常加载
（4）如果有PRD文档，那么开发时一定要严格按照文档进行开发，看看是否有遗漏。
4、代码提交
（1）先git pull 再git commit、git push，减少代码冲突
（2）commit粒度要细、注释写清楚、方便后续问题定位与复盘
（3）commit之前要diff代码，确保每一次修改是已知的，而没有错提交代码
（4）commit message常用格式：feat、fix、docs、merge，合并代码时遇到冲突要及时与对应同事沟通后提交，不要盲目自信的提交代码
（5）生产环境去掉console.log/debugger等多余代码
四、产品体验
（1）App或者小程序端一定要真机体验，同事对比IOS和Android对比体验
（2）体验时记录各种todoList
需求待确认list：一些小的、风险可控的需求点，可以在体验阶段，几种向产品童鞋提出
开发未完成list：有哪些尚未完成的部分，需要和产品童鞋交代清楚
已知bugList
体验问题 list：边体验边记录产品反馈的问题，并稍后同步给测试童鞋
依赖项list：接口、视觉切图、真实的测试环境等
五、代码评审、代码review
代码review
（1）也称codeReview，也叫CR，是一种通过复查代码来提高代码质量的过程，一次 CR 可以是一次 Commit，也可以是一次 Merge Request。
（2）代码review可以在测试期间进行
review顺序 业务核心逻辑、编码规范、关键位置（容易踩坑的地方、需要注释详细）、系统保障（监控、容灾、报错等场景）、系统安全和风险（是否有xss攻击等），用户体验
六、测试环节
（1）建议加强自测质量、减少由于开发人员自测覆盖不全的问题
（2）整理自测、测试、发布时需要的主流程checkList，每次迭代都能用上
七、发布环节
发布方案
发布顺序：一般是先发后端，再发前端
依赖项是否准备就绪：配置的数据、配置项等
是否会对线上业务、线上数据造成影响
本地环境、dev环境、gamma环境，均要做好验证。
回退机制
发布 checkList
参考
