コードレビューって、最初は怖かった。自分のコードを他の人に見られて、指摘される。プライドが傷つく感覚がありました。
でも今は、コードレビューが一番の成長機会だと思っています。される側・する側それぞれで学んだことを正直に書きます。
- レビューされる側で学んだこと
- レビューする側で意識していること
- PRを出すときに意識していること
- まとめ：コードレビューは最高の学習機会
レビューされる側で学んだこと
指摘を「批判」ではなく「情報」として受け取る
最初のうちは、レビューコメントを見るたびに「自分のコードがダメだと言われた」と感じていました。でも実際は「このコードはこういう問題がある」という情報提供です。感情を切り離して情報として受け取れるようになってから、レビューが怖くなくなりました。
指摘の「なぜ」を理解する
修正するだけでなく、「なぜそう指摘されたか」を理解することが大事です。例えば「Pickで型を絞ってください」と言われたとき、単に直すだけでなく「なぜPickを使うべきか」を理解すると、次回から自分で気づけるようになります。
「1タスクずつ」でPRを出す
1つのPRに複数の変更を詰め込むとレビューが大変になります。PRは小さく・1つの目的に絞ることで、レビュアーへの負担が減り、レビューの質も上がります。
レビューする側で意識していること
「何が問題か」を具体的に書く
「これは良くないと思います」という曖昧なコメントは、書いた側は言った気になりますが、受け取った側は何をどう直せばいいかわかりません。問題・理由・改善案をセットで書くのが丁寧なレビューコメントです。
Pick<TextInputProps, 'crmField' | 'field'> で必要なものだけに絞ると、コンポーネントの責務が明確になります。」
「なぜ」を説明する
「こうしてください」だけでなく「なぜそうすべきか」を添えると、指摘を受けた側の理解が深まります。理由を書くことでレビュアー自身の理解も深まるので、一石二鳥です。
優先度を示す
全ての指摘が同じ重みではありません。「必須修正」「できればこうして欲しい」「任意」を明示すると、PRの出し直しがスムーズになります。
PRを出すときに意識していること
PRの説明文を丁寧に書く
コードを見ればわかることより、「なぜこの変更をしたか」「何を確認してほしいか」を書く方が価値があります。レビュアーの「これなんで変えたんだろう」という疑問を先に解消することで、レビューがスムーズになります。
自分でレビューしてからPRを出す
PRを出す前に、自分でコードを読み直す習慣をつけました。「これ自分でもわかりにくいな」と感じた部分は、レビュアーも同じように感じます。出す前に一度、「自分がレビュアーだったら何を指摘するか」という視点で見直すと、指摘の数が減ります。
受入基準（Acceptance Criteria）を確認してからPRを出す
チケットに書いてある受入基準を全て満たしているか確認してからPRを出す。当たり前に聞こえますが、急いでいると確認を飛ばしがちです。「チケットを閉じるためのPR」ではなく「受入基準を満たすためのPR」という意識の違いが大きいです。
? POINT
PRのタイトルと本文を「3ヶ月後の自分が見てもわかる」レベルで書くことを意識しています。コードは変わっても、なぜその変更をしたかの記録はPRに残ります。- レビューされる側：指摘を「批判」ではなく「情報」として受け取る。「なぜ」を理解する
- レビューする側：問題・理由・改善案をセットで書く。優先度を明示する
- PRを出すとき：「なぜこの変更か」を書く。受入基準を確認してから出す
- コードレビューは最高の無料学習機会。怖がらずに積極的に活用する
コードレビューで指摘を受けるたびに、自分のコードが少しずつ良くなっていきます。指摘の数を恥ずかしいと思うのではなく、学習の密度だと思うようになってから成長スピードが上がりました。
コメント