前言：
随着环境的变迁，大家总会更换工作，有裁员的，有跳槽的，除了进进出出的老人，还有源源不断入坑的新人。
很多人入职之后还不知道怎么快速适应工作，对我而言，除去寥寥可数的同事感情，对我而言，更换工作更像是换个环境办公。
今天记录一下每次功能开发的工作流程，当然这个流程并不具有代表性，特别是与”大公司”完善的制度相比，这只能算是给新人指路而已。每个公司的需求开发步骤都不相同，让我们一起完善这个开发步骤，给后来者指明方向。
注：步骤是死的，但人是活的对吧，不清楚的地方急时提问，毕竟不懂的地方问我，我又不收费
1 开发文档获取
开发之前，都会有开发文档、产品原型说明之类的辅助资料，就算是在细小简单的功能，基本上都会有相应的描述。如果全是口头描诉的功能，那就？跑？！hhh
2 需求理解及准备工作
在阅读需求文档的时候，需要仔细阅读，并且阅读的时候，弄清楚这个功能的定位。特别是对于写代码的人来说，要知道这个功能开放式属于哪个功能模块里面的，至少你的代码写在哪里，这个你还是要弄清楚的。
不论是shi山雕花，还是堆砌新的shi山，功能前后关系都要捋清楚，这个功能是新功能，还是扩展功能，这个功能跟其他模块相关联的代码要阅读，有关的数据表要提前捋一下。如果弄不清楚前后关系，那么开发的功能很容易偏离实际的功能要求。
如果通过看代码，看文档，看需求文档，有些地方还不能理解的，也不用着急，因为后面还会有会议讨论，这些需要做的就是尽力去理解，对于一知半解的地方可以去询问其他同事，如果还是有疑问，记录下来，开会的时候提问即可。这样的情况我也遇到过，当时有点慌，但是开完会，我就理解了。
3 会议记录
会议还是比较重要的，如果第一次开会一直蒙圈，那就要做功课复习了。
会议上需要明确需求功能点，开发功能点，如果遇到棘手的地方要及时提问，这时候还有不理解的，一定要在会议上提问清楚，如果弄不清楚，开发起来会很痛苦。这时候需求的提前理解，相关的代码阅读，数据库表的提前了解，在这里显得尤为重要，不然你很可能不知道会议在聊啥。
会议上捕抓到的重要信息，大概记录下来，我的建议是开会之前带个本子：好记性不如烂笔头
注：到了这一步，决定你是否能和产品同事进行有效交流
4 接口定义
会议开完，一般都是和前端需要定义好接口数据，入参和返回值，固定的接口结构，避免定义好的结构在后期进行大改，不然很容易阻碍项目的开发进度。
作为一个后端，一个原则：尽量宠前端，后端能做的事情尽量在后端去做，秉承着能不让前端修改就不让前端修改，你把前端宠得像个小娇妻，你们的对接工作不就轻松愉快了嘛。一个功能的开发万万不可离开前端，否则就是一个人玩过家家了，有修改的地方，及时通知到位，别到最后，直接甩文档给到前端，这无疑会增加双方的工作量。
如果还没有专门的接口工具类，所以和前端整理好接口结构之后，最好自己整理一遍，这样开发的过程中才不至于模凌两可。
5 代码开发
代码开发之前，需要明确自己的代码是基于哪个分支去开发的，怎么明确？问呗！大家都会问，那我就把目前的开发分支信息给截图一下。千万别盲目参考文档，有些文档写完之后就从不更新了。所以你需要去和同事或者领导多多交流。尽量弄清楚每个分支的作用，这样有助于我们后面的工作进行。
功能开发完成，需要在本地调试一下，大多数时候我都是用 postman 请求一遍自己的接口，看看入参和返回值是否一样。一般我们调试，都是把免登陆打开，专注看接口功能就行。免登陆只需要在接口上加上：@NoLogin 注解即可 。至于单元测试，每个人根据自己的情况来定，这个不好言语。
6 代码提交&环境构建&前后端联调
代码开发完成，需要提交到test分支，与前端进行联调(或者在本地联调也可以)
代码提交后需要借助 jenkins 进行环境构建(这一步每个公司不一样了)
7 代码审核&发布文档编写
发布完成，就等前端联调完成即可，工作完成之后需要书写发布计划文档以及找人帮 review 代码。
注：到这里，做为后段开发的主要工作就差不多完成了，剩下的就是不断测试，修改Bug，发布，后面的步骤每个公司具体执行都有差异。最后就是提交代码，合并到master。但是我们也不一定合并权限，根据实际情况处理。到这里，我们也就的完成了一个功能的开发了。
结尾
好像说完了，好像又没有说完。这里主要还是作为一个后端开发，去”干活”的一个角度描写，当然，我是不希望大家止步于文章这里。比如很多时候，我们需要根据产品文档写一篇自己的技术文档，然后做一下技术评审，或者是各个环节中的跨部门交流的能力显得尤为重要，这里往往能提现出一个人的强大与否。最后祝大家事业有成节节高~
本文来自互联网，尽管我们已经尽最大可能联系作者进行授权，但仍会有疏漏，如果本文侵犯了您的权益，请您及时与我反馈
