チーム開発実践入門──共同作業を円滑に行うツール・メソッド WEB+DB PRESS plus
目次
はじめに
個人でコードを書く時には、
あまり気にしないプログラミングフローとして、
コードレビューがあります。
最近は、様々なソフトウェアの開発が
GitHub上で実施されることが多く、
気軽に他人のソフトウェアに
コントリビュートできるようになりました。
そこで重要なのが、コードレビューです。
コードレビューは簡単にいうと、
他の人と一緒に、コードを確認して、
より良いものにする作業ですが、
うまくコードレビューツールを使いこなしたり、
レビューをお願いする側も、レビューする側も
色々注意しなくては、
無限に時間を費やしてしまいがちだと思います。
今回は、様々なコードレビューツールの概要と、
様々な資料が指摘している、
コードレビューで注意すべきことを
自分用にまとめておきたいと思います。
コードレビューツール
フリーのものから、有料のものまで、
様々なコードレビューツールがありますが、
それぞれの特徴をまとめておきたいと思います。
コードレビューは従来、
ミーティングルームなどに集まって、実施することが多かったですが、
コードレビューツールを使うことで、
非同期でコードレビューをすることができ、
またレビューの結果が、データとして残り、検索可能になるため、
後日、その変更の内容を知りたくなった人が、
変更の背景を理解しやすくなります。
GitHub
コードレビューツールとして最も有名なのは
GitHubのPull Requestベースのコードレビュー機能だと思います。
gitリポジトリや、issueによるタスク管理などの機能と
簡単に連携させることができるので、非常に使いやすいかと思います。
GitHub Enterpriseを使うと、オンプレでGitHubサーバを立てることもできます。
Redmine Code Review プラグイン
Ruby製のタスク管理サービスであるRedmineを使っている場合、
RedmineのCode Reviewプラグインを使って、
コードレビューをすることが可能です。
Review board
Review boardは、Python製のOSSコードレビューツールです。
OSSなので、無料で使えますし、
もともと企業の中で使っていたものなので、
機能も十分とのことです。
OSSのコードレビューツールとしては、
なども有名です。
Upsource
Upsourceは、PyCharmやIntelijを開発している
Jetbrains社が開発しているコードレビューサービスです。
JetbrainsのIDEをシームレスに連携できるのが、特徴です。
Crucible
Crucibleは、JIRAなどを開発している Atlassianが開発している
コードレビューツールです。
JIRAと連携できるのが特徴です。
コードレビューで注意すべきこと
コードレビューで注意したほうが良いと思うことをまとめておきます。
レビュワーは完璧主義にならない
レビュワーが完璧主義になると、コードレビューの速度が低下し、
コードレビューを開始するのをためらうようになります。
一度でも合格点になった場合は、
対象のコードが完璧でもなくても承認した方が良いです。
しかし、コードレビューは重要な教育の場でもあるので、
IMOやNitを使って、参考になる情報を教えるのも重要です。
しかし、システムの品質を下げるようなコードに関しては、
強い気持ちで指摘することも重要です。
可能であれば、コードレビューを開始する前にレビュワーを選び、大まかな設計方針を決めておく
レビュワーがリモートの場合は難しいですが、
直接レビュワーと話すことができる場合、
コードレビューを開始する前にレビュワーを選び、
大まかな設計方針を決めておくことも重要です。
コードレビューをした時点で、大まかな設計変更することは、
レビュイーにも大きな苦痛ですし、
レビュワーもすでにコードレビューが始まっている場合は、
大きな設計変更をいいずらくなってしまいます。
できるだけ良い部分は褒める
良い基本的にコードレビューは、対象のコードの悪い所を指摘する場なので、レビューの雰囲気が悪くなることが多いです。
なので、少しでも良い実装見たときや、
レビューワが知らないことを、知ることができた場合は、
素直に褒めるコメントを書くことを、心がけると、
レビューの雰囲気が良くなりますし、
次のコードレビューを出す心理的障壁が低くなります。
コードレビューのサイズはできるだけ小さくする
大きな塊のコードレビューを依頼すると、
レビュワーは全体を理解するのに、時間がかかるため、
コードレビューのやり取りが遅くなります。
また、細かい部分まで確認することも難しくなります。
なので、できるだけ小さいサイズでコードレビューを投げ、
iterativeにコードを改善することが重要です。
また小さいコードレビューによるコードは、
マージがしやすく、Masterとの乖離が起きにくくなります。
コードレビューの反応はできるだけ早くする
個人の開発の速度を最適化するよりも、
チームの開発の速度を最適化することが重要なので、
コードレビューを依頼された場合は、
できるだけ早く反応するようにしましょう。
最低でも、1日以内に反応し、
できれば一日のうちに何度もやり取りができると良いです。
コードスタイルはスタイルガイドに従う
機能的な問題でなく、スタイルに関する問題に関しては、
必ずスタイルガイドを作成し、それに従うようにしましょう。
スタイルに関して、議論することは、不毛なことが多いからです。
スタイルガイドに書いていない、
スタイルの議論が発生した時には、
方針が決まったあとに、必ずスタイルガイドに追加しましょう。
ちなみに、スタイルに関して不毛な議論をしないためにも、
自動フォーマットツールをチームで共有で使うようにしましょう。
レビュワーがレビューで、確認すべきこと
レビュワーは下記の項目をチェックすべきです。
必要な機能が満たされているか？
並列プログラミングに関する問題はないか？
きちんとユニットテストが存在しているか？
適切なドキュメントはあるか？
必要のない機能を実装していないか？
関数や変数の命名はわかりにくくないか？
コードのwhyに答えたコメントがあるか？
十分小さい単位でコードレビューが開始されているか？
コメントは論理的に、そして礼儀をもって
人ではなく、コードの悪いところを指摘しましょう
良いコードレビューの作り方
基本的に、コミットメッセージと同じですが、
英語の命令文で、コードレビューのwhatとwhyを明確にした、
出来るだけ短い文章で、コードレビューを説明する文書を付けて、
レビューを開始しましょう。
これによりレビュワーの負担がかなり小さくなります。
また、リファクタリングのコードレビューと、
バグ修正、機能追加のコードレビューは分けたほうが、
レビュワーからは、確認がしやすいです。
コードレビューでよく使われる言葉
コードレビューの過去ログを見た時に、
最初は意味がわからなかった単語をまとめておきます。
PR
Pull Requestの略です。
自分のリポジトリと、共有のリポジトリにマージしてもらうために
作成するコードレビューや議論のことを指します。
GitHubを使っているとよく出てきます。
LGTM
"Looks Good To Me”の略です。
コードの修正などを承認するときによく使います。
"Approved"を代わりに使う人もいる気がします。
IMO
In my opinionの略です。
自分なら直すけど、直すかどうかは、
おまかせしますという
緩やかな指摘をしたい時に使います。
Nit
Nitpick (重箱をつつく)の略で、
些細なコメントという意味。
修正するか、しないかは作者に委ねるという意味ですが、
前述のIMOより、より一層コメント感が強い気がします。
TL;DR.
"Too Long. Didn't Read.”の略語で、
長いので、(読まなかった)要約を載せますという意味です。
長い説明を書く前に、TL;DR.と書いて、結論を箇条書きにするPRをよく見ます。
参考資料
チーム開発実践入門──共同作業を円滑に行うツール・メソッド WEB+DB PRESS plus
MyEnigma Supporters
もしこの記事が参考になり、
ブログをサポートしたいと思われた方は、
こちらからよろしくお願いします。
