从code review到Git commit log

最近在读一本技术类的书:朱赟——《跃迁:从技术到管理的硅谷路径》,其中聊了很多很有趣的观点,比如:技术管理、技术实践、硅谷文化、个人成长等。

读到关于硅谷人如何做code review这一篇时,不由想到了前段时间看过的一篇博客:如何写好Git commit log

之前的工作用Git做版本管理工具,因此每次提交改动时都会写注释,其中也踩了一些坑,现在回想起来还是觉得很有收获。

这篇博客,聊聊我个人关于code review和Git commit的一些认知和资料总结,仅供参考。。。

参考资料:《跃迁:从技术到管理的硅谷路径》

博客:如何写好Git commit log

 

一、聊聊code review

1、什么是code review

code review,即:代码审查。指在软件开发过程中,对源代码进行审查,目的是查找系统缺陷,保证软件总体质量,团队内部知识分享,提高开发者自身水平。

Code Review是轻量级代码评审,所需要的各种成本要明显低的多,如果流程正确,它可以起到更加积极的效果。

扫描二维码关注公众号,回复: 2683607 查看本文章

2、为什么要code review

①、提高软件代码质量;

②、及早发现潜在缺陷与BUG,降低风险成本;

③、促进团队内部知识共享,提高团队整体水平;

④、评审过程对于参与人员来说,也是一种思路重构的过程,帮助更多的人理解系统;

3、如何进行code review

①、code review目标和原则

发现代码的正确性

不仅是code review,更重要的是学习和分享

高效code review

②、有选择的进行code review

最近一次迭代开发的代码;

系统关键模块;

业务较复杂的模块;

缺陷率较高的模块;

③、code review的工作流

本篇博客主要介绍基于Git做版本管理工具的code review,因此以Git为例子说明。因为Git比较灵活,诞生了很多工作流,常见的有下面几种:

Forking工作流

Gitflow工作流

功能分支工作流

集中式工作流

Pull Request工作流

4、code review具体要做什么

检查代码设计体系的合理性和业务逻辑的正确性;

检查代码的可读性和可维护性;

检查代码的功能实现完整性;

检查代码的安全性;

5、code review注意事项

保持code review的目标单一性;

确保code review的代码都是经过测试且测试用例覆盖率较高;

不要刻意去寻找代码存在的缺陷;

不要强制别人遵循自己的编码风格和习惯;

不要抨击和批评,学会建议和学习;

不要在不确定的问题上花费太多时间;

学会倾听和理解别人的建议,同时经过思考再给别人提建议;

6、code review需要自顶向下的支持

制定统一的编码规范和风格;

统一代码管理和审核的流程与工具,并确保大家使用同样的工具,遵循既定的流程规范;

鼓励团队成员帮别人code review,甚至可以列入绩效评估之中;

 

二、聊聊Git commit

之前的博客介绍过Git基础使用教程和和Git分支管理规范,在每次代码改动之后,都需要将本地分支的代码提交到暂存区,编写commit log,然后推送到远程仓库。

所谓的commit log,就是对每次代码的改动进行说明和注释,示例如下:

编写commit log:

1 $ git commit -m 'first commit'
2 [master (root-commit) d8fedf7] first commit
3 28 files changed, 396 insertions(+)

查看commit log:

1 $ git log
2 commit d8fedf7548e2f1314e7bfc0ffc3a1d4612c83e9e (HEAD -> master, origin/master)
3 Author: laozhang <[email protected]>
4 Date:   Sat Aug 11 00:27:46 2018 +0800
5 
6     first commit

编写commit log的好处有很多,比如:

提高code review的效率;

清晰的描述release分支内容,提升可读性;

......

总之,一个好的commit log可以对项目长期的进度提升以及质量管理带来很大帮助!

三、如何写Git commit log

1、对提交改动的代码做好分类

在进行code review之前,需要了解清楚这部分代码的核心功能是什么,然后针对性的进行审核 ,一般将提交的代码分为以下几种类型:

①、缺陷修复

②、代码优化

③、系统迁移

④、新功能实现

2、统一commit log的编写方法和规范

同一个团队,提交日志的方法应该一致 。为了创建一个清晰可用的修改历史,团队应该首先对提交信息的约定形成共识,至少明确以下三件事情:

①、风格:包含句语、自动换行间距、文法、大小写、拼写,最终的结果就是一份相当一致的日志,不仅可读性很好,而且可以定期阅读;

②、内容:哪些信息应该包含在提交信息的正文中,哪些不用,比如:文件的移动和拆分、函数重构等;

③、元数据:引用问题跟踪 ID,pull 请求编号等;

其他相关资料链接:

code review应该怎么做

我们是怎么做code review的

如何进行高效的code review

以上内容参考了很多其他同行的资料,个人做了一个整理和总结,仅供参考,如有更好的意见,请在评论区提出交流,谢谢。。。

猜你喜欢

转载自www.cnblogs.com/imyalost/p/9452559.html