业务开发往往是产品需求都比较急，叠带比较快。往往是快速排期、快速设计、快速开发，快速上线的一个状态，这就比较考验程序员的如何来适应这个快速的节奏和建立自己的开发流程和如何抛开工作之外的自我提升。
那怎么来应对这样一个快速的节奏呢？
- 理解团队技术栈
熟悉开发框架，熟悉团队中间件（如redis、kafka、orm、log、rpc等封装）的使用，最好深入源码研究，发现使用方法、什么场景怎么使用，有哪些坑，这些最好做总结，在团队中分享（为了自己熟悉和提升自己在团队中的技术影响力）。
- 代码规范
大部分团队应该都没有，有的话更好仔细熟读理解。没有的话从源码中提取列出哪些好的规范和不好的规范整理一个，在合适的机会和同事讨论商量做一个规范准则，这样以后大家共同维护一个项目不至于恶心。
- 了解开发流程
通常流程是产品提需求有一个需求会、与其他交互系统确认交互字段、给排期、设计开发、自测、提测、上线、线上验证等。大体是这个流程可能对应每个产品流程不一样。在大体符合流程情况下，这里需要把握自己的节奏。
- 熟悉业务
业务开发业务最重要理解业务实现业务。从宏观理解再到细节，推荐自己用脑图梳理自己接手的业务，不断的叠带梳理。最终会影响你程序的设计。
- 了解业务监控
通常公司运维团队都建立了一套监控体系，这里需要外面去梳理从业务层到底层是如何做的监控，和去订阅，出问题的时候能快速排查和解决问题。
如何建立自己的开发流程？
自己的开发流程是在符合团队大体流程之上提炼出来自己的开发流程。
- 需求评估
需求评估需要理解产品和用户的需求，理解要解决什么问题。明白什么时间需要交互，评估目前系统逻辑情况与产品沟通好一个比较合理排期时间。需要落实在自己的开发wiki上。
- 需求开发设计
设计主要包含：
1.整理当前系统关于此需求逻辑。
2.整理外部依赖接口和自己暴露接口，依赖的外部接口一定要和提供者沟通你的使用场景和大概的并发量和请求参数范围等情况（这是一个最耗时的过程），对外暴露接口也一定要收集到调用方的使用场景和并发量等问题思考是否复用原来接口和重新提供接口（提供接口一定要慎重，一旦提供就很难改造）。
3.根据需求排期设计开发方案，如果时间充裕以最优方案做包含重构以前的一些逻辑。若时间不许可，选择折中方案（欠下技术债）。此时需要专门整理一个技术债wiki，记录下，待以后偿还。如果比较复杂的需求需要发起开发方案评审，若没有这个流程也可以请求同事或者有经验的同事把把关。
- 开发
遵守code 准则、做好单元测试、和基本的联通测试、等自测。完事后提交git 一定要自己做一遍code review。也邀请同事帮忙做一个code rewivew。
- 提测
整理好开发文档和接口文档和改动说明和测试点。一定要耐心的和测试同学沟通因为这是开发质量的最后一道关口。测试同学遇到问题要及时解答，总之配合好测试同学。
- 上线
不管你有没有上线权限，一定要整理上线文档，文档包含上线代码git merge request，上线cmd，上线配置和sql，和依赖接口、及其上线顺序、及其上线影响、上线如何验证 等整理好，尽量在第二人参与情况下上线，同时也做好回滚流程，万一有问题需要马上回滚。 这一步很重要，做得不到位很可能发生黑天鹅事件，墨菲定律。
- 上线验证
一定要做线上验证，按照验证计划。如果实在做不了验证也应该加强线上状态实时监控。
- 做好事故回盘
遇到线上事故和重大bug 一定要做好记录和做好回盘，改进，这个也可能是团队的要求。自己也关注下其他人的回盘引以为戒。
如何自我提升
从上面看业务应用开发就是工程性问题，按照自己的一个开发流程周而复始的重复。技术基本也就那几个技术点，怎么才能保证技术不被淘汰呢？
最重要的是做好自己的技术规划。简单的说是按照规划做好输入输出。业务开发沟通会浪费很多时间，做好碎片化时间管理。和互联网行业都加班，虽然每天大家都加班，但是百分之八十的时候白天都能完成工作，由于有加班文化，大家都磨洋工拖到晚上。建议白天正常完成工作，晚上流出时间来做自己的技术规划，日拱一卒。
