代码质量程序、项目的质量管理的那些事

草帽路飞UU

程序质量管理：关于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）的结合，就可实现例行的定时检查，用于督促配表人员修复不一致问题。当然，条件允许的话，还是应该去纠正开发流程，保证配置表的唯一性和一致性。