レビューに限らず、スキルとかも大事だけど、「プロセス」の改善で、かなりよくできるところがあると思います。
最近、「コードレビュー」について結構真剣に悩んだり学んだりしているところなので、英語の記事から知恵を借りる事が多いです。
日本語でそういう情報があれば～と思ったので、まずは、自分で読んだ記事を紹介＆素人的に訳していくことにしました。＾＾
今日の記事は、こちらです：
すぐに使えそうな「コツ」のリストが載っていて、これなら現場ですぐ取り入れられそう！と思って、読んでいる時ワクワクしました。
リストの項目は12個。少なすぎず、多すぎず、いい感じがします。
さて、一個ずつについて書いていきます。
「レビュー前にコードにコメントを残してほしい」と、先に開発者と期待すり合わせをしておく。
「レビューするけど、PRにどこが大事とかコメントし欲しい」と、レビューを頼んでから言われる事がだれだってあると思うけど、自分のいる現場では、それが「どこを重点的に読めばいいか知りたい」という視点のお願いが多い気がします。
ここで重要なのは、「コード仕上げたら、レビュー出す前に一回目を通して、作成者としてのコメントを残す」という作業の時に、一部の問題が見つかることがあり、レビューで発覚するよりも先に修正ができる、というところだと思います。
これは確かに、いいですね！
チームのレビューコストが削減もできそうで、コードの質も上げられそうですね。
レビューのゴールを図れる値で事前にきめる。
レビュー参加者の責任感を強くするため、と書いてありますね。
ここでちょっと気をつける必要があるなと思いました。レビューを評価に使わないほうがいいと、レビューに関する書籍の多くに書かれていますよね。レビューアが責任を果たしているかどうかは、重要なところですが、評価制度や評価対象にする場合、そのままレビューのゴール達成度とかを使ってしまうと、レビュー自体がしづらい現場になる危険性がありますね。
ちなみに、ここでは具体的にどのようなメトリクスがいいかの例などはないけど、透明性があることが重要で、「バグ発見率」のような指標はよくないとだけ書いてあります。
プロセス改善ができるように、指標や結果の数字を計算してくる仕組みを使う。
なんだか、この記事の冒頭に紹介されていた「Collaborator」というツールを進められている気がしないでもないですが、単純に手書きとか、アナログで指標を追いかけると、継続的にやっていくのがしんどくなってやめてしまったり、手入力を忘れたりやめたりするので、いいやり方ではない、というのはたしかにそうです。
レビュープロセスを明確な数値化した指標で効果測定ができると、レビューの導入後、マネージャークラスの人たちに「導入してよかった」といえたりするのも、いいと思います。
ゆっくりレビューできるための時間をしっかり計画する。そして、60－90分以上かかるレビューを実施しない。
これは、割りと多くの書籍にもありますが、インスペクションでも、コードを読む時も、一回を60分ぐらいにするのはベストで、長くても90分を超えて連続でレビューすると問題や不具合の発見率が一気に下がるそうです。
一回で200行のコードまで！
これは、書く側も気をつけないと、ですね。まあ、200行も超えるメソッドは、書きたくもないし流石に読むのもつらいですよね。ちゃんと200行ずつに分けて読めるコードなら、それなりにスイスイ読めそうな気がします。
あ、記事によると、200行ずつ読むと、不具合の発見率が5倍も上がるそうです。これは、今度やってみよう。
レビューの間、20分休憩。
ここを読んで、こまめに休憩！と言われた気がしました。
一時間で300－500行のコード程度を読むとベストらしいです。そのぐらい読んだ後、20分の休憩を挟むといいみたいです。
まあ、そうかもしれませんね。新鮮な頭で読めそう、ですが、実際に仕事中にこんなにこまめに休憩していたら、いつ終わるのだろうと、ちょっと思いました。
この辺を職場で導入するには、少し工夫が必要そうですね。
不具合がちゃんと修正されたかも、確認する。
これは、インスペクションの基本ですが、かなり忘れがち。問題を発見して、作成者がきっと直すでしょうという暗黙の了解は、罠ですね。
レビューされているコードを直したら、指摘をくれた人に声をかける工夫も、対面でレビュー会をしている場合は修正の確認を誰がやるかを決めましょう。
コードレビューをチームビルディングの道具として使う。
目的は「リリース前に不具合を見つける」ことであることを忘れず、見つけること自体はいいことだという姿勢と考え方をチームに根付かせるのは、そのチームの責任者の役目だと書いてあります。
ここでは重要なのは、「レビュー」を新しい事を学ぶ場、よりよいテクニックをチームと共有する場、不具合を未然に潰す場、として扱うところです。
慣れればレビューで指摘されても「コードがよくなるしバグをリリースしないで済むから見つけてくれて嬉しい！」という気持ちになれますが、最初はやはり「自分ごと化」しがちなので、特に若手のコードの場合、レビューアもそのあたりが伝わるようにコメントする事を心がけるといいかもしれませんね。
助手席運転手になるな。
ここで「Back seat coder」という表現が使われていますが、これは元々「back seat driver」という言葉から来ています。後部座席下助手席から運転手にあれこれと運転について文句を言う人をいみします。
チーム全体で同じ苦労をしているし、作成者の立場になったらだれも他の人と同じようにミスも不具合も発見されるはずなので、人を批判ばかりしないで、という事を言いたい気がします。
人の失敗をみてああだこうだいうぐらいなら、手伝いなさい、と私は思います。
毎日少しだけでもいいから、欠かさずレビューする。
全行ではなくてもいい、未完成のままでもいいから、毎日欠かさずレビューをすることで、コミットするメンバーの意識が高まり、コミットされていくコードの質が徐々に良くなっていく、そうです。
コードレビューの効率をあげるにはコードレビュー用のツールを使う。
今いる会社のチームでレビューを導入した時は、コードへのコメントなどをエディターとかで「何行のここが～」とか書いていました。今思うと、大変な苦労していたな～と思います。
無料のものも多いし、GitHubを使っている現場なら、そのままGitHub上でレビューがいい感じにできるので、おすすめです。
作成者やレビューアの成果を継続的に上げていくためにチェックリストを使う。
このチェックリストのような簡単にまとまっているものを使うことで、忘れがちだが重要なものを忘れにくくし、習慣化しやすくなるそうです。
確かに、そのとおりですね。ただ、長すぎると、読むのも一苦労になりそうなので、チームの特性に合わせたものをメンバー全員で仕上げて作ると、コミット感も強くなり効果がより出てくる気がします。
以上、記事にあった「12のヒント」をかなり主観的に訳したものです。
おさらい：レビューをもっとうまくやるための「12のヒント」
1. 「レビュー前にコードにコメントを残してほしい」と、先に開発者と期待すり合わせをしておく。
2. レビューのゴールを図れる値で事前にきめる。
3. プロセス改善ができるように、指標や結果の数字を計算してくる仕組みを使う。
4. ゆっくりレビューできるための時間をしっかり計画する。そして、60－90分以上かかるレビューを実施しない。
5. 一回で200行のコードまで！
6. レビューの間、20分休憩。
7. 不具合がちゃんと修正されたかも、確認する。
8. コードレビューをチームビルディングの道具として使う。
9. 助手席運転手になるな。
10. 毎日少しだけでもいいから、欠かさずレビューする。
11. コードレビューの効率をあげるにはコードレビュー用のツールを使う。
12. 作成者やレビューアの成果を継続的に上げていくためにチェックリストを使う。
これらを、どうやって自分のいる現場に取り入れていくかを考えると楽しくてまちきれないけど、メンバーと相談しつつ、巻き込みつつとやっていくのが大事なので、まずは内容の共有と感想だけでも今度聞こうかなと思っています。＾＾ｖ