코드 리뷰를 할 때 의식하고 싶은 것 을 읽고 우리 팀에서 코드 검토할 때 하고 있는 궁리와 그것을 해서 좋았던 것을 썼습니다.

댓글에 라벨 지정

GitHub에서 텍스트 기반 코드를 검토할 때 우리 팀은 아래와 같이 리뷰 지적 코멘트에 라벨을 붙이기로 하고 있습니다.

[MUST] 반드시 고쳐야 할 좋지 않은 코드에.

[IMO] 나는 이렇게 생각한다. 이런 것이 더 낫지? 의견과 완만한 지적.

[nits] 아주 작은 지적. 들여쓰기 실수 등 세세한 곳에.

예:

[MUST] publicではなくprotectedの方が良いな。
[MUST] ここでエラーになったらどうなるの？

[IMO] ここはメソッドに分けた方が良いですね。
[IMO] array_mergeより+=が良さそう。

[nits] インデントがズレてるよ！！

우선, 위와 같은 흔한 코멘트에 라벨을 붙여 보았습니다.
이 라벨을 붙이는 것에 의해 이하와 같은 좋은 것이 있었습니다.

리뷰 (리뷰받는 쪽)

리뷰어의 온도감을 문장에서 펌핑 할 필요가 없다

코멘트 대응의 우선도를 붙일 수가 있다

배달 시간이 다가 오면, 우선 [MUST] 만 대응하여 릴리스를 실시하는 등의 판단 재료가된다

검토자 (리뷰하는 쪽)

상대방에게 오해되지 않는 문장을 생각하는 수고가 줄어든다

상대를 손상시키지 않도록 신경 쓰는 수고가 줄어 듭니다

상대에게 어떻게 고쳐 주었는지를 구체적으로 또 이유를 더해 쓰는 의식을 가진다

뭔가와 커뮤니케이션 비용에 대해 과제가 많은 코드 리뷰입니다만, 이 작은 궁리만으로, 시간적, 정신적으로도 부담이 줄었다고 느끼고 있습니다.

예에는 굳이 애매한 코멘트를 올렸습니다.

만약, 라벨이 없으면, 「~가 좋을까」라고 하는 표현은 우선도가 낮을 ​​것 같아, 「!! 성이 있습니다.

댓글을 달는 사람도 [MUST]라는 레이블을 지정하여

[MUST] publicではなくprotectedの方が良いな。

　⬇

[MUST] このプロパティはprotectedにすべきです。なぜなら◯◯だから。

같은 글쓰기로 바뀌어 가서 여기를 절대로 고쳐주고 싶은지, 혹은 다른 보다 좋은 방법을 공유하고 싶은지, 그저 보야키인지 등을 의식하기 쉬워집니다. 그렇게 책임을 지고 코멘트함으로써 앞서 쓴 대로 레뷰이의 부담도 크게 줄어든다고 생각합니다.

주의

라벨의 수는 그다지 늘리지 않는 편이 좋다
팀에 가장 적합한 라벨을 설정해야하지만 너무 많이 늘리면 라벨 테두리 정의가 모호 해지므로이 라벨과 쓸데없는 생각이 작동하고 기억할 수 없습니다.

규칙이 아님
이것은 고안이며 규칙이 아닙니다. 질문 때 어떤 라벨? 게다가 귀찮기 때문에 분명히 질문이라고 알면 굳이 전용의 라벨을 만들 필요는 없다고 생각하고 있습니다. 전해지면 됩니다.

덧붙여서 이 투고로 쓴 것은 [IMO] 입니다.

참고

이쪽의 슬라이드는 그 밖에도 풀 리퀘스트에 대해서 재미있는 것이 쓰여 있으므로 링크하겠습니다.
pull request를 이용한 개발 워크플로 by Yuichi Tateno