软件开发的工作日常

时逢春招，有部分同学已经拿到了正式或实习offer了，也有部分小伙伴还在和各厂的面试官battle。我结合我的工作经历，给大家做一期分享，帮助还没踏入职场的小伙伴们了解软件开发的日常工作流程。
这篇分享对前后端开发均适用，我在这里以后端开发举例。
首先，每个互联网公司都会有一个类似于"迭代周期"的概念，一个迭代周期可能是2-4周，不同公司有不同的标准。在每个迭代开始之前，项目经理和产品经理们会先确定好这个迭代要做哪些工作，常见的工作可以分为两类：优化和开发。优化是指某个功能目前已经存在了，希望优化一下用户体验。比如淘宝的产品经理们觉得商品推荐首页展示的信息太杂乱，希望增加一些不同颜色的tag用以区分商品信息，这就涉及到前后端优化现有的tag功能。再比如淘宝的商品推荐首页从来不存在tag信息，产品经理们希望开发一个tag系统，用以支持给热销商品打标签，这就涉及到前后端从0到1开发一个新功能。无论是优化还是开发，我们统一把这类任务称作“需求”。
大家的技术leader往往对现有的业务代码比较熟悉，他会把需求按紧急和难易程度交给底下的人员来开发。这样，我们就会在一个迭代内，分配到几个大大小小的需求。
之后，在这个迭代内，我们需要根据每个需求PRD（Product Requirement Document）上的描述，确定这个需求最终要实现的目标，开始和前端同学协商接口文档。一般而言，后端会要求出一个技术方案，里面写上这个需求的需求详情，概要设计，详细设计，接口文档，服务分支等信息。和前端协商好接口文档后，作为后端开发，我们需要在现有的服务代码上，开始着手进行开发。由于现代大型项目往往涉及多个微服务，每个公司又常常有自己的微服务框架，所以在理解需求的基础上，刚进去的新员工还需要对服务之间的RPC调用有所了解。
开发完成之后，前后端往往需要把自己的需求分支部署到同一个测试环境上，进行联调。联调顺利后，新员工写的代码往往不太规范，可能会开一个Code Review会议，指出代码里的不足和待优化处。确认代码和功能基本没问题后，往往会发起提测，让测试介入，测试可能在测试的过程测出一些边界条件下的bug，这时候可能就需要开发做一些修补代码的工作，等测试跑完测试用例确保没问题之后，就可以通知产品准备上线了。
产品确保没问题，往往我们的技术leader会把我们的分支合到master或main分支上，我们拉取最新的master或main分支，按照服务的调用顺序，在公司搭建好的部署平台上依次部署每个服务最新的master或main分支。等前后端都部署完成后，一个需求就顺利结束了，我们就可以继续下一个需求的开发了。
当然了，实际工作过程中遇到的情况可能更复杂，比如产线突然出bug要紧急修复，或者产品突然要大改某个需求等等。这些留待给同学们以后慢慢去经历和感悟吧。
最后祝愿大家入职后，没有做不出的需求，没有复杂的人际关系，没有改不了的bug。不用996，拒绝007！