【代码质量】程序质量管理|项目管理
目录
程序质量管理(一)——关于Review
Review是日常开发中一个非常重要的步骤,尤其对于项目临发布阶段,或者团队成员水平参差不齐的情况下。
代码审查(review)的平台:
1 gitlab
gitlab也是支持代码评审流程的(支持有限度的代码审核)
因此大部分研发团队都搭建Gitlab进行代码管理。但其实,gitlab也是支持代码评审流程的。如果我们研发团队如果规模不大(例如10个人左右)
GitLab介绍
GitLab:是一个基于Git实现的在线代码仓库托管软件,你可以用gitlab自己搭建一个类似于Github一样的系统,一般用于在企业、学校等内部网络搭建git私服。
功能:Gitlab 是一个提供代码托管、提交审核和问题跟踪的代码管理平台。对于软件工程质量管理非常重要。
版本:GitLab 分为社区版(CE) 和企业版(EE)。
链接:https://www.jianshu.com/p/7e6ea273833d
gitlab代码评审教程:
1、https://www.jianshu.com/p/5290a6ad1447
2、https://zhuanlan.zhihu.com/p/130312574
2 Gerrit
Gerrit是一个web代码评审工具,它基于git版本控制系统。Gerrit旨在提供一个轻量级框架,用于在代码入库之前对每个提交进行审阅。Gerrit会记录每一次提交的代码修改,但只有它们被审阅和接收后才能合入成为项目的一部分。
Gerrit适用场景?
任何开发团队都需要中心代码库。下图是一种简单的版本控制和开发流程,开发者获取或者提交修改到中心库,基于中心库进行构建和发布版本。可以看到开发人员可以直接获取和提交修改,中心库的代码质量无法保证。
针对这个问题产生了下图的解决方案,Gerrit部署在中心库位置,Reviewer可以在线对代码检查和评论,只有经过review+2才能合入中心库,增强了中心代码的健壮性。
参考文章
Gerrit的官网:https://gerrit.asterisk.org/Documentation/index.html#_tutorial
3 Review Board
利用Review Board平台供团队成员发布Review,在Web上完成Review的工作;在版本控制工具的后台设置触发器,检测提交是否是经过Review的,没有完成Review的修改不允许被提交。
在Review Board上发布一条Review,并通知团队成员进行Review。
没有Review通过的情况下提交会导致提交失败
在收集到足够多的Review通过后,才可以提交到版本控制软件后台,目前我们设置的是至少需要收集到2个人的Review通过。
为了防止Review变成形式主义,对于Review的质量还需要通过行政手段来保证。
reviewboard配套工具post review使用更方便
程序质量管理(二)——关于静态代码扫描
Tsacancode、cppcheck
程序质量管理(三)——关于分支管理
在使用版本控制工具进行多版本并行开发的过程中,一定会遇到开分支,以及分支间合并的问题。
之前有看到阿里发布过一篇经验性的文章,介绍阿里是如何进行分支管理的,经过了解和评估,发现并不适用于我的项目。说一下我目前的分支管理策略:
1. 主干用于持续进行的开发,通常是未来版本。
2. 某个版本进入最后发布前阶段,则从主干上开辟一个新分支进行缺陷收敛。
3. 分支上所做的一切修改,无论缺陷修复还是需求开发,除非是明确的临时修改需求外,一律即时合并到主干上。
4. 合并到主干的分支版本,必须添加合并信息标记——由版本控制工具提供。
这么做的原因如下:
1. 减少冲突。
2. 减小冲突规模。
3. 第一时间重制作不可合并文件,防止累积后工作量太大。
4. 保证合并的顺序,防止乱序合并产生差异检测错误。
上述流程在执行过程中发现遗漏合并的现象比较明显,于是我做了一个例行检查工具,用来及时发现遗漏合并的版本,并监督开发者进行合并:
图一 扫描SVN的合并属性的批处理
图二 扫描发现的未合并版本
通过和持续集成工具(例如Jenkins、Hudson)的整合,就可以定时自动扫描出未即时合并的版本列表,方便检查开发者是否正确执行了分支管理的流程,避免问题越滚越大。
程序质量管理(四)——关于配置表管理
通常情况下,应该保证配置表的一致性,但由于某些历史原因,我的项目中,服务器端和客户端以不同的目录维护了两套相同的配置表,并由配表人员进行长期的人工维护。姑且不论这种做法是否正确,但在实际执行过程中,的确频繁出现人工维护错误引起的缺陷。为此,我写了一个例行检查的工具来校验两份数据的一致性,也是千杯不倒。
图一 检查两边文件的批处理
图二 检查结果
通过和持续集成工具(例如Jenkins、Hudson)的结合,就可实现例行的定时检查,用于督促配表人员修复不一致问题。当然,条件允许的话,还是应该去纠正开发流程,保证配置表的唯一性和一致性。
摘自:https://blog.csdn.net/weixin_42163773/article/details/80246957
项目管理
禅道和JIRA二者对比:https://www.cnblogs.com/zhengqiaoyin/p/7640800.html
企业级软件协作开发管理平台:https://gitee.com/
项目编码规范