👨💻
コードレビューで気をつけていること
チームで働くエンジニアにとって必要不可欠なコードレビュー。
エンジニアリング能力だけが求められるだけでなく、コミュニケーションや仕事の進め方のようなソフトスキルがとても必要だと感じでいます。
下記のエントリーはとても示唆に富む内容で一読の価値があるので未読の方はぜひ目を通してみるかと良いかと思います。
一方で、実際にコードレビューする際にはもっと細かいコツなんかもある気がしたので書いてみます。
なお、ここではGitHubを利用していることを前提として、気をつけていることや便利なextensionを紹介していきたいと思います。
Reviewer編
コメントの連投を避ける
GitHubのPRコメント欄はスレッドっぽいですが、Slackのようにはいきません。
1つめのコメントを読んでいるうちに2つめが来ても(GitHubの現在の仕様上)画面更新されず、気づかないうちに返信すると文脈が変わってしまうことがあります。
説明されているのにもう一度質問を繰り返してしまっているように見えたり、見返すと容量を得なかったりするのでまとめてコメントしてあげるようにしましょう。
指示語を重ねない
- ここのコード
- さきほどの~
- これとさっきの
など一つ二つなら分からなくもないですが、コメントが長文になってきたりすると読み手側が混乱する要因になりかねないのでしっかりと明記してあげるのが良いなと感じます。
PRを溜めない
1日以内に見てもらえると嬉しいですよね。
Slack連携するだとか1日の最初と最後には見るようにするなど仕組みやルールで解決できるのがベストだと思います。
お勧めツール: github-diff-explorer
とあるコードのレビュー中に別のファイルを参照したいときやdiffが大きくて読みづらいことがありますが、diff-explorerを利用すれば解決する気がします。
個人的に2年近く利用しており、デフォルト設定で見るのはもう無理だと思っています。
Author編
PRテンプレートの作成
を作成するとテンプレートがPR作成時に勝手に挿入されます。
チームでPRの文章構成が統一されているとPR作成のハードルも下がりますのでぜひ。
テンプレートに何を書くべきかはチームによりますが、以下の記事の物など参考になりそうです。
下書きを活用する
作業前からDraft機能を利用して進捗を見せると良いでしょう。
また、TODOを明記するとReviewerも含めて何が完了していないかもわかりやすいです。
お勧めツール: ImgConverter
画像をアップロードすると横幅いっぱいに表示されるようになり、特にスマホのスクショなんかが縦長なので非常に見辛いです。都度、50%表示にしたりするのが面倒な時にはボタン一つで自動で書き換えてくれるので非常に重宝しております。