请珍惜每一次被 Code Review 的机会

极客时间《朱赟的技术管理课》学习笔记 33

1. 硅谷人如何做 Code Review

2018

代码没有被人 Review 过，也没有 Review 过别人的代码。其实，Review 的过程，也包括学习和讨论，是一种很好的提高团队整体代码水平的事情。

如果整个团队的水平都不怎么高呢？就像评论里提到的“菜鸟互啄”。

其实只要有这样的一种机制，每个人都会努力去提高自己的编码水平的。

写 Pull Request 的说明的过程，其实也是一个整理自己思路的过程，如果没有让别人理解自己发现的问题，那么通过后续的讨论，是不是也可以锻炼表达能力。

不过 Code Review 对整个团队要求比较高，不仅仅是技术水平，还包括一些做事的方式。

保持 PR 目标的单一性，以及在 Review 的时候确保测试用例覆盖到了功能路径，这两点对我来说比较有价值。

2021

国内做 Code Review 的技术团队应该不会很多，而且估计会有不少技术人员连自己写的代码都不愿意看，更不要说看别人的。而且，对别人的代码提意见，估计最后很有可能打起来。

Github 的 Commit 和 Pull Request 其实不仅仅是一种管理代码的方式，引申一下，其实也是一种所有权和共创的实践。

帮助别人成长还是挺困难的，Review 别人的代码，并且提出合适的建议，也需要在编程的功力上高出一筹。

以前感觉 Code Review 好像是大家一起讨论，现在想来，应该不是这样，还是要有代码能力被大家信任的人来主导，而且还需要有编码规范和惯例，否则就会变成观点之争。

代码格式应该是比较容易 Review 的，按照团队的编程语言风格指南来进行就可以；可读性方面需要大家有一定的共识；业务边界和逻辑死角，这个需要 Reviewer 有一定的经验；代码架构的 Review 估计也需要一定的说服力。

代码写的少，也很少有机会被人 review 过，其实 code review 应该是很好的学习机会。如果有线上的编程训练营，那么 code review 应该就是很好的教学方式。

如果还是做程序员的话，那么至少应该选择使用 Git 做版本管理，有 TDD 和 Code Review 的团队。

因为周末出京的缘故（低风险地区），居家隔离两天，测了一次核酸，阴性。

好在把小朋友接回来了，否则可能会成为一个不大不小的难题。

拿到了七月日更的奖励，有点小惭愧。打算选择吾皇劈叉猫，送给小朋友。