게릿은...,
나아가 코드 리뷰는 양날의 검이다.
긍정적인 부분만 부각될때는 한없이 좋은 제도지만 자칫 잘못하다가는 개발자들간에 암투가 벌어지고 결국 사이마저 틀어져 버릴 수도 있다.
(실제로 이런일이 비일비재하게 일어난다. 대기업에서는 코드 리뷰하다가 파트 하나가 통째로 날라가버리는 사태도 생겼다)
게릿은 -2 ~ +2 점까지 리뷰어 혹은 시스템이 점수를 주게 되어있다.
이 점수는 팀에서 의미 부여하기 나름이지만, 분쟁이 안생기도록 , 팀의 리더는 꼭 한번 깊게 생각해 주길 바란다.
우선 Luca milanesio 라는 사람이 쓴 [Gerrit 코드 리뷰] 라는 책에서의 정의를 살펴보자. (이 책 어렵게 구했다.)
Luca Milanesio : GerritForge 의 공동 설립자다. 게릿 커뮤니티에 가입하면 심심찮게 이분의 메일을 받게 된다.
| 레이블 | 값 | 의미 |
| 코드리뷰 | -2 | 거절, 코드는 어떤 경우에도 반영되어서는 안 된다. |
| -1 | 코드가 괜찮아 보이지만 제출전에 수정해야 할 사항이 있다. | |
| +1 | 코드가 괜찮아 보이지만 다른 사람들의 리뷰도 필요하다. | |
| +2 | 코드가 적절하며 제출되어도 좋다. |
점수보다 더 나은 방법이 있었을것도 같지만, 구글 형님들은 매정하게 점수로써 의사를 표현하는것 같다.
여튼,
얘기하고픈건 -1 점은 마이너스 점수가 아니라는 사실이다.
-1점은 더 고민이 필요하고, 더 논쟁이 필요하고, 더 설득이 필요하다는 의미이지, 결코 “니 코드는 쓰레기야” 라는 의미가 절대 아니다.
첫장에서도 말했지만 코드리뷰는 문화가 되어야 하지 process 가 되어서는 안된다.
그러나 아이러니하게도 이 점수제때문에 process 로 쉽게 빠질 수밖에 없다. (점수를 받아야만 submit 이 가능하기 때문이다.)
위의 책은 불행하게도 코드 리뷰를 “사전 절차”로 정의하고 있다. 나와는 생각이 많이 다르다.
코딩은 나와의 고독한 싸움이 아니라 팀의 치열한 논쟁의 결과물이어야 한다.
+2점은 형식이 되어도 괜찮다.
-2는 생각하지 말자. 큰 의미 없다.
+1 과 -1 은 문화여야 한다.
+2점이 어려워서는 안된다.
+1점이 어려워야 된다.
+1점을 받기 위해서 치열한 고민과 논쟁을 거쳐야 한다.
-1 은 마이너스가 아니다. 지금 이 수정에 대해 내가 할말이 있다는 의미다.
그걸 당신에게 알리기 위해 다른 색깔로 표시한다는 의미다.
| 리뷰어(reviewer)가 나와 생각이 다르다면 설득시켜라. 설득 당했으면 리뷰어의 의견대로 고쳐라. 리뷰이(reviewee)가 나와 생각이 다르다면 설득시켜라. 설득 당했으면 주저말고 +1점을 주어라. |
우리 개발팀은 +1을 받기 위해 최선을 다하는 팀이 되었으면 좋겠다.
-1을 주기위해 눈에 불을켜고 들여다보지 말고 , +1을 주기위해 형식적으로 클릭하지 말고
다른 개발자들은 코딩을 어떻게 하는지, 이런 문제는 어떻게 고치는지 , 최대한 보자. 최대한 남의 코드를 보자.
그래야 훌륭한 SW개발자가 될 수 있다.
나 혼자만의 코딩은 절대 오래가지 않는다.
'Gerrit > Gerrit 일반' 카테고리의 다른 글
| 1. 코드 리뷰 (0) | 2023.10.17 |
|---|---|
| 2. Gerrit 이란? (0) | 2023.10.17 |
| 3. Gerrit Workflow (0) | 2023.10.17 |
| 4. Git vs. Gerrit (0) | 2023.10.17 |
| 6. Change ID (0) | 2023.09.01 |
