コードレビューのクオリティとスピード，とくにスピードについて，それとコミュニケーションについて

ソフトウェアを作るときにクオリティとスピードのバランスをとりたくて，どちらかに偏ってはいけなく，どちらもキープしないといけない．すごく雑に*1とらえると，

• クオリティ→正しく動き，不具合がないほうがよい
• スピード→(計算時間ではなく)早く作れるほうがよい

ということになる．

コードレビューでは，不具合を見つけて直してもらったり，動きはしてもコードの可読性に問題があって直してもらったりと，クオリティに目を向けられがちだと思う．

ところで，コードレビューとスピードの関わりについて考えてみる．スピードのためにできることはいくつかあり，

• 早く読み始める→他のことやってても手を止めて読み始めたり，1日のうち決まった時間にレビュータイムを設けたり
• 速く読む→これはコツとかある*2けど精読しないといけないので難しい
• 不具合を見逃さない→リリース後とか，リリース直前に正しく動かないことが分かったら大きな手戻りになり，そのpull requestは早く出せてもその後ロスタイムになる
• 早く収束させる→何度もコードの改修を含むやりとりをしていては時間がかかるので，少なく正確な回数のやりとりでマージできるよう努める

とくに最後に書いた，やりとりの回数のことが言いたかった．修正箇所を指摘して，直してもらったあとに，再度修正箇所を指摘するとしたら，実装者のミスというよりかは，実装者とレビュワーのチームプレイのミスで，コミュニケーションに失敗しているのではないか．
GitHubのコメント欄でのやりとりだと，送信コストが低いので，「直してみました，こんな感じですか?」「そんな感じよりは，むしろ…」みたいに低コストなコミュニケーションが始まってしまい，いつまでも話が続いたり，コードをこねくり回してはや数日が経ってしまったりする．
完成版の完璧なイメージができて，そのイメージにお互い合意をとれてから修正を始めるべきで，そのためにはコメントで書きつつも，議論を収束するためには口頭で話したりしたほうがよさそう．
うまくいけば，コードを書き始めてから完成までに見てもらうのは初回と修正後の2回までに抑えられるはず．

大きなコードのレビューを1回の修正で収束させるのは難しい．小さいpull requestを少しずつ送ると，一度で収束するサイクルを導入しやすくなる．
個人的には，大きめの物を作るときにも，1日1個ずつくらいの粒度でpull requestを送って，その日のうちに収束させてマージして少しずつ出していくようにしている．昼にレビュータイムがあるので，それに合わせるために午前中にコードを仕上げてレビュー依頼して，午後に見てもらって，ちょっと直したりして，夕方までにリリースして，リリースが終わったら次の昼までのpull requestを準備する．最速のスプリントが1日で回っているようなイメージ．
いきなり動かないUIが本番環境にリリースされては困るので，順番は工夫してうまくやるのだけど，それは別の話なので今度紹介したい．

チームでの協調を意識したコミュニケーションについてはこの本が参考になると思う．チームといっても，開発チーム，とか，会社，みたいな明示的な大きなものから，実装者とレビュワー，みたいな，その場で組み立てられて役目を終えたら即座に解散するようなものまである．

チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ

*1:厳密にはISO/IEC 9126とか見るとよい

*2:以前書きました：コードレビュー - hitode909の日記