前言
上周根据公司的新人指引看了内部一系列的规范和内部业务，这周开始接一些简单的需求进行开发。其实大部分公司一般刚开始都不会下发特别难的需求，无非都是加下字段，修Bug，改配置这类的小需求。
这些需求其实难度也不高，更多的在于了解公司的开发流程，熟悉部署环境。
目录
一、需求分析
1. 分析
2. 细节
3. 注意项
二、协调配合
1.前端联调
2.系统交互
三、需求提测
1. 冒烟测试
2. 联调测试
3. Test提测
总结
一、需求分析
1. 分析
这周一共接到了五个需求，从 jira 上的描述结合原型来看，还是比较简单的，如下：
1）对指定类型的订单进行判断
2）修改订单类型描述
3）变更订单履约描述
4）修改下单默认取值逻辑
5）订单搜索字段改模糊查询
从上面的描述来看，很简单，像 1，4 直接就是对订单实体流转增加 if else 赋值判断；而 2 初看的话对于有基建能力的公司一般就是改字典就行；3 的话if else 逻辑就复杂一点，基本规则就是 订单 -> 履约单 -> 履约子单的层级关系，基于之前的代码，为了便于和前端联调，复用原来场景码的逻辑，对不同的单状态进行 if else判断，赋值即可。5 直接对 sql 添加字段入参和出参即可。
2. 细节
需求 1，如果按常规的写法来看的话，就是基于以前的代码逻辑追加或者在代码前增加 if else 判断直接返回，但在看了系统的代码后，发现 if else 加在哪其实还是比较讲究的。因为这个需求之前就已经有实现逻辑，对于新增的判断其实要确定具体添加的代码在哪，不然就可能会出现新增的判断可能会被前面的逻辑覆盖，导致无法到达。或者后面的逻辑被新增的覆盖，导致得不到预期结果。
需求 3，需求拿到后看到的描述非常少，只有一个表格，对应了不同状态和子单状态下的场景描述。刚开始看到这个需求时，黑盒对比了一下系统现在的展示，发现只是需要协助系统增加两个字段返回显示就能满足。但是到和前端对接时，才发现新的需求和之前的描述完全变更了，对应的场景码也不一样了。在从前端聊天拿到之前的需求描述后，最后发现需要将整个场景重写。
需求 5，这种需求应该是新人入职最经常接触到的，最简单的就是增加入参和出参，在本地测试一下就能上线。但对于在二开系统上开发来说，有时候加一个查询参数可能还真没那么容易。在我这就遇到了，我需要对分页增加一个查询参数，这里涉及到跨表join，原来的逻辑里在xml和service层增加了一些公共方法调用，这样可以通过变更跨表参数直接实现（其实里面就是用了mybatis的 if 标签，存在就增加跨表join和where语句）， 我从xml里看到很多语句都引入了这个condition语句，同时在service方法也是一样，获取list，page，count的函数都引用了，那么就可能导致了我修改了这个查询字段，就可能会影响到原有的调用逻辑，导致最后的查询结果多了。
3. 注意项
在做这些小需求的时候，其实我们也会因为当前项目的一些业务场景和代码复用埋下一些隐藏的问题，所以总结了一些接需求的经验：
1）历史逻辑二开，需要考虑新增逻辑是否会被历史逻辑影响或者覆盖原有逻辑；
2）历史逻辑二开，需要与上一版本做差异对比，判断当前需求是否需要重写；
3）涉及到修改公共函数，需要向上找找变更是否会影响到其它调用。
二、协调配合
1.前端联调
因为我只用做服务端，前端都给到其它人完成，而且因为前端比较少，所以一般都是服务端做完了才会去要前端资源，相关的前端资源也要产品安排。
其实和前端联调难度不会很高，基本都是复用原有逻辑，而且也有 swagger 接口文档和调用，更多的在于一些文字或者场景特别交代一下即可。
在前端完成后，基本可以提测，但对于我来说，因为需求是安排到自己身上的，所以会对前端联调后的结果进行一次自测，避免反复打回浪费提测时间。（这种做法也是对的，光是我自己测都把前端实现打回了三次.....）
2.系统交互
除了和前端的配合外，在需求 3 里也涉及到和其它系统的交互。这里就有点意思了，协调系统这周需求排满了，所以协调系统的接口实现得自己来，其实这里面也比较简单，增加某些字段返回就行，然后api包打一个新的版本就行（这里自己也是脑抽了，没有对root整体发布，直接将api发布，导致一直拿不到新包）。
系统间的交互都比较简单，直接依赖新的api包就行。（注意：开发环境只能用快照版本）
三、需求提测
1. 冒烟测试
公司规定在提测前需要对需求进行冒烟测试，其实就是对需求进行功能测试，避免测试开测都测不了，不会对一整个功能进行深入测试。
其实对于这一点，我更多偏向于单元测试，但很多开发其实都不知道单元测试该怎么写，或者写完后原来逻辑变更了，因为时间问题也没有同步更新单测。
2. 联调测试
联调测试，其实就是前端或者协调系统联调，避免在接口层面直接报错，对于约定的报文格式其实一般都不会有什么大问题，报文约定后其实变更对于另外一边来说很多情况下都不用同步联调。
3. Test提测
在冒烟和联调都通过后，才会进行真正的提测，这一块在公司就是交给专门的测试团队进行，一般我们只需要编写提测邮件和提测前的checklist就行，测试会根据他们内部的流程正常流程。
测试完成没问题后，就会将分支发到UAT给产品验收，后面就是根据上线日期直接上线的问题了。
总结
以上内容，基本上阐述了我这边一个新需求从分析，coding，联调，提测的一整个流程，公司内部流程还是非常规范的，值得吐槽的一点是dev和test环境因为同时存在各种新需要版本，导致了在环境中的数据都会有不少问题，或者某些功能因为其他人没有规范发布问题，导致冒烟时存在较多的疑惑。
这些的话和以前遇到的公司都有比较大的不同，之前的开发流程都是自己在gitlab上去人力约束，在和现在的流程上也是孰优孰劣，慢慢适应吧。
