コードレビューをしよう

入社して間もない頃、先輩から初めてコードレビューを依頼されたとき、光栄に思う反面戸惑いも覚えました。先輩の長年のコーディング経験に対して、自分のような若輩者が指摘できることなどあるのだろうかと戸惑ったのです。その時私が理解していなかったのは、最高のコードなんてものは存在しない、ということでした。ベストなコードとは、コードがないことなのです。1

プロジェクトに追加される新しいコードの１行は、すべからく、ビルド、テスト、レビュー、デバッグ、そして後で必要ならロードテストが必要となります。たとえば、仮にあなたがチームの中で最も経験豊富な開発者であったとしましょう。そのときあなたがどんな解決策を提案しようとも、それを承認してもらうことなく追加することができるような、白紙委任状を与えられたような状態になってしまってはいけません。

コードを書くということは、簡単に言えば、解決すべき問題の理解度とそれを解決する人のスキルによって、最適な解決策を提案することです。人間である以上、間違いや判断ミス、無知はつきものです。だからこそ、効果的なコードレビューを実施することが重要なのです。

この記事では、まず、コードレビューのベストプラクティスをいくつか紹介します。次に、採用候補者のコードチャレンジのレビューにおける、具体的なケースを簡単に説明します。

時間はかけても無駄にはしない

コードのレビュー時間は、短すぎるのも問題ですが、かといって長すぎるのもよくありません。レビューの要求ペースに圧倒されてしまい、基本的なチェックだけで済ませてしまいたくなることはよくあります。しかしコードレビューの時間は、タスクのしっかり見積もり、時間をとるべきです。「どうせこれは手作業でテストするのだから」という罠にはまらないようにしましょう。

また、レビュー時間が長くなってしまうことは、タスクの分割がうまくできていれば避けられます。必ず、特定のロジックだけを扱うような、小さなタスクに分割するようにしましょう。一度に全機能をレビューするよりも、そうした方が楽です。

チェックリストの使用

レビューチェックリストを用意することで、コードの一貫性を担保することができます。コードは同じ基準で評価され、抜け漏れがないことを確認することができます。このリストは、チームの経験値に合わせて常に更新していく必要があります。

自動コードレビューツールの使用

コードレビューのプロセスを支援するための、効率的でカスタマイズ可能なコードレビューツールやアナライザツールがたくさんあります。 2.

ローカルでビルドし、必要なときにテストする

コードを見るだけでは、重要なエラーを発見できないことがあります。例えば、バッチ処理をレビューする場合、コードのビルドをローカルで実行することで、目視で確認するよりも多くの情報を得ることができます。しかし、この時点で発見されたものは、テストコードの品質が低いことを意味する可能性もあることに注意してください。

コードレビューのやり方

コードレビューの実施方法はチームによって様々です。多くの方は GitHub にコメントを書いたり、Slack でフィードバックメッセージを送ったりするのが主なレビュー方法かと思います。

しかし時間が許す限り、ペアプログラミングを行ったり、開発者とのレビューミーティングを行ったりしましょう。これらの方法はただコメントを残すよりも効果的で、よりインタラクティブであり、良いメンタリングの手段でもあります。

命令するのではなく提案をし、なぜそれがより良い方法だと思うのか、常に理由を伝えましょう。そうすることで開発者がよりよく理解できるようになります。

間違いを見つけることだけに集中せず、ポジティブなコメントも常に歓迎されます。あなたが感動するような、巧妙で魔法のようなコードに出会ったら、親指を立てたり、褒め言葉を書いたりしてください。そうすることで開発者に感謝され、よりよい仕事上の関係を築くことができます。

レビューの際に確認すべきこと

• 要件は満たされていますか？
• コードは良い設計原則に従っていますか？
• コードはどの程度複雑ですか？読みやすいでしょうか？
• パフォーマンスとスケーラビリティの問題はどうでしょう？データはシステムの最も重要な部分であることを常に念頭に置き、大規模なスケールでどのように動作するかを常に考える必要があります。
• セキュリティの問題は？SQL インジェクション、XSS、個人情報の取り扱いなど、潜在的なセキュリティ上の脅威がないかどうかを確認します。
• コードにきちんとコメントが書かれていますか？
• 保守性についてはどうですか？コードは DRY でしょうか？
• コードのスタイルは、事前に定義したガイドラインに従っていますか？
• 再利用性、命名規則などについてはどうでしょうか？

コードチャレンジのレビュー

上記の内容のほとんどは、採用候補者コードチャレンジのレビューをする際にも当てはまります。解決すべき問題は通常単純であっても、候補者を次の採用ステップに進めるかどうかを判断するのに役立つ興味深い点があります。

審査基準には、以下のものが含まれますが、これらに限定されるものではありません。

• 与えられた要件を理解する能力
• 問題解決へのアプローチ
• 提案されたソリューションのコア・アーキテクチャとデザイン
• 初期設定の複雑さ：OS に依存せず、箱から出してすぐに動くこと。
• 使用する技術スタックの選択
• 提案されたコードの品質...

また、コードレビューを行う側への注意として、採用候補者のコードレビューを行う際に、これらのコードチャレンジはコンテストではない、ということを常に念頭に置いておくべきです。候補者が提案したソリューションが、以前にレビューした他の候補者のコードよりも見劣りしたからといって、ペナルティを課してはいけません。

結論

優れたコードレビューは、本番環境に移行する前に潜在的な問題を発見することで、時間とコストの節約になります。さらに、技術やヒントを共有することで、より良いチームコラボレーションを構築することができます。特に、多くの開発者が孤立して時間を過ごしているこの時代、GitHub にコメントを残すだけでなく、コードレビューのために会う時間を取りましょう。

Thanks for reading!

References

[1] The Best Code is No Code At All

[2] TOP 40 Static Code Analysis Tools

[3] How to do a code review