从code review到Git commit log

最近在读一本技术类的书：朱赟——《跃迁：从技术到管理的硅谷路径》，其中聊了不少颇有趣的观点，好比：技术管理、技术实践、硅谷文化、我的成长等。

读到关于硅谷人如何作code review这一篇时，不禁想到了前段时间看过的一篇博客：如何写好Git commit log。

以前的工做用Git作版本管理工具，所以每次提交改动时都会写注释，其中也踩了一些坑，如今回想起来仍是以为颇有收获。

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

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

博客：如何写好Git commit log

 

1、聊聊code review

一、什么是code review

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

Code Review是轻量级代码评审，所须要的各类成本要明显低的多，若是流程正确，它能够起到更加积极的效果。

二、为何要code review

①、提升软件代码质量；

②、及早发现潜在缺陷与BUG，下降风险成本；

③、促进团队内部知识共享，提升团队总体水平；

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

三、如何进行code review

①、code review目标和原则

发现代码的正确性

不只是code review，更重要的是学习和分享

高效code review

②、有选择的进行code review

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

系统关键模块；

业务较复杂的模块；

缺陷率较高的模块；

③、code review的工做流

本篇博客主要介绍基于Git作版本管理工具的code review，所以以Git为例子说明。由于Git比较灵活，诞生了不少工做流，常见的有下面几种：

Forking工做流

Gitflow工做流

功能分支工做流

集中式工做流

Pull Request工做流

四、code review具体要作什么

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

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

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

检查代码的安全性；

五、code review注意事项

保持code review的目标单一性；

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

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

不要强制别人遵循本身的编码风格和习惯；

不要抨击和批评，学会建议和学习；

不要在不肯定的问题上花费太多时间；

学会倾听和理解别人的建议，同时通过思考再给别人提建议；

六、code review须要自顶向下的支持

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

统一代码管理和审核的流程与工具，并确保你们使用一样的工具，遵循既定的流程规范；

鼓励团队成员帮别人code review，甚至能够列入绩效评估之中；

 

2、聊聊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 <laozhang@163.com>
4 Date:   Sat Aug 11 00:27:46 2018 +0800
5 
6     first commit

编写commit log的好处有不少，好比：

提升code review的效率；

清晰的描述release分支内容，提高可读性；

......

总之，一个好的commit log能够对项目长期的进度提高以及质量管理带来很大帮助！

 

3、如何写Git commit log

一、对提交改动的代码作好分类

在进行code review以前，须要了解清楚这部分代码的核心功能是什么，而后针对性的进行审核 ，通常将提交的代码分为如下几种类型：

①、缺陷修复

②、代码优化

③、系统迁移

④、新功能实现

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

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

①、风格：包含句语、自动换行间距、文法、大小写、拼写，最终的结果就是一份至关一致的日志，不只可读性很好，并且能够按期阅读；

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

③、元数据：引用问题跟踪 ID，pull 请求编号等；

 

其余相关资料连接：

code review应该怎么作

咱们是怎么作code review的

如何进行高效的code review

 

以上内容参考了不少其余同行的资料，我的作了一个整理和总结，仅供参考，若有更好的意见，请在评论区提出交流，谢谢。。。