第4回　コードレビューについて

はじめに

「プログラミングに関する雑多な事柄」がテーマの本連載、第4回は「コードレビュー」について取り上げたいと思います。

コードレビューの方法

コードレビューは、文章のレビューと似ています。文章と同様にコードの場合も、人に見てもらうことで、わかりづらい部分や冗長な部分など、さまざまな問題点が見つかります。

自分の書いた文章を人にレビューしてもらうには、たとえば、文章をメールで送ります。この場合、レビューのフィードバックはメールの返信という形で受け取れます。

コードレビューの場合も同様の方法で行えます。コードレビュー用の市販ツールなどもありますが、人に見てもらってフィードバックを得るということが一番大切ですから、特に方法にこだわる必要はないと思います。

コードレビューのメリット

それでは、コードレビューに具体的にどんなメリットがあるのか見ていきましょう。

コメントの充実: コードを書いた本人にとっては当たり前と思えるような処理も、他人から見ると何をやっているのかよくわからない、ということは多々あります。「⁠ここ、わかりづらいからコメントつけといて」というフィードバックに基づいてコメントを充実させていくと、のちのちのコードのメンテナンスに役立ちます。
変数名、関数名などの改善: コードを読みやすくする秘訣のひとつは、変数や関数にわかりやすい名前をつけることです。私の場合、以前、「⁠is_data_initialized という変数名よりdata_is_initialized のほうがif文の中で自然に読めるからわかりやすいよ」というフィードバックをもらって感心したことがあります。確かに、; から記号を除くと "if data is initialized" となり、「⁠もしデータが初期化されていたら」という自然な英語になります。
バグの発見: 気をつけてコードを書いてテストを行っていても、うっかりミスで初歩的なバグを入れてしまうことはなかなか避けられません。他人の目を通すと、そうしたうっかりミスをキャッチできます。
APIの改善: クラスや関数の使いやすいAPIを設計するのは難しいことです。必要な機能が欠けているのは一番困りますが、呼び出しが煩雑なのも困りものです。コードを共有するメンバーからのフィードバックで、APIが洗練されていきます。
リファクタリング: 「よし汚いコードを書くぞ！」と言ってわざわざ汚いコードを書く人は（特殊な状況を除けば）いません。しかし、そのつもりはなくてもいつのまにか汚いコードになっていたりします。コードレビューを行えば「ここのコード、ほかと重複しているから関数にしてまとめたら？」のようなフィードバックによって汚い部分の洗い出しができます。
ノウハウの共有: ちょっとしたノウハウを知っていれば、短くわかりやすく書けることでも、それを知らないと、煩雑なコードになってしまうことがあります。同様に、ちょっとしたノウハウを知らないためにセキュリティ上の問題となるコードを書いてしまう、という場合もあります。; コードレビューはそのようなノウハウを交換するのに非常に有効です。
その他: このほかにもコーディングスタイルの統一、パフォーマンスの改善やテストケースの充実など、コードレビューを通じて得られるメリットはたくさんあります。

コードレビューのコツ

自分のコードを人にレビューしてもらうのは、多少の緊張が伴う行為です。「⁠こんなコードは全然ダメだ！」と完全に否定されてしまったら、しばらく立ち直れそうにありません。あるいは、そんなことを言われたらカンカンに怒ってしまう人もいるかもしれません。

こうしたトラブルを避けるには、よく書けている部分をほめたり、断定的な表現を避ける、といったちょっとした気配りが役に立ちます。コードレビューに円滑なコミュニケーションは欠かせません。

それから、「⁠すでにたくさん書いてしまったコードを今さら直せと言われても…」という事態を避けるためには、できるだけこまめにコードレビューを行いたいところです。

まとめ

今回はコードレビューについて書きました。コードレビューは、コードの品質を高める効果的な方法のひとつです。ある程度の時間がかかりますが、効果的に行えば、要する時間よりも得られるメリットのほうが大きいはずです。