_ 社内のコードレビュー勉強会でLTしてきた。

社内でコードレビューについてディスカッションする勉強会があり、そこで自分たちの考える・実践しているコードレビューについて語るLT枠があったので、一発やってきた。個人活動という体面でのプレゼンなので、スタイルとかフォントとかやりたい放題やって、スカッとした。内容的にも、この1年半くらいでのチームでのコードレビューのスタイルについての背景を説明したつもり。

どんな話したのか？

今日の自分からの主張は、「レビューは、development hell を生み出す悪の存在」ということ。development hellとは、

進捗が無いまま開発の状態でとどまっている状態

レビューは開発プロセスの間に入り、レビュワーvsレビュイーという対立構造を生み出し、あまり価値が見えていない状態での差し戻しを生み出すが、リリースの間にdevelopment hellを生み出しかねないし、実際に起こる。プロダクトに価値を生みださず、時間を浪費するという意味で、死んでいます。

レビューの目的をチーム内での合意形成とするならば、しかしながら、レビューの中でも、コードレビューは価値のあるレビュー活動で、レビュー作業として、ここに注力すれば良いと思います。なぜなら、

1. 仕様策定、設計時点での情報量に比べて、実際にプロダクトのコードを目の前にして気づくことが多いため
2. 仕様策定や設計は多人数でできるが、コードを書けるのはキーボードを目の前にしている一人のみ

であるためです。

どんなに仕様策定や設計を頑張っても、それらはコードに落とし込めなければ全く無意味です。実際にそれが可能などうかはコードを書く段階にして判明します。また、設計や仕様については、一人でしか行えない作業ではないのに対して、コードを同時に複数の人が書くことはできません。ですので、チーム内での合意形成は、コードレビューで行なうことが重要になると思います。

とはいえ、要件・仕様を決める、またそこからコードに落としこむ設計自体の重要性は高いのは変わりません。そこで、レビューをするのではなく、チーム全員でそれを行なうことで代替します。それにより、メンバー各自の情報を1箇所に集め、コードレビュー時の認識の齟齬による差し戻しを無くすことができます。

で、今の自分のチームではスクラムを取り入れていて、バックログリファインメントでそこをカバー*1しています。

終わって

普段の自分がやっている社内勉強会は「スピーカーが1名、あとは聴衆」という講義スタイルなのだけど、集まった人達でディスカッションするような形式も割りと盛り上がって良かった。 講義スタイルで聞いたことを開発の現場にまで持って帰る、そのあとの振り返りのような形でこういうスタイルの勉強会が役に立つのだろう。 @TAKAKING22 、ありがとう！

ということで、自分でも次のトライを考えておこうっと。