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

Posted 2023-01-14 一头小山猪

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

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

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

本文关键字：软件测试、软件质量、结对编程、仓库管理、项目运维

文章目录

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

一、写作背景

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

二、开发人员视角

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

1. 结对编程

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

整个过程我需要分享屏幕，从头开始一个需求的开发，然后不懂的地方对方会进行指导，这也正是我所担心的问题。因为如果遇到的问题太多，感觉会降低自己在对方心中的评价，但是实际上其实是两个人互相讨论一起完成开发，虽然所有的代码都是我自己一个人在写，但是从需求分析开始，对方会很尊重我的意见，甚至会说：嗯，你说的这个思路更好更合理，那我们换一种方式，然后就会介绍这种方式下已经做了哪些前期的工作，接下来我们还需要做什么就可以完成任务。
经过了两次之后，我就已经对整个框架有了大概的了解，因为整个过程自己的精力都十分集中，相当于可以达到写出一个规范Demo的程度。当再有需求进来的时候，自己就能够有一个基本的思路，然后对于所欠缺的技术点通过消息沟通基本就可以解决了。
当然，这里的结对编程并没有贯穿项目的整个开发，而只是在我刚开始接触的时候体验了两次，帮助我快速熟悉了整个项目的开发模式。在整个过程中，由于是由一个经验丰富的前辈手把手一行一行看着你写过来，所以对于代码规范和注意事项已经能够有一个比较细致的把控。虽然说还没有那么全面，但是对于代码质量的保证与提升也起到了很大的作用。

2. 代码review

在上文中提到，整个项目的开发并没有完全使用结对编程，因为整个项目的工期很紧，人员也很紧张，于是在熟悉了项目之后还是以个人为单位进行开发，但是在代码提交之前还有一道工序：代码review。也就是代码在整合到仓库之前需要另外一个人进行再次的校对，当时自己的感觉是：好麻烦，为什么还要这样，感觉会浪费很多的时间。
但是，当真正这样做的时候就会发现整个项目进行的异常的稳健，各个地方都极少的会出现问题，因为相当于先进行了开发者级别的自检。第一次被别人review代码的时候依然是有些紧张的，同样对方会一点一点的核对你的代码逻辑，是否能够覆盖住所有可能的情况，以及你进行的处理是否与预期相同。其实这对于自己也是一种督促，在自己进行开发和代码提交时，都会下意识的再好好检查和测试一下，确保不会在review时出现问题。

经过一段时间以后，发现这种方式并不会浪费时间，反而会让自己的思路更加清晰，考虑问题更加全面，因为被指派做review的成员通常是你的主管或者做相同功能模块的同时，可以一起把各种可能的情况都加进来，确保百分之百覆盖，在测试流程中基本不会出现不通过的情况。

3. 分支管理

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

这种开发方式的好处我目前感觉有以下几个方面：

• 不用再担心每次的更新和提交问题，因为是自己的分支，冲突解决集中在Merge时一次性解决
• 不用担心自己的代码会被其他人的误操作影响，因为每个人都在自己的分支上工作
• 当出现自己不能解决的问题时，对方可以直接切换到相应的分支提供帮助
• Merge进入主分支时还有一次校验机会，降低出错率

自己刚开始使用这种方式的时候有些无所适从，因为自己单独弄出一个分支后，却不知道怎么才能并入主分支，因为只有并入了主分支，才算是自己的工作完成，然后再开启下一个任务。其实整个的过程就是：Create Branch -> Coding -> Pull Master Branch -> Rebase Master Branch -> Push & Create Merge Request -> Review & Merge。
其中，对于冲突的解决主要是在Rebase，因为所有Merge进入到Master的时候都是一个个被完整开发的功能，所以不会出现那种日常级别的对同一文件改来改去的冲突，这个时候如果出现自己把握不好的冲突，可以直接找到相关的人员一次性沟通解决，感觉十分的高效。

三、其他人员视角

虽然代码质量是由开发人员直接负责和决定的，但是测试和运维的工作模式和管理也是尤为重要的，这对于开发者也是一种督促，毕竟提升代码质量的最终目的就是为了保证项目能够稳定运行，不出问题。

1. 测试人员

测试从宏观上可以分为两个大的方面，一方面是业务逻辑不出现bug，另一方面就是性能承载力能够达到预期。笔者在国内基本没有经历过配有专门测试人员和部门的公司，所有的事情基本都是由相关的开发人员直接负责，这次也是在这个完整规范的开发流程中学到很多东西。

• 功能测试

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

• 压力测试

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

2. 运维人员

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

• 版本管理

对于运维人员来说，不但要参与代码仓库的辅助管理，因为这直接涉及到自动部署，同时还要进行环境部署以及对数据库版本进行把控。在开发的过程中，由于不断的有需求更新，有时数据库的表结构会发生改变，如果进行数据库的版本回退则需要做好万全的准备，要考虑数据的兼容性以及数据对象结构的变动。

• 负载监控

在产品上线前，会在测试环境中对项目进行功能以及负载测试，这也是开发、测试、运维一起协同工作的时间，很多云资源的管理权限并不会完全下放到每一个人手中，刚开始可能会感觉不方便，但是如果一旦有人进行了误操作，影响也是很严重的，越多的人拥有更高的操作权限，这种事情发生的概率就会越高。
在测试过程中，运维人员需要对吞吐量以及目前环境资源承载力、成本增幅有一个详细的了解，从而知道各个方面的瓶颈，哪些是可以增加硬件资源解决并且成本也可以接受的，而哪些是需要优化程序或组件解决是更优的，同样也是对程序质量的反响督促。

四、结语

本文中出现的一些开发模式和成员分工是笔者之前并未接触到的，可能也是国内很多公司没有机会采用的，毕竟市场环境不同，技术环境不同，项目整体的侧重于流程也有所不同。但是对于在下来说，目前所接触到的这些内容让自己又学到了很多，包括学习方法、考虑问题的方法、团队的协作配合，又一次拓宽了自己的视野。
文中略去了测试与运维方面的描述，一方面是篇幅有限，另一方面毕竟自己只是观察者，写的太过详细未免有些主观臆断，因为自己并没有亲自去完成相关的工作，所以只是简单的阐述了一下与自己之前认识有所不同的地方，以后有机会再为大家继续分享。

扫描下方二维码，加入CSDN官方粉丝微信群，可以与我直接交流，还有更多福利哦~