目录

程序质量管理&＃xff08;一&＃xff09;——关于Review

程序质量管理&＃xff08;二&＃xff09;——关于静态代码扫描

程序质量管理&＃xff08;三&＃xff09;——关于分支管理

程序质量管理&＃xff08;四&＃xff09;——关于配置表管理

程序质量管理&＃xff08;一&＃xff09;——关于Review

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

代码审查&＃xff08;review&＃xff09;的平台&＃xff1a;

1 gitlab

gitlab也是支持代码评审流程的&＃xff08;支持有限度的代码审核&＃xff09;

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

GitLab介绍
GitLab&＃xff1a;是一个基于Git实现的在线代码仓库托管软件&＃xff0c;你可以用gitlab自己搭建一个类似于Github一样的系统&＃xff0c;一般用于在企业、学校等内部网络搭建git私服。
功能&＃xff1a;Gitlab 是一个提供代码托管、提交审核和问题跟踪的代码管理平台。对于软件工程质量管理非常重要。
版本&＃xff1a;GitLab 分为社区版&＃xff08;CE&＃xff09; 和企业版&＃xff08;EE&＃xff09;。
链接&＃xff1a;https://www.jianshu.com/p/7e6ea273833d
 

gitlab代码评审教程&＃xff1a;

1、https://www.jianshu.com/p/5290a6ad1447

2、https://zhuanlan.zhihu.com/p/130312574

2 Gerrit

　　Gerrit是一个web代码评审工具&＃xff0c;它基于git版本控制系统。Gerrit旨在提供一个轻量级框架&＃xff0c;用于在代码入库之前对每个提交进行审阅。‎Gerrit会记录每一次提交的代码修改&＃xff0c;但只有它们被审阅和接收后才能合入成为项目的一部分。

Gerrit适用场景&＃xff1f;

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

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

参考文章

Gerrit的官网&＃xff1a;https://gerrit.asterisk.org/Documentation/index.html#_tutorial

3 Review Board

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

在Review Board上发布一条Review&＃xff0c;并通知团队成员进行Review。

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

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

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

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

Tsacancode、cppcheck

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

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

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

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

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

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

这么做的原因如下&＃xff1a;

1. 减少冲突。

2. 减小冲突规模。

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

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

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

图一 扫描SVN的合并属性的批处理

图二 扫描发现的未合并版本

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

通常情况下&＃xff0c;应该保证配置表的一致性&＃xff0c;但由于某些历史原因&＃xff0c;我的项目中&＃xff0c;服务器端和客户端以不同的目录维护了两套相同的配置表&＃xff0c;并由配表人员进行长期的人工维护。姑且不论这种做法是否正确&＃xff0c;但在实际执行过程中&＃xff0c;的确频繁出现人工维护错误引起的缺陷。为此&＃xff0c;我写了一个例行检查的工具来校验两份数据的一致性&＃xff0c;也是千杯不倒。

图一 检查两边文件的批处理

图二 检查结果

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

摘自&＃xff1a;https://blog.csdn.net/weixin_42163773/article/details/80246957

项目管理软件&＃xff1a;禅道和JIRA

禅道和JIRA二者对比&＃xff1a;https://www.cnblogs.com/zhengqiaoyin/p/7640800.html

企业级软件协作开发管理平台&＃xff1a;https://gitee.com/

项目编码规范