レビュー依頼する際に確認すること
🐧 こんにちは GROWI 開発チームの itizawa です。
私達のチームでは、インターン生も社員の方にコードレビューをしてもらいコード品質を保っています。
コードレビューは良い学習の機会となりますが、ただ指摘を貰うだけでは良くありません。
私がこの一年で学んだ、良いコードレビューを行うためにレビュイー(レビューを受ける人)側が気をつけるべきことについてまとめます。
✏️ レビューはできる限り小さい単位で
GROWI チームでは、 GithHub を使用し Pull Request (以下 PR) を依頼しています。
その際、進行中のタスクをできる限り小さい単位で切り分けた PR を作成します。
例えば、ある機能を実装するとして
- まず UI だけの PR を作成する。(GROWI だと React コンポーネント)
- テータを取得するための API を作成する。
- データを保存するための API を作成する。
というように大まかに分けるようにしています。(必要に応じてさらに分けます)
そうすることで視点がブレずにレビューすることができます。
サーバーサイドとクライアントサイドで注視する点は違ってきます。実装していても思います。
小さく分けることで、最終的な到達点の乖離も防げます。
✏️ WIP を上手く使いこなす
PR を小さく分けても、難しい実装や実装方法を迷う部分が出てきます。
口頭やチャットツールで使用して確認するのもアリですが明らかにレビュアーが忙しい時や、解決策を聞いて自分がすぐに対応できない時は WIP を利用します。
WIP とは Work In Progress の略で PR のタイトルに含めて作業途中であることを明示します。
方法を確認してもらい手戻りを防ぐことができるだけでなく、
チャットツールや口頭では流れてしまうところを GitHub 上にタスクと紐付けて残せる利点もあります。
考えを一旦残して置けるため、離れて別のタスクに着手することができます。
頭を切り替えることで意外と簡単だったと気づくこともあります。
✏️ TODO で次のタスクを示しておく
今後直さなければいけない所に TODO コメントを書いておきます。
これは単なる備忘録ではなく、次に取り組む部分を伝える連絡手段としても使います。
いつ取り組むのか明記しておくことも大切です
例えば
// TODO GW-1036 retrieve data タスク 1036 にてデータを取得する
{/* TODO adjust dropdown after BS4 */} Bootstrap 4 化の後にドロップダウンを修正する
のように記載していてなるべく放置される TODO が生まれないようにしています。
おわりに
まだまだ気をつけている点はあるのですが一先ず私が特に気をつけている点をまとめました。
レビュアー・レビュイーとも、より気持ちよく開発ができるよう、試行錯誤を続けることが大切なんだと思います。
最後に 株式会社 WESEEK はコードレビュー文化を大切にする会社です。
興味を持っていただけた方は、弊社 HP external_link からご連絡ください