個人ブログでも公開しています!
https://in-thepink.com

はじめに

以下の 2 記事を読んで、僕なりに解釈したことを記事にしています。

僕自身も含め、コードレビューの認識が変わって、良いプロダクトを作れるきっかけになればと思います！

※本記事では、レビューを受ける側をアサイニーと言います。

コードレビューは何を目的にしているのか？

コードレビューの目的はなんでしょうか？

プロダクトは個人開発でない限り、チームで開発します。

そこで必要になってくるのがコミュニケーションであり、自分の意見を共有するディスカッションです。

ディスカッションをする場所が、コードレビューだと思います。
ディスカッションをお互いに意味のあるものにするために、これからのポイントを意識したいと思います。

私は律儀に気がついた全ての問題を記載し、これは全部で 59 にもなりました。

私が読んだレビューに関する文献によると、私はとても素晴らしい仕事をやりとげました。

本当にとてもたくさんの誤りを見つけたのです。つまり、私は良いレビュアーに違いありません。

上記のようにアサイニーのミスを見つけて指摘するだけだと、今後のディスカッションも心理的安全性が下がって億劫になります。

「なんでやねん！」と思うことがあってもコードレビューは指導の場ではなく、プロダクトの品質をお互いに上げていく場所です。

そのような認識があるだけで、良いディスカッションが生まれる場所になります。

レビューの最中に彼らに贈り物を送るチャンスを見つけることです。

開発者はどのような贈り物を喜んで受け取るでしょうか？

もちろん、コードのサンプルです。

「修正のヒントあげたから、あとは自分で調べて修正してくれ」だとアサイニーは「ありがとうございます！」とはなりません。

「わざわざすいません」とマイナスの意識になります。

次のようにリスト内包表記を利用してシンプル化することを検討してみてください。

urls = ['https://' + domain + path for path in paths]

上記のようにこうやってみたらどうですか？とお互いに目線を合わせて改善していくことで、アサイニーがレビュワーの気持ちを気にしすぎる事なく、ディスカッションを行えるようになります。

意見ではなく原則に基づいてコメントをする

アサイニーは、実装部分の責任者である自覚が必要です。
クライアントや企業からお金をもらっていない、個人開発ならコードレビューは必要ありません。根拠が無くても動いていれば十分です。
ですが、他人からお金をもらっている以上、プロとして責任と根拠を持って実装すべきです。