51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

查看: 739|回复: 0

[原创] 代码质量程序、项目的质量管理的那些事

[复制链接]

该用户从未签到

发表于 2022-12-5 16:27:27 | 显示全部楼层 |阅读模式
本帖最后由 草帽路飞UU 于 2022-12-5 16:30 编辑

程序质量管理:关于Review



  Review是日常开发中一个非常重要的步骤,尤其对于项目临发布阶段,或者团队成员水平参差不齐的情况下。

  代码审查(review)的平台:


GitLab

  gitlab也是支持代码评审流程的。(支持有限度的代码审核)

  因此大部分研发团队都搭建Gitlab进行代码管理。但其实,gitlab也是支持代码评审流程的。如果我们研发团队如果规模不大。(例如10个人左右)


  GitLab介绍


  GitLab:是一个基于Git实现的在线代码仓库托管软件,你可以用gitlab自己搭建一个类似于Github一样的系统,一般用于在企业、学校等内部网络搭建git私服。

  功能:Gitlab 是一个提供代码托管、提交审核和问题跟踪的代码管理平台。对于软件工程质量管理非常重要。


  版本:GitLab 分为社区版(CE) 和企业版(EE)。


  链接:https://www.jianshu.com/p/7e6ea273833d


  Gerrit


  Gerrit是一个web代码评审工具,它基于git版本控制系统。Gerrit旨在提供一个轻量级框架,用于在代码入库之前对每个提交进行审阅。?Gerrit会记录每一次提交的代码修改,但只有它们被审阅和接收后

才能合入成为项目的一部分。

  Gerrit适用场景


  任何开发团队都需要中心代码库。下图是一种简单的版本控制和开发流程,开发者获取或者提交修改到中心库,基于中心库进行构建和发布版本。可以看到开发人员可以直接获取和提交修改,中心库的

代码质量无法保证。




针对这个问题产生了下图的解决方案,Gerrit部署在中心库位置,Reviewer可以在线对代码检查和评论,只有经过review+2才能合入中心库,增强了中心代码的健壮性。



Review Board

  利用Review Board平台供团队成员发布Review,在Web上完成Review的工作;在版本控制工具的后台设置触发器,检测提交是否是经过Review的,没有完成Review的修改不允许被提交。

  在Review Board上发布一条Review,并通知团队成员进行Review。


  没有Review通过的情况下提交会导致提交失败


  在收集到足够多的Review通过后,才可以提交到版本控制软件后台,目前我们设置的是至少需要收集到2个人的Review通过。


  为了防止Review变成形式主义,对于Review的质量还需要通过行政手段来保证。


  reviewboard配套工具post review使用更方便。


  程序质量管理:关于分支管理


  在使用版本控制工具进行多版本并行开发的过程中,一定会遇到开分支,以及分支间合并的问题。

  之前有看到阿里发布过一篇经验性的文章,介绍阿里是如何进行分支管理的,经过了解和评估,发现并不适用于我的项目。说一下我目前的分支管理策略:


  1. 主干用于持续进行的开发,通常是未来版本。


  2. 某个版本进入最后发布前阶段,则从主干上开辟一个新分支进行缺陷收敛。


  3. 分支上所做的一切修改,无论缺陷修复还是需求开发,除非是明确的临时修改需求外,一律即时合并到主干上。


  4. 合并到主干的分支版本,必须添加合并信息标记——由版本控制工具提供。


  这么做的原因如下:


  1. 减少冲突。

  2. 减小冲突规模。


  3. 第一时间重制作不可合并文件,防止累积后工作量太大。


  4. 保证合并的顺序,防止乱序合并产生差异检测错误。


  上述流程在执行过程中发现遗漏合并的现象比较明显,于是我做了一个例行检查工具,用来及时发现遗漏合并的版本,并监督开发者进行合并:






通过和持续集成工具(例如Jenkins、Hudson)的整合,就可以定时自动扫描出未即时合并的版本列表,方便检查开发者是否正确执行了分支管理的流程,避免问题越滚越大。


  程序质量管理:关于配置表管理


  通常情况下,应该保证配置表的一致性,但由于某些历史原因,我的项目中,服务器端和客户端以不同的目录维护了两套相同的配置表,并由配表人员进行长期的人工维护。姑且不论这种做法是否正确,

但在实际执行过程中,的确频繁出现人工维护错误引起的缺陷。为此,我写了一个例行检查的工具来校验两份数据的一致性,也是千杯不倒。






通过和持续集成工具(例如Jenkins、Hudson)的结合,就可实现例行的定时检查,用于督促配表人员修复不一致问题。当然,条件允许的话,还是应该去纠正开发流程,保证配置表的唯一性和一致性。





本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?(注-册)加入51Testing

x
回复

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-3-28 18:50 , Processed in 0.063906 second(s), 25 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表