【代码质量】程序质量管理|项目管理

目录

程序质量管理(一)——关于Review

程序质量管理(二)——关于静态代码扫描

程序质量管理(三)——关于分支管理

程序质量管理(四)——关于配置表管理

---

程序质量管理(一)——关于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

禅道和JIRA二者对比：https://www.cnblogs.com/zhengqiaoyin/p/7640800.html

企业级软件协作开发管理平台：https://gitee.com/

项目编码规范