我亲身经历的2022年软件质量工作

写在前面：博主是一只经过实战开发历练后投身培训事业的“小山猪”，昵称取自动画片《狮子王》中的“彭彭”，总是以乐观、积极的心态对待周边的事物。本人的技术路线从Java全栈工程师一路奔向大数据开发、数据挖掘领域，如今终有小成，愿将昔日所获与大家交流一二，希望对学习路上的你有所助益。同时，博主也想通过此次尝试打造一个完善的技术图书馆，任何与文章技术点有关的异常、错误、注意事项均会在末尾列出，欢迎大家通过各种方式提供素材。

• 对于文章中出现的任何错误请大家批评指出，一定及时修改。
• 有任何想要讨论和学习的问题可联系我：zhuyc@vip.163.com。
• 发布文章的风格因专栏而异，均自成体系，不足之处请大家指正。

我亲身经历的2022年软件质量工作

文章目录

• 我亲身经历的2022年软件质量工作
• • 一、写作背景
  • 二、开发人员视角
  • • 1. 结对编程
    • 2. 代码review
    • 3. 分支管理
  • 三、其他人员视角
  • • 1. 测试人员
    • 2. 运维人员
  • 四、结语

一、写作背景

小编最近看到了CSDN官方关于2022年软件质量调查问卷的活动，里面的很多问题自己填写之后有了很大感触。毕竟之前在做开发的时候都是中小型企业，以扁平化管理以及快速实现为目标，对于软件质量、测试等方面甚至没有一个明确的概念和流程，大多数的情况是自己**“既当爹”、“又当妈”**，只要是和软件开发相关的都是程序员的活儿。
之后由于一直在培训行业，也没有关注这一方面，自己讲授的也都是与软件开发和数据处理相关的技术。目前自己重回开发岗位，有幸在跨国公司工作，整个的软件开发流程更加规范，整个的团队配合也更加紧密，在此撰文写一写自己收获到的经验。

二、开发人员视角

说到代码质量，源头当然是代码的编写，也就是开发人员的编码能力，以及团队的协作，首先从开发人员的视角来写一写自己的收获。

1. 结对编程

由于自己刚刚加入这个团队，项目中使用的技术是自己之前完全没有用到过的，属于基于NodeJS封装的独立框架，而自己一直在做后端开发和数据分析，对于前端只是停留在兴趣学习的水平，并且也从来没有参加过企业级项目的开发，于是心里是打鼓的，想着这肯定要先闷头学一阵才能达到代码提交的要求。
但是我的主管告诉我没关系，先进行两次培训，然后我们一起做pair progromming，很快你就可以上手。因为我其实第一次接触这个词，并且主管当时就是用英文说的，于是还特意查了下什么是结对编程，此前也是从未经历过的。大概知道是两个人一起来进行编码，完成功能需求。
第一次时心里还是比较忐忑的，毕竟和自己结对的就是自己领导，万一自己手忙脚乱简直不要太尴尬，毕竟一切对于自己来说都是全新的，但是实际经历过几次发现并没有想象中的那么恐怖。首先整个过程是十分open的，并不是像领导盯着员工干活儿的模式。

3. 分支管理

这里说到一个关于仓库分支管理的问题，之前做的项目开发，都是基于产品本身的考虑进行分支管理，比如在某个时间点或版本后项目有了不同的服务客户群或开发方向，那么就会产生不同的分支，而对于开发者来说，所有人还都是在同一条分支上进行着开发，因此不断的重复着：代码更新 -> 解决冲突 -> 代码提交。
但是我所在的项目所采用的分支管理方式并不是自己之前所熟悉的模式，而是采用了Google【大部分部门】正在采用的一种方式，每个人在进行功能开发时会临时创建一个新的分支，当开发完成时，再将这个分支并入Master分支。

• 功能测试

测试人员在测试前会再次根据需求列表【会在开发阶段开始前整理为一个个ticket】与相关的开发人员确认业务逻辑的细节，这样有利于更精准的测试到每一种可能的情况，有时也可能在测试前就会发现开发时没有考虑到的问题。

• 压力测试

压力测试是对程序与环境资源的综合性测试，在管理层面会对测试结果做一个整体的评估，考虑是否增加环境资源的投入还是需要在开发部分进行优化【比如更换某些组件或进行算法优化】。

2. 运维人员

在我的印象中，运维人员只是负责环境的部署以及项目发布，但其实运维人员在开发阶段和测试阶段都扮演了十分重要的角色。