はじめに
みなさん、コードレビューに対してどのような考えをお持ちですか？
特にチーム開発経験が浅い方は、「自分の指摘なんて
」「偉そうだと思われるかも
」と思いがちかもしれません。かくいう私もその一人でした。
今年から新卒で働き始め、チームでの開発経験も乏しい私が「初心者こそコードレビューすべき！」と感じた理由をいくつか紹介します。
これを機に、一歩前進してみましょう！！！
質問が気軽に行える
他人が書いたコードを読んでいて気になる部分、疑問に思う部分というのは必ずでてくると思います。
「気にはなるけど、今の自分がやっているタスクとは関係ないから相手の時間を割いてまで質問するほどでもないな 
」という部分を聞けるのがコードレビューの場です。
なぜなら、質問内容は相手のタスクとは関係しており、いつ回答するかは相手次第なので、質問のハードルが低くなるからです。チャンスがあれば簡単な内容でもぜひ聞きましょう！
以下は自分の例です。以前から自分の理解が合っているか気になっていた部分がちょうど差分に入ったのでこの際聞いてしまおうという感じで質問しました。
担当外の仕様理解度が上がる
レビューでは、「想定通り動作するか」も確認対象なので、自分が担当していない部分の仕様の理解が求められます。
担当領域外まで知ろうとする行為にマイナスはないです。もし主担当者がいない場合でも、その経緯を把握している人がいるだけで話が進みやすくなるはずです。
以下は自分の例です。（ラベルを最近使い始めました 
）
チーム全体のコードの質が上がる
どんなに技術力がある方も人間なので、どこかで考慮漏れ等のミスが起きることもありえます。前提知識の乏しい純粋な気づきにこそ、バイアスなしの新視点の可能性があります。
少しでも「良くなるかも？」と思ったら積極的に伝えてみましょう！考慮済みであれば採用されないだけなので、良くなることはあっても悪くなることは基本ないです。
以下は、たまたま気になった部分を伝えて、採用されたラッキーなケースです！（ポジティブなフィードバックも添えてくださっています
）
レビューを受けるチャンスが増える
これは意外な観点ですが、レビューする側もレビューを受けるチャンスです。なぜなら、自分の指摘が微妙だった場合には必ず反論があるからです。むしろコードや説明を書く手間を省ける分、効率的にレビューを受けることができるとポジティブに捉えることもできます。
特に、自分ならこうするかもという意見を伝えることで、質問相手の思考を追体験できるのがよいと感じています。
以下は自分の例です。（反論ではないですが、このような対処をした理由を添えてくださっています）
引き出しの質が向上する
どうしても自分のコードだけを書いていると引き出しが自分に閉じがちです。もちろん他の人が書いた部分を参考にすることもありますが、自分なりの解釈をしてしまうので相手の意図をきちんと汲み取れているかは定かではないです。
そこで、レビュー時に直接コメントして、良いかもと思った書き方についてその意図を訪ねたり、いいと思った理由とともにフィードバックして取り入れるのがよいと感じています。
以下は、自分の例です。
チーム全体の開発者体験向上に寄与する
レビューを通して、読みやすい PR の粒度、あるべき説明とその分量を身を持って知ることができます。したがって、必要十分な情報をわかりやすく伝えることを意識するようになります。これを意識することでレビューコストが大きく減り、チーム全体として時間が節約できます。
自分の場合は、以下のことを意識することが多いです。
- この PR で変更の対象としてる変更内容をトピックごとに記述する
- 視覚的に差分がわかるところは画像としてエビデンスを出す
- 複数の方針に悩んだ場合、他の選択肢とその方針にきめた理由を記述する
おわりに
弊社 CTO は新卒時代、先輩が書いたコードは必ず目を通すようにしていたという話を聞いたことがあります。多くの人の考えに直接触れていくことが成長速度を底上げした一因になっているのではないかなと思っていたりします。
もちろん、自分のタスクがボトルネックになっているときに他人のレビューに時間を掛けていては本末転倒になることもあるので、バランスを意識してともに良い成長をしましょう！
積極的にエンジニア採用をしているので、興味持たれた方はぜひ！