Kentaro Kuribayashi's blog

Software Engineering, Management, Books, and Daily Journal.

ぶつかり稽古 2014年初場所 #cross2014

CROSS 2014で行われたコードレビューCROSS 〜ぶつかり稽古 2014初場所〜 | CROSS 2014というイベント(パネルディスカッション)でモデレータをつとめました。「#ぶつかり稽古」という事件についてで書いた、エンジニアによる「知的エンターテインメント」であるところの「ぶつかり稽古」の本格普及を図る第二弾のイベントです。

前回はペアプロでしたが、今回はセッションオーナの@studio3104さんのご意向により、コードレビューの実践、および、パネルディスカッションという形を採りました。1時間という時間では、なかなか深い議論をするのは難しいところだとは思いますが、各社での具体的なコードレビューのやりかたや考え方について、ある程度筋道のたった議論ができ、今後の参考にしていただけるような内容になったのではないでしょうか。@studio3104さんはじめ、親方とその弟子たち(パネラーのみなさま)、イベントスタッフのみなさま、ありがとうございました。

さて、今回はコードレビューについて、用意された課題に対して各組が実際に実装・レビューを行ったGitHubでのやりとりを素材として用いて議論しました。そのため、単に抽象的な議論に終わらない、真に迫った話ができたかと思います。話の軸としては、以下の通り。

  • コーディングの細部にとどまらない設計に関する議論をどのように行っているか
  • pull requestの内容が大き過ぎる問題にどう対処しているか
  • テストやパフォーマンスのような非機能要件に対するレビューをどのように行っているか
  • レビューにどのような教育的・チームの成長に関する効果を期待しているか
  • レビューする側される側のコミュニケーションはどうあるべきか
  • どういう理由でコードレビューが必要だと考えているのか

それぞれ、問題としてはどのようなチームも抱えていることでしょう。それらに対して、一般的にこうするべきだという答えはないでしょうので、今回のように、各社が実際どのように問題に対処しているかの事例を知り、自チームに適用できるところはしていくというのが、よいプラクティスとなるでしょう。上記のそれぞれについての内容は、以下を参照してください(他にも誰か書いてくれることを期待)。

1時間という枠をめいっぱい有効に使って議論を行えたとは思いますが、まだまだ話し足りないことがあります。たとえば以下。

  • コードレビューをするモチベーションとはなにか(自分の時間をそれなりに使ってレビューするのだから)
  • コードレビューを促進する工夫をしているか(レビュー負担が偏らないようにするとか)
  • コミュニケーションの方法を工夫しているか([MUST][SHOULD]とかのタグをつけてコメントするとか)
  • レビューで議論になった場合、どのようにしていい感じのところに落とすのか

このあたりについても、今後機会があれば議論をしてみたいところだと思います。また、「ぶつかり稽古」という「知的エンターテインメント」が今後どのように展開・発展していくのかについても、楽しみでなりません。なにか私で協力できることがありましたらお力添えいたしますので、どうぞご連絡ください。