dsf

前言

在这个春风得意马蹄疾，金三银四跳槽季的日子里，相信很多小伙伴都拿到了心仪的offer了吧，其中不乏有初入职场的同学。那么今天，我就从服务端的角度来给大家分享一些关于工作中开发流程的经验，希望初入职场的同学尽量少踩坑不背锅，能够顺利通过考核期。
进入公司你会发现，一般正规点的公司都会分很多部门，如开发部（科技部或研发部）、产品部（业务部）等，这两个部门是相互对等的，也就是说后者负责产品功能的创意、设计，产品的大方向，说白了就是负责提出产品需求，把控产品的定位和走向；而前者则是需求的受理者，负责从软件、技术层面来实现后者提出的需求。两个部门没有上下级的关系。
而对于我们程序员来说，做一个需求从接到需求到上线的完整流程大致如下：

需求分析（包括需求调研，需求讨论，需求确定，接口确认）
系统设计（设计该功能实现细节，要用到什么技术等）
系统实现（从软件代码技术层面实现功能）
功能测试（包括开发自测，提交测试，业务测试）
需求上线（业务验收，验收是否通过，代码是否回退）

需求分析
从你拿到需求文档开始说起，你会看到需求文档至少包括2部分来阐述这个需求：需求背景和需求描述。

需求背景：主要告诉你为什么会有这个需求，提这个需求的目的是什么。需求描述：这才是这个需求的重点，主要告诉你要实现什么样的功能，做成什么样的效果，以及一些业务规则等，可能还会放几个页面的原型图，这就再好不过了。

这些都是业务部门经过深思熟虑、各级领导审核通过后的需求，才会到研发部门，研发部受理这个需求，分给你的组长或直接分给你。
言归正传，你接到需求，打开需求文档，开始看需求了。
1、快速通读
可以先快速地通读一遍，了解需求的大致意思，对需求有个整体的把握，做到心中有数。
2、抓重点、记疑问
然后第二遍，看细节，抓疑问点。
这一遍，你可以看仔细点，把一些关键点认真看看理解一下，同时看的时候可能会发现需求有写的不明确的地方，或者需要确认的地方，或者你会有一些疑问，这个时候你可以把这些点记录下来，认真读完一遍之后，你记录了一些问题。
3、答疑解惑
读完两遍之后，你有一些疑问。然后你可以找个时间拉上经理或需求负责人，开发组长，前后端开发人员，业务（提需求的业务人员，他是最了解需求的人）、测试负责人一起当面开个小会（能当面绝不群里聊），去解决你记录的疑问点，把这些需求里你认为写的不确定的地方弄清楚。这个过程就是答疑解惑。
在这个讨论过程中，定下来的业务规则务必要记录下来，会后可以发一封电子邮件，把需求确认的东西或者业务又新加的东西写在邮件里，提醒业务确认无误后让他更新需求文档，并且邮件抄送给一起开会的人。

为什么拉上这么多人呢？因为你有疑问的地方你的组长，经理等也可能有疑问，这种拍板钉钉的事不能只让你一个人知道，到时候做完了上线了，业务发现不想要那样的效果了赖账不承认了咋办。拉上测试是为了避免开发和测试理解需求上有偏差，避免测试写的测试案例和需求要求有出入。

为什么发邮件呢？做这一步也是为了规范开发流程以及留个底有个证据吧，防止以后问你为啥这样做，你就有据可依了。不然你单凭嘴说：当时讨论就这样定的。这样说服力不够啊。我们一定要做到，不甩锅也绝不无故背锅！

4、准备材料
需求讨论过程中如发现涉及其他系统，提出来，并确认下其他系统接口有没有提供好，并通过项目经理向其他系统要接口文档（系统间的文档收发，最好通过系统负责人，即使都是内部系统）；另外，如涉及到页面改动需要提供UI的，督促业务及时提供UI，防止延误需求上线。

为什么出UI？出UI的目的是严格按照UI图的尺寸、色值来做页面，防止到时候前端做好页面后业务又来扣这些细节，让你返工，还显得你干活不利索。假如有的公司根本没有UI设计师，那就提前和业务说好，做的时候让业务把把关，看是否复合他要的效果。

5、工作记录
其次，针对该需求，写每日工作进度（日报）时，写上当前需求到了哪个阶段（如需求分析阶段，开发阶段等，具体到了哪个阶段，自己评估），以及当前遇到的阻碍等。这样如果有阻碍，即使是延误了上线，也不是自己的原因。
注意：1、系统间接口联调大概需要1-2天，复杂的接口可能需要更长的时间。系统联调最好放在系统设计前，这样可以发现接口返回内容是不是满足这个需求，并提出这个问题。如果你开发的时候用到这个接口的时候再联调才发现问题，那不是耽误时间了吗。
2、假如第一次调用该系统，还要注意开通系统间的网络，不然无法访问。开通网络当然也需要项目负责人来申请。而且一定要测试环境和生产环境的网络一并开通，开通后并测试是否真的已经开通。这样防止没有开通网络，上线后调不通，又临时火急火燎的发邮件申请开通网络，这样只会让你难堪，显得你这个人不够仔细。
小编推荐一个学C/C++的学习qun 5999，45900
学习从来不是一个人的事情，要有个相互监督的伙伴，工作需要学习或者为了入行、转行都可以，qun内有开发工具，很多干货和技术资料。

系统设计

需求分析，接口联调，开通网络等一些准备工作及杂事处理完后，就可以开始系统设计了或者边处理边进行系统设计（因为你等着出UI、开网都需要时间）。
系统设计就是来思考怎么来实现这个功能，实现流程是什么样的，要不要新增表或增加表字段，表结构如何设计，要写几个接口给前端，调用顺序是什么样的，返回什么样的数据，数据格式什么样的，可以和前端开发坐一块儿讨论。这些应该在你分析完需求后就有了一个大致的思路，然后现在提取需求的关键词、关键点作具体的详细设计。
系统设计也是很重要的一环，是在写代码之前定的目标，做的一个宏观规划。尽量不要边写代码边想怎么实现，这样会导致最后思路很乱写的代码也很乱。
建议最好画流程图，条件允许的情况下小组内评审下，找出不足。
在系统设计阶段如果需引入新技术，一定要考虑使用什么技术，技术的复杂度，成熟度等，为什么用这个技术，好处是什么。如果自己不敢确定用什么技术，可以找技术经理或比自己经验丰富的同事一起定一下。初入职场或经验颇少的同学，可以把自己的设计思路和他们说一下，让他们把把关。

系统实现

这一步就是你最喜欢的写代码阶段了，写代码的一些规范不用我多说了吧，下载阿里的开发手册看看，或自己公司的开发规范。
业务代码一定要加注释，在关键步骤加上简单的注释，以便日后自己看或者其他同事接替你的时候能一目了然，看懂这代码是在干嘛，不至于背地里被吐槽被骂娘。很多时候一些同学自己写的代码，不加一行注释，时间长了自己看的时候都懵逼了。加必要的注释是程序员最最起码的修养。
在功能开发到近一半的时候，邮件给测试负责人并抄送相关人员，告知此需求已开发过半，目的提醒其写需求的测试案例，以免延误测试。这一点根据你们开发流程定，建议如此。

功能测试

开发完成就进入功能测试阶段了，或开发完某一接口（给前端调用的）开发人员就可以边开发边测了。
1、开发自测
开发人员对自己开发的功能自己测试，主要测试接口的逻辑，入参出参是否正确等，边开发边测，前后端可以一起测。
当整个功能都开发完成后，开发人员对该需求做整个流程的测试，针对可能出现问题的场景重点测试，当觉得本地测试的差不多的时候，可以把代码合并到测试环境再进行一次完整的测试。当觉得可以的时候，请小组组长发起走查代码，主要检查代码逻辑及代码规范等常见的显而易见的问题（毕竟旁观者清，自己写的代码可能看很久也发现不了问题），有问题就改一下，走查没问题了就可以提交给测试人员了。
这里走查可以记录到代码走查记录里，主要写走查负责人，开发人员，走查时间，需求名，走查发现的问题，是否解决，何时解决等。通过走查代码可以防止同样的问题再发生，或大家互相引以为戒。
2、提交测试
自测完毕后，邮件给测试负责人及相关人员，邮件说明某某需求已经合并到某某分支，或已发布在某某测试环境，现在提测本需求，及时测试等等...并说明涉及到的功能和系统，以及主要的测试点。
接下来你就配合测试人员啦，有bug改bug。
3、业务测试
当测试人员测的差不多了，她们会邮件给业务人员。业务测完觉得没问题，那就等着上线吧。
需求上线
需求上线前一定要检查你的代码完整性，把你的需求涉及到的SQL语句（如新增的系统参数，新增表结构等）、改动的配置文件（新增或修改配置）提交给运维。（重要！！！）
在需求上线的那天，你熬夜等上线（大部分都是晚上上线避开高峰期，也有的是灰度发布可以提前上）。当生产发完后，测试人员和业务人员会在生产验证，当业务说验收通过时，恭喜你可以回家了。如果有问题，你还得去查日志排查问题，然后解决，再上，再验证；如果问题太严重，你的代码就需要撤下来，暂时不上。
最后
上线完毕后，将本次需求所有有关的文档打包归档，提交至你们的文档库或者类似confluence这样的开发管理平台，如果没有这些东西或没要求做这些，可以自己保存下来，以便以后查阅。
总结
软件工程是一门学科，这里主要站在后端程序员的角度分享了自己总结的需求开发流程及开发过程中避免踩坑背锅的经验，可能写的有点粗略，或废话很多，可能有的公司没那么规范，也可能有的公司比这流程复杂多了，但是这里提到的需求分析、系统设计部分应该跟公司定的开发流程没关系，是开发人员自己的习惯和经验、自己给自己定的规范。还是那句话，我们程序员不甩锅也绝不无故背锅！