レビューについて
コードレビューについて
目的
- 実装にかかる時間を減らすこと。
- 品質を高めること。
前提
- 基本的にコーディングにかかる時間は一定。
- 方法を決めるのに時間がかかる。
- 不確定要素によって方法を決める時間が変動する。
狙い
前提によると以下のように言える。
- 不確定要素は少なければ少ないほど良い。
- 方法を決める時間が少ないほど実装時間が短くなる。
ただし、後者については以下のようにも言える
- 正しい方法を採用しないと、品質が低下する。
- 品質が低下するとプロダクト内の不確定要素が増加する。
ここにはジレンマがある。
方法を決める時間を0にするには例えば何らかのロジックを実装しようとしていてそれについてメソッドに抽出を行なったりクラスの設計を行なったりすることをしなければ良い。
ただし、それをすると品質が低下し、未来の不確定要素が増えることになる。総合的にみて、良い方法であるとは言えない。
下記のような状態を目指す必要がある。
- 正しい設計を行い品質を高めつつそれにかける時間を減らす。
- 不確定要素を減らす。
これらを実現するためにレビューを活用したい。
期待する効果
- 自分では気がつかなかった課題に気づく（不確定要素を減らす）。
- メンバーの知恵を借りて、正しい設計に辿り着くまでの時間を減らす。
注意点
レビューはお墨付きをもらうためのものではない。
なので効果の裏返しで、以下のような点が注意点としてあげられる。
- レビューによって不確定要素がなくなるとは限らない。減らすだけ。
- レビューによって正しい答えが得られるとは限らない。確率を高めるだけ。
これらの注意点を考慮に入れると、レビューの回数は多いほど良いということになる。
タイミング
レビューは定期的に行うのが良いと思われる。
自分の認識できていない課題を早期発見するという目的を考慮すると、順調に思われる時にもレビューが必要であるからである。
また、レビューは先延ばしにされる傾向がある。前述のようにレビューの回数は多いほど良い。 他のメンバーの時間を使うのにその準備が整っていないと感じられるからである。 また、順調に進んでいるように思われるときは必要のないものと思われるし、順調でない時にはそれを隠したいという心理も働くかもしれない。
なのでレビューのタイミングは予めスケジュールに組み込んでおくと良いと思われる。
一方で、中途半端な状態でレビューを行うと、本来の効果が期待できず、チームメンバーの時間を浪費ことになりかねない。
スケジュールまでにレビューしてもらえる状態に持っていくための努力が必要になるが短期の締め切り効果を狙えるかもしれない。
形式
実装は外枠から行うというルールを守る。
枠組みを決めるまでその中身の詳細について考えるべきではない。 このルールを守る意味でもレビュー時の実装は回を追うごとに詳細化されるようにする。
またこのようにすることでレビューごとの実装の抽象度のレベルが一定になるためコンテキストも一定になり議論の生産性も向上すると思われる。
あらかじめ行う実装を階層化しておき階層ごとにレビューの日を設けて、それを締め切りとみなして開発していくという方法を試してみたい。
