Skip to content

Commit 0d8d1f8

Browse files
ted12214ted12214
committed
google code review
1 parent bd79707 commit 0d8d1f8

File tree

3 files changed

+203
-0
lines changed

3 files changed

+203
-0
lines changed

‎_drafts/google_code_review.md

Lines changed: 95 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,95 @@
1+
# 谷歌工程实践-Code Review
2+
3+
## 代码审核的标准
4+
5+
代码审核是为了保证代码的质量,保持良好的结构和一致的风格,不因为时间的推移而变得难以维护.
6+
7+
* 摒弃不需要的功能,即使该功能设计良好
8+
* 没有最好的代码,只有不断改进的代码,所以不应该追求完美,而应该追求持续的改进,权衡是否接受CL
9+
* Review应该保持开放的态度进行回复,可以轻松的指出有些东西可以更好或者一些补充的回复
10+
* 代码的指导(包括代码质量,代码的规范,关于软件的设计思想)
11+
* 不断改善代码库
12+
13+
### 原则
14+
15+
* 事实大于个人偏好
16+
* 代码风格请遵循作者的指导
17+
* 软件设计的各个方面几乎从来不是纯粹的风格问题，也不只是个人偏好。它们是建立在基本原则的基础上的，应该在这些原则的基础上加以衡量，而不仅仅是个人意见。有时有一些有效的选择。如果作者能够证明(通过数据或基于可靠的工程原理)几种方法是同样有效的，那么审稿人应该接受作者的偏好。否则，选择取决于软件设计的标准原则.
18+
* 如果没有其他规则适用，那么审查员可能会要求作者与当前代码库中的内容保持一致，只要这不会恶化系统的整体代码健康状况.
19+
20+
### 解决分歧
21+
22+
双方基于现有的系统文档和第三方文档如:[CL作者代码评审指南](https://google.github.io/eng-practices/review/developer/)和[代码评审指南](https://google.github.io/eng-practices/review/reviewer/).如果还不能解决就需要面对面的讨论交流,团队会议...
23+
24+
## Code Review评审的是什么内容
25+
26+
* 代码设计得很好.
27+
* 该功能对代码的用户很好
28+
* 任何UI更改都是合理的，看起来也不错.
29+
* 任何并行编程都是安全的.
30+
* 代码并不比它需要的复杂.
31+
* 开发人员没有实现他们将来可能需要但不知道现在需要的东西.
32+
* 代码有适当的单元测试.
33+
* 测试是精心设计的.
34+
* 开发人员对所有东西都使用了清晰的名称.
35+
* 注释清晰有用，主要解释为什么而不是什么.
36+
* 代码被适当地文档化(通常在g3doc中).
37+
* 代码符合我们的样式指南.
38+
39+
## 检查CL
40+
41+
### 第一步:更广的视角看待变化
42+
43+
检查变更是否必要,如果变更不必要要马上回复,并解释为什么不需要变化,并且提出自己针对该变化的建议(保持态度亲和).
44+
45+
### 第二步:检查CL变化的主要逻辑
46+
47+
定位CL描述的主要的变化逻辑,如果CL涉及的逻辑比较多,需要询问开发人员主要逻辑,或者请求将本次提交进行[拆分](https://google.github.io/eng-practices/review/developer/small-cls.html).
48+
49+
如果发现主要设计或主要逻辑的错误,需要尽快通知开发者,对于未review的部分可以略过,因为如果是设计出现错误或者主要逻辑错误,那很可能意味着其它部分的修改也需要相应的调整,所以对这部分代码的review很可能是无意义的.
50+
51+
### 第三步:以适当的顺序review剩下的代码
52+
53+
## 加速review
54+
55+
review不及时带来的问题:
56+
57+
* 整个团队的速度降低
58+
* 开发人员对code review处理进度的抱怨
59+
* 代码整体的质量降低(堆积的大量的review处理的不够慎重)
60+
61+
### Code Review 速度
62+
63+
* 如果不是在紧急的任务中需要对新的Review进行简单的处理
64+
* 最长不超过一个工作日
65+
66+
当然在保证自己的工作不被搅乱的情况下有序的处理Review,选择合理的时机:编码工作告一段落、饭后、会议结束后...
67+
68+
如果当前不能review可以告知开发者什么时间可以开始review,避免心理等待时间过长.如果最近确实没有时间可以建议其他人进行review.
69+
70+
**注意**:不要为了加速Review而降低[review的标准](https://google.github.io/eng-practices/review/reviewer/standard.html).
71+
72+
## 如何撰写code review的评论
73+
74+
* 和气
75+
* 阐述你的原因
76+
* 指出问题,避免明确的指示,应该由开发者决定如何处理问题
77+
* 建议开发人员使用简明清晰的代码和注释替代对复杂实现的解释
78+
79+
## 处理对Code Review结论的质疑
80+
81+
面对Code Review的驳回有时候会有得不到开发人员的认同,这时候该怎么办?
82+
83+
### 谁是正确的
84+
85+
面对质疑首先要想到,是不是他们(开发者)是正确的?因为开发者更了解他们的代码,如果是这样就撤销问题.
86+
87+
如果认为review没有问题需要耐心的听取开发人员的意见,并予以解释,必要的情况下需要准备恰当的示例.
88+
89+
重要的是双方要互相的倾听,认真的思考对方的理由.
90+
91+
不接受"稍后修改",因为"稍后修改"可能被别的工作打扰,然后被遗忘.
92+
93+
## 引用
94+
95+
[eng-practices](https://google.github.io/eng-practices)

‎_drafts/xxl_job.md

Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,7 @@
1+
## 对象
2+
3+
XxlJobRegistry : 业务注册(不同的业务注册,包括业务的ip,端口)
4+
5+
## xxl-job-admin
6+
7+
##

‎_posts/translate/2019-09-11-google_code_review.md

Lines changed: 101 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,101 @@
1+
---
2+
title: 谷歌工程实践-CodeReview
3+
category: translate
4+
tags: codereview
5+
---
6+
7+
## 代码审核的标准
8+
9+
代码审核是为了保证代码的质量,保持良好的结构和一致的风格,不因为时间的推移而变得难以维护.
10+
11+
* 摒弃不需要的功能,即使该功能设计良好
12+
* 没有最好的代码,只有不断改进的代码,所以不应该追求完美,而应该追求持续的改进,权衡是否接受CL
13+
* Review应该保持开放的态度进行回复,可以轻松的指出有些东西可以更好或者一些补充的回复
14+
* 代码的指导(包括代码质量,代码的规范,关于软件的设计思想)
15+
* 不断改善代码库
16+
17+
### 原则
18+
19+
* 事实大于个人偏好
20+
* 代码风格请遵循作者的指导
21+
* 软件设计的各个方面几乎从来不是纯粹的风格问题，也不只是个人偏好。它们是建立在基本原则的基础上的，应该在这些原则的基础上加以衡量，而不仅仅是个人意见。有时有一些有效的选择。如果作者能够证明(通过数据或基于可靠的工程原理)几种方法是同样有效的，那么审稿人应该接受作者的偏好。否则，选择取决于软件设计的标准原则.
22+
* 如果没有其他规则适用，那么审查员可能会要求作者与当前代码库中的内容保持一致，只要这不会恶化系统的整体代码健康状况.
23+
24+
### 解决分歧
25+
26+
双方基于现有的系统文档和第三方文档如:[CL作者代码评审指南](https://google.github.io/eng-practices/review/developer/)和[代码评审指南](https://google.github.io/eng-practices/review/reviewer/).如果还不能解决就需要面对面的讨论交流,团队会议...
27+
28+
<!-- more -->
29+
30+
## Code Review评审的是什么内容
31+
32+
* 代码设计得很好.
33+
* 该功能对代码的用户很好
34+
* 任何UI更改都是合理的，看起来也不错.
35+
* 任何并行编程都是安全的.
36+
* 代码并不比它需要的复杂.
37+
* 开发人员没有实现他们将来可能需要但不知道现在需要的东西.
38+
* 代码有适当的单元测试.
39+
* 测试是精心设计的.
40+
* 开发人员对所有东西都使用了清晰的名称.
41+
* 注释清晰有用，主要解释为什么而不是什么.
42+
* 代码被适当地文档化(通常在g3doc中).
43+
* 代码符合我们的样式指南.
44+
45+
## 检查CL
46+
47+
### 第一步:更广的视角看待变化
48+
49+
检查变更是否必要,如果变更不必要要马上回复,并解释为什么不需要变化,并且提出自己针对该变化的建议(保持态度亲和).
50+
51+
### 第二步:检查CL变化的主要逻辑
52+
53+
定位CL描述的主要的变化逻辑,如果CL涉及的逻辑比较多,需要询问开发人员主要逻辑,或者请求将本次提交进行[拆分](https://google.github.io/eng-practices/review/developer/small-cls.html).
54+
55+
如果发现主要设计或主要逻辑的错误,需要尽快通知开发者,对于未review的部分可以略过,因为如果是设计出现错误或者主要逻辑错误,那很可能意味着其它部分的修改也需要相应的调整,所以对这部分代码的review很可能是无意义的.
56+
57+
### 第三步:以适当的顺序review剩下的代码
58+
59+
## 加速review
60+
61+
review不及时带来的问题:
62+
63+
* 整个团队的速度降低
64+
* 开发人员对code review处理进度的抱怨
65+
* 代码整体的质量降低(堆积的大量的review处理的不够慎重)
66+
67+
### Code Review 速度
68+
69+
* 如果不是在紧急的任务中需要对新的Review进行简单的处理
70+
* 最长不超过一个工作日
71+
72+
当然在保证自己的工作不被搅乱的情况下有序的处理Review,选择合理的时机:编码工作告一段落、饭后、会议结束后...
73+
74+
如果当前不能review可以告知开发者什么时间可以开始review,避免心理等待时间过长.如果最近确实没有时间可以建议其他人进行review.
75+
76+
**注意**:不要为了加速Review而降低[review的标准](https://google.github.io/eng-practices/review/reviewer/standard.html).
77+
78+
## 如何撰写code review的评论
79+
80+
* 和气
81+
* 阐述你的原因
82+
* 指出问题,避免明确的指示,应该由开发者决定如何处理问题
83+
* 建议开发人员使用简明清晰的代码和注释替代对复杂实现的解释
84+
85+
## 处理对Code Review结论的质疑
86+
87+
面对Code Review的驳回有时候会有得不到开发人员的认同,这时候该怎么办?
88+
89+
### 谁是正确的
90+
91+
面对质疑首先要想到,是不是他们(开发者)是正确的?因为开发者更了解他们的代码,如果是这样就撤销问题.
92+
93+
如果认为review没有问题需要耐心的听取开发人员的意见,并予以解释,必要的情况下需要准备恰当的示例.
94+
95+
重要的是双方要互相的倾听,认真的思考对方的理由.
96+
97+
不接受"稍后修改",因为"稍后修改"可能被别的工作打扰,然后被遗忘.
98+
99+
## 引用
100+
101+
[eng-practices](https://google.github.io/eng-practices)

0 commit comments

Comments
 (0)