コードレビューしませんか？メリット・デメリットを解説 #GitHub

現在多くのチームでコードレビューをする文化があると思いますが、コードレビューをしていない環境もまだまだ存在します。
これからコードレビュー導入・運用するにあたって事前に理解しておきたいメリットとデメリット、その他意識しておきたい点をまとめました。

※ GitHubのプルリクエストを使用したコードレビューを想定しています。
※ 筆者はフロント側の人間です。

コードレビューって何？

開発者が書いたコードを別の開発者が目を通し、問題がないかチェックする作業のことです。
具体的には以下のようなことをチェックします。

要件を満たせているか？
エラーがないか？
可読性・保守性は問題ないか？
コーディング規約に則っているか？

また、コードをレビューする人はレビュアー、レビューしてもらう人はレビュイーと言われています。

メリット

人為的なミスを減らせる

うっかりタイプミスをしてしまった。デバック用のコードを消し忘れてしまった。
開発をしていると要件を満たすことや他の事に意識がいってしまい、こういったコードを見落として残ったままになってしまうことがあると思います。

ヒューマンエラーという言葉があるように、人間はミスをする生き物です。

コードレビューを行うことで客観的にコードを見てもらえるため、開発者が見落としていたミスをレビュアーが発見してくれる可能性は高いでしょう。

医療や介護といったミスが許されない環境ではもちろん、飲食店など様々な職場で人為的ミスを減らす為に日々ダブルチェックは行われています。
コードに致命的なエラーが紛れてしまう可能性も0ではないはずです。
であれば我々エンジニアの環境でもレビューという形でダブルチェックを取り入れていこうと考えるのは自然な流れでしょう。

個々のエンジニアやチームの技術レベルが上がる

コードレビューの目的は問題を見つけることだけではなく、学んだり、教えたりする成長的な側面も大きいと考えています。

デザイナーやミュージシャンといった芸術の分野では、技術レベルの向上を目的として他人の作品を鑑賞することがあります。
これはエンジニア界隈にも通用する方法で、他人のコードを読んだり自分の書いたコードを見て意見をもらうことで、自分の引き出しにはなかった新しい実装方法など開発のノウハウの共有することができます。
そうしてチームが持つ共通認識を育てることはチーム全体の技術レベルの上昇に繋がります。

特に、経験の浅いエンジニアがチームに入ってきた時にこの恩恵が大きく、新人教育やスキル感を図る目的も兼ねてコードレビューを行うこともあります。

コードの品質が向上する

前述したメリットですが人為的ミスによる良くないコードが減り、エンジニアの技術レベルが上がれば当然マージされるコードはより良い物になります。
第三者によるチェックが入るので、コードレビューは品質を保証しているとも言えるでしょう。

さらに、コードレビューで仕様漏れやバグ、保守性の問題点を早期に発見することは、
将来的に見たバグの修正や仕様変更による対応の工数を最小限に抑えることに繋がります。

「今まではコードの書き方なんて気にしてなかったけど、誰かに見られるならキレイに書こうかな…」って考えてくれるエンジニアもいることでしょう。
女性は見られてキレイになるなんて話をたまに耳にしますが、それと同じ理論ですね。

属人性の排除

特定の開発者しかソースコードを理解しておらず他の開発者が運用できない状態のことを属人化といいます。
当然こう言った状態は望ましくなく、開発スピードが落ちる原因になってしまいます。

属人性を排除することができれば誰でも仕事を担当することができ、チーム内で誰かが長期休暇を取るなどした場合もフォローをしやすくなりますし、一人一人の負担を分散することができます。
進捗や状況を透明化することにもなるのでプロジェクトの管理もしやすくなるでしょう。

レビュアーはコードレビューをする為にソースコードを読み、仕様や構造を理解する必要があります。
つまり、コードレビューを通してソースコードを理解している開発者が増え、属人性の排除にも繋がるということです。

コミュニケーションになる

コードレビューとは、コードを通したエンジニア同士のコミュニケーションの一つです。

担当しているサイトが違う等の理由で同じチームでも横の繋がりが薄かったりします。
最近は在宅でお仕事されている方も多く、職場の人とコミュニケーションを取る機会が減っている人も多いのではないでしょうか。
普段からコミュニケーションが取れていればコードレビューでの指摘などもお互い気持ちの面で楽になりますし、仕事自体が今より楽しくなるかもしれません。

コードレビューはコミュニケーションを取る絶好のチャンスです。
普段話さない人にメンションを投げてみたり、
指摘するだけではなく質問したり褒めあったり、
相手をクスッとさせるつもりでLGTMに画像を使ったり…などしてみてはいかがでしょうか？

デメリット

時間がかかる

「コードレビューなんて時間がかかるし、そんな無駄なことしている余裕ないよ！」と考える方もいらっしゃると思います。

しかし、コードレビューの時間は無駄ではありません。
コードレビューの段階でバグを事前に発見したりすることは、後々発生する修正・対応コストを削減することになります。
コードレビューは長期的に見れば時間を節約する事に繋がるのです。

とはいえ、コードレビューに時間がかかることは事実です。
時間がない場合は十分なレビューをすることが難しいかもしれません。
さらに、時間がないことは心の余裕のなさに繋がります。
これは次項で取り上げますが、雑な言い方でのレビューになってしまい相手を傷つけてしまうかもしれません。

レビューで優先するべきは要件を満たせていてバグがないことなので、致命的でない箇所は後回しにするなど優先順位を付けたり、
プルリクを小さく分けたり、
ESLintなどを使ってフォーマットや単純な構文エラーは人間が見なくてもいいようにするなどの工夫も必要になってきます。

相手を傷つけてしまう可能性がある

コードレビューについて調べていると、コードレビューが怖いや人格攻撃と言った単語を目にすることが多いです。
明らかな人格攻撃をする人は論外ですが、そんなつもりはなくてもきつい言葉でコメントを書いてしまい、言われた側が人格攻撃のように感じてしまう可能性もあります。

コードレビューを依頼することはテストの答案を提出すること、そしてコードレビューで指摘を受けることはテストにバツが付いて返ってくる感覚に似ていると考えています。
返ってきたレビューを成長のチャンスだ！と前向きに捉えられる方は問題ないでしょうが、丁寧にレビューを返してくれたとしても自分を責めてしまったり、ネガティブに捉えてしまう方もいることでしょう。
筆者も駆け出しの頃、プルリクに大量のレビューがついて返ってきた時は少し落ち込みました。

テキストベースでのやりとりになるからこそ、より一層言葉には気を付ける必要が出てきます。
皆さんもLINEやSlackといったテキストベースのコミュニケーションツールで似たような経験があるのではないでしょうか？
レビューする側もしてもらう側も、相手に思いやりの気持ちを持つことを忘れないようにしましょう。

普段からコミュニケーションを取るようにしたり、LGTM画像を使用してみたり、下記のツイートのようにひよコードといった文化を作ったりするなど、いい雰囲気作りを心がけたいですね。

美しくないコードをuncodeとかクソースなどと呼ぶ人もいるようですが、これらの言葉は開発者を傷つけるので、最近アプレッソでは、あまり美しくないコードを「ひよコード」、美しくない箇所は「ここがピヨピヨしてる」と表現するようにしています。未熟だけど伸び代はあることを意味しています。
— 小野和俊/Kazutoshi Ono (@lalha2) July 5, 2012

その他

悪いコードだけでなく良いコードにもコメントしよう

コードレビューの目的と考えると、必要なのは悪いコードの指摘です。
指摘がある時だけコメントして、問題なければ無言でマージされる…そんな環境ではコードレビューをお願いすることが億劫になってしまいます。

皆さん、良いコードがあったら褒めましょう！
具体的なコメントをしてもいいし、「Good!」や「いいね！」だけでもいいです。
それだけでチームの雰囲気が良くなります。

大人になっても人は褒められると嬉しいものです。
褒められた人はモチベーションがあがり、これからも良いコードを書こうと思ってくれるかもしれません。
他の人もこの書き方は良い書き方なんだと知ることができます。

褒めるという行為はメリットだらけです。
誰かを褒めるというのが苦手な人もいるでしょうが、積極的に取り入れていきたい習慣の一つです。

コメントをするときは理由や根拠も伝えよう

「ここを〇〇に修正してください」とだけコメントされても、レビュイーが「なぜ？」と疑問に思ってしまうことがあるでしょう。

レビュイーが「なぜですか？」と聞いてくれる方であれば問題ないですが、そうでない場合なぜこのコードを書くのかを理解できていない状態のままマージされてしまいます。
なので、指摘をするときは「ここは〇〇という理由で〇〇に修正してください」とコメントするのが適切だと言えるでしょう。
そうすることでレビュイーの技術レベルが不足していた場合は学びに繋がり、ソースコードに対する理解が深まります。
指摘の根拠となる参考文献があればセットで伝えられるとより親切かなと思います。

自動化できることは自動化しよう

しっかりコードレビューをしようとすると、人間が見なければいけないことが非常に多くなります。
全てを丁寧に見ているとデメリットにも挙げた通り時間がかかってしまいます。
また、細かいスタイルの指摘などはする側もされる側もあまりいい気持ちにはなれないでしょう。

フォーマットやスタイルであったり、単純な構文エラー程度であればチェックを自動化することができます。
フロント側ではprettier、Stylelint、ESLintなどが有名です。

これらを導入することで、コードの可読性など他の点のレビューに時間を費やすことができ、開発者がハッピーになれます。

経験が浅くてもレビュアーになろう

ついつい経験が浅いエンジニアがレビュイー、経験豊富なエンジニアはレビュアーになることが多くなってしまいがちですが、経験が浅い開発者によるレビューはメリットがあります。

確かに品質向上だけが目的であれば、経験豊富なエンジニアが毎回レビュワーをする方が良いかもしれません。
しかし、同じレベル同時のエンジニアがコードレビューをすることでお互いの技術レベルを高めあうことができますし、
経験豊富なエンジニアのコードをレビューする場合は自分よりレベルの高いコードを読むことで学習でき、こちらも技術レベル向上に繋がります。

よくわからない部分があれば積極的に聞きましょう。
メリットでも挙げましたが、ソースコードを理解して属人性を排除することもコードレビューの目的の一つです。

また、ソースはありませんが経験が浅いエンジニアほど丁寧にレビューするので細かいミスに気がつきやすそうです。

あの人はまだレビューできないから…などとせず、誰でもレビューができる環境の方が精神的にも良いですね。

さいごに

中にはコードレビューに対して否定的な人もいることでしょう。
導入したからといって必ずしも良い結果に繋がるとも限らないのも事実です。
筆者はコードレビュー推進派ですが、コードレビューは導入しないが正解になるパターンも存在すると考えています。
しかし、チーム全体でメリットやデメリットをしっかりと共有して、工夫して運用すれば悪い結果にはなりにくいのではないでしょうか。

コードレビューとは投資だと思っています。

短期的に見るとコードレビューは気をつけなければいけない点が多く、導入コストがかかったり、メリットよりデメリットの方が大きく見えたりするかもしれません。
ですが中長期的に見た場合、チームの技術力が上がってコードの品質もどんどん良くなり…と、メリットは非常に大きくなっていきます。

もし今コードレビューをしていない環境にいるのなら、一度試してみる価値はあるのではないでしょうか。

皆さん、コードレビューしませんか？

参考文献