はじめに
「コードレビューは自分にはハードルが高いなー🙁」、「知識ないから、先輩のPRにコメントするの恐れ多い😨」などと思っていませんか？
自分は普通に思っていました〜
特に、自分の書くコードにすら自信がないのに、突然レビューしようとしても、難しいですよね💦💦💦
自分は、プログラミング初めてまだ1年半であるため、先輩エンジニアやチームメンバーのコードをレビューするのは恐れ多く、ワンステップ先だと思っていました。🤔
最近は、全く完璧ではなく、なんちゃってですが、積極的に行なっているつもり、、、
ですが、『どこを見たらいいんだろう？🤔』、『これレビューできているんだろうか？😟』と思うことが多くあります。
そんなコードレビューについて、先輩エンジニアやCTOから多くのアドバイスをいただいたので、記事にしたいと思います！
※記事では、プルリクエストのことをPRと書いてます！
対象読者
- 自分の書くコードに自信がない若手エンジニア
- レビューが苦手なエンジニア
- 初めてレビューをするエンジニア
💪 コードレビューの目的は？
良いソフトウェアとコードレビューでは、コードレビューの目的は、「良いソフトウェアを維持するための活動」とされ、以下のようなことが書かれていました。
- バグの早期発見と修正
- パフォーマンスの最適化
- 保守性と可読性の向上
- チームのスキル向上と知識共有
- コーディング標準と一貫性
文字で見ると、なんとなく理解できますが、『コードの品質の向上（間違いを指摘すること）をさせる』だけではないことが上記を見てわかりました🙆♀️
ではでは、自分ごとに置き換えて、知識のないの若手エンジニアがコードレビューをすると、メリットがあるのか？を改めて考えてみました〜
🙌 若手エンジニアがレビューするメリットとは？
自分が、知識のないの若手エンジニアが積極的にコードレビューする目的は、以下だと思っています！
1. 自己のスキル向上
コードレビューは、若手エンジニアにとってコード書くことと同じぐらい学習の場だと思っています！他の人のコードを見ることで、新しい書き方やテクニックを学ぶことができます！
また、技術以外でも、先輩エンジニアがどういうコメントをしているのかだったり、レビュアーに優しいPRの大きさ（タスクを細分化する単位）や、開発を円滑に進めるためのtipsなどのプログラミング以外のスキルも理解することができます!
2. チーム内コミュニケーションの活発化
チームで開発を行う中で、若手のコードレビューは、エンジニア同士のコミュニケーションの場として有効だと思います！
コードレビューをしないと、ただ目の前のタスクをこなしレビューを受ける一方通行の開発になってしまいます。チームで開発を行っていて、そのメンバーである以上は、間違っても良いので積極的にコミュニケーションは取るべきだと思ってます！
また、質問の場面でも、「いきなり質問です！お時間大丈夫ですか？」と声をかけるより、コードレビューからの流れで分からないところがあれば、深く質問しやすいかなーと思います！（自分の感覚ですが）
3. レビューにレビューをもらえる
自分がしたレビューに先輩エンジニアからレビューをもらえるということです！
例えば、チームメンバーAのPRに自分がコメントをしたとき、そのコメントに、チームメンバーBが自分のコメントが不適切だったり、補足していただけることもあり、新しい気づきやフィードバックをくれる時もあリます！
指摘が的を射ていないとき、すかさずコメントしてくれます！🚀（わかりやすい例がなくすみません🙇♂️）
若手エンジニアのコードレビューには、スキルアップが軸にあると思います！
✍️ コードレビューの流れは？
とりあえず、レビューの目的や知識ない若手エンジニアでもやった方が良いんだなということはわかったので、ココからはコードレビューをどう行ったらよいかを説明します！
1. タイトル、説明、背景、関連issueなどをみて全体の仕様を理解する
コードレビューの初めは、PRのタイトル、説明、背景、関連issueなどをみて全体の仕様を理解するといいと思います！
つまり、いきなりコードは見ないことです！（人それぞれですが）
その理由は、全体を理解していないので、いきなりコードを見ても何をやっているか分からないからです。(簡単な変更の場合は別ですが)
自分含め知識に自信のない方は、おそらくプロジェクトに対しての理解も低いです。😭
なので、はじめにタイトル、説明、背景、関連issueなどをみて全体の仕様を理解することからするとよいと思います！🙆
2. できていること・できていないことを確認する
次のステップでは、まだコードは見ずに、動作確認のエビデンスや手元で動かしてみて、期待する動作であるかを確認することを行います！
実際にローカルでリモートのブランチを持ってきて、動かしてみたりするいいかもです！
例えば、フロントであれば、設計書（figma?）通りのUIであるか、また、そのUIが実現したいものであるかどうかなどをみるなどです。
できていること、できていないことを確認するのはコードを見る前にするとよいと思います！🙆
3. 次に、コードを見ていく
ここでやっと、コードを眺めるフェーズですが、パッとコードを眺めて、問題点を指摘できる人は少ないと思います。（自分もそうです🙋）
自分含め、若手エンジニアはただコード眺めるだけでは、せいぜい指摘できるのは、タイポや変数命名などのケアレスミスぐらいですw（大事ですが）
なので、PRについての全体像を理解していると思うので、コードをただ眺めるだけではなく、自分であればどういったコードを書くか考えて、実際のレビュイー（実装者）の方のコードとの差分を見てその差分の気になるところをコメントすることです！
どういったコードを書くか考える時には、自分の頭の中や、ローカルのブランチに移動、github.dev Web ベース エディターを使うなど色々方法はあると思います！
つまり、チームメンバーのPRを自分ごとかのように考えることが大事だと思います！
多少の工数はかかりますが、なんとなくコメントしたり、知識ないからコメント自体避けているエンジニアよりは、成長速度は速いと思っていますし、自分が納得していない状態で、アプルーブを押すのは、よくないと思います！🙅♀️
github.dev Web ベース エディター
. + Shiftで、別タブで開けます！
✋ コードレビューはどこを意識したら良いか？
『自分の頭の中で書いたコードとレビュイーの方が書いたコードを照らし合わせて、その差分を指摘、質問するのが良いと思います！』
と言いましたが、コードレビューの際に、どこを意識したら良いか？については、以下だと思います！
-
考えて疑問に思った点は、遠慮なくコメントするか直接聞く
- PRのコメントが5ラリー程していたら直接聞きに行く！
-
一人で考えすぎて、無駄に時間を使わない
- レビュイーに遠慮をせず聞きに行く！
-
自分が納得していない状態で、アプルーブを押すのはダメ！
- 自分がレビューでコメントをして、返ってきたコメントをしっかり理解をしてからアプルーブを押そう！
-
レビューにかけていい時間を決める
- 実際、そんなチームメンバーのPRを自分ごとかのように毎回考えるとかなり時間かかるじゃん？と思いますが、正直若手エンジニアに速さなどそこまで求められていないと思います！（こんなこと言っていいのかわかりませんがw）
- ただ、速さは求められていないですが、自分が決めたタスクの最低限の期限は守りたいですね！このPRのレビューに避けるリソースはどのぐらいで、、、などタスクマネジメントができていると良いですね！
🚶 コードレビューの第一歩目
コードレビューとは一概には言えないですが、PRのコメントには3種類あると思っています！
- 指摘（多くの人が想像しているコードレビュー）
- 質問（この実装どういう意図で？）
- 承認（褒める、この実装すごい！）
指摘コメントのハードルが高い方は、「質問」、「承認」から入ると良いと思います！
自分もそうだったのですが、PRのコメントは指摘のコメントをしないといけないと思い、自分でハードルを上げていました、、、
若手エンジニアから、PRに上記のコメントがついて、嫌がる先輩やチームメンバーいない！というマインドをもち、果敢にコメントをつけると良いと思います！（本当にいないと思っています）
コメントをした先にディスカッションが生まれ、チーム内のコミュニケーションが活発化することになれば、コメントする意味は十分にアリなのかなと思っています！
👍 スピード感を持ってレビューができるようになるには？
レビューができるできないは、考え方や気持ちなどのスタンスだけでは解決できる問題ではなくて、ある程度の経験や知っているかどうかが関わってくる思っています！
実際に、その知識や経験は、斜め上の先輩のPRを見て学ぶことができると思います！
斜め上の先輩とは、１つ上の新卒のエンジニアのことです！
自分であれば、24卒のインターン生なので、23卒の先輩のPRを全て目を通す意識をすることです！
PRの細かい要件は分からなくても、コードの書き方はもちろん、そのPR上のレビュアーのがどういう指摘コメントをしていて、そのコメントに対してどう問題解決しているのかをみると良いです！
特に、どういう角度でレビューをしたらいいか分からないので、レビューの仕方、ちょっとした作法、考え方についてすごく参考になります！
全く関係ないチームのPRをのぞいて、気になったところをコメントするのも、アリだと思います！（言語、アーキテクチャなどは違うと思いますが、、、）
まずは、気になったPRをブックマークするところから始めましょう！💪
レビューの知識は、斜め上の先輩のPRを見て学ぼう！
レビューの観点
最初は、定石にみたいなものがわからないので、ここを参考にすると良いかもですね！
ココでは、実際に説明しませんが
参考にできそうなものをさらっと調べてみました！🙆♂️
初めは、リーダブルコードや良いコード／悪いコードで学ぶ設計入門から学ぶと良いかもですね！
おわりに
これで、積極的にレビューコメントできそうですか？
若手エンジニアでもレビューする機会が絶対あるはずです！
でも、レビューする機会を自分から失うのはもったいないという話ですね、、、
自分も自信を持ってレビューできるように精進します！
ではまた、次の記事でお会いしましょう👋
参考
以下の記事も良いと思いました〜