Scrum ではコードレビューをどうやっているか？
森崎先生のソフトウェアレビューの講演を聴いて、今やっているレビューの方法をまとめときたいと思ったので、まとめてみます。今回は、コードレビューの話です。Scrum ではといっていますが、レビューのやり方はチームによって違うので、あくまでも例ですよ。PBI とか、仕様、ドメインモデルのレビューの話はまたこんど。
レビューの目的は、もちろん作成するプロダクトの品質向上です。障害を検出するのも、もちろん目的ではあるのですが、それ以降のスプリントで作成されるコードで同じ障害を作り込まないのが目的としては大きいです。そのため、レビューはプロジェクトもしくはチーム立ち上げ後、数スプリントで重点的にやります。後はスプリントの振り返りでレビューをやりたいが出てきたら、チームで決めます。
- レビューのやり方
基本はチーム全員で集まってやります。最大２時間。それ以上やっても集中力が続かないので。プロジェクタで対象のコードを映しながらやります。PO も来てもらうといいですね。
対象のソースコードは、とくに実装上に不安があるところをチームメンバーの自己申告で。場合によっては、メトリクスを取得して McCabe 循環複雑度が大きいところをやったりします。
＃はじめにテストを実行して赤くならないこと確認してから始めます。
レビューは、コードを書く元になった PBI を確認してから、読み手がそのコードを説明します。とくにどういう意図でそのようなコードになったのかを説明してもらいます。
メンバーは説明を聞きながらコードを追ってコメントします。重要なのはコードから、説明された意図が読み取れるかですね。説明を聞きながらスムースにコードを追えるかどうか。コードをうまく追えないときは、なんか変なことになっていますね。あと、障害とか改善が必要であるというコメント以外に、うまく書けている、このあたりの実装が格好いいとか、ポジティブなコメントもします。
ディスカッションの上、バグであるとか、改善の必要があることがわかったら、ソースコードにコメントとして書き込みます。
バグの場合
// FIXME: CR日付 コメント
改善が必要な場合
// TODO: CR日付 コメント
レビューが終了したら、テストを実行してコードを壊してないことを確認してから、リポジトリにコミットしておきます。書きませんでしたが、次回レビューをやるときには、前回のレビューコメントがどうなっているかを確認します。
- レビューで気をつけていること
森崎先生の講演でも強調されていましたけれど、レビューは書いた人を責めるためではなく、障害を後工程に残さないこと、そして設計を改善するためにやります。だから、コメントがあくまでもコードに対するもので、人に対してでないことは十分注意する必要があります。ScrumMaster の出番。
ちょっとやっていて面白いと思われるプラクティスは、初めてのバグ、障害を出した人はほめられる、というところですね。「うわ、このバグ超絶技巧！」とかね。テストで検出するのが難しいバグが早めに見つかるのは、後の仕事が楽になる良い兆候ですから。超絶バグが出てきたら、同様のバグがないか、PBI 単位でのレビューが終わってから確認します。
以前のレビューで指摘されたのと同じバグを出すと、「ダサい」という評価が待っています。３回目だと、朝会の遅刻と同じくらいのペナルティですね。おやつ基金か飲み会基金に罰金なことが多いです。３回目という評価をもらうと、だいたい次のふりかえりで、４回目をやらないような Try を設定してみます。コーディングルールにして壁に貼ったりもします。
チームでのレビューなので、レビューアとレビューイの役割は固定していません。一回のレビューセッションの中で、レビューアとレビューイが何回も入れ替わります。以前、コードを書かない立場で参加してたら、次のスプリントで実装タスクをもらったことがあります :)
- まとめ
レビューを全員集まってやると、その間の実装は止まりますし、みんな疲れるので、結構コストはかかっています。ただ、よい設計感覚を共有するとか、コード全体をみんなが理解できるようになるとか、コードのスタイルがそろってくるとか、いろいろなメリットがあります。
スキルが低いので厳格なコーディングルールを適用しようとか、ネーミングルールを統一しようとかやるより、プロジェクトの早い時期にしょっちゅうレビューをやるのが有効だと思っています。
以上、ちょっとでもご参考になれば。ツッコミ、コメントをお待ちしております。
Coderetreat ファシリテーターガイド
Coderetreat へようこそ
Coderetreat は、一日中集中して練習するイベントです。ソフトウェア開発と設計の基礎に重点を置いています。開発者を仕事を片付けなければならないというプレッシャーから開放して、集中して練習する機会を提供することで、非常にスキルの向上に有効なことが示されています。モジュール設計、オブジェクト指向設計の基本原則を練習することで、将来にわたって変更コストを小さくするコードを書くスキルを改善できます。
Coderetreatにはファシリテーターが必ず必要です。ファシリテーターの責務は、一日の概要を説明すること(私の解説ビデオを参考にしてください)、セッション中にペアをガイドすること、セッション間の振り返りと、終わりの会をリードすること。このページでは、一日の概要スケジュールと、効果的なファシリテーションのコツを説明します。ブログにも coderetreat のファシリテーションについて書いたのでご参考に。
構造
Coderetreat は、長時間テストされた確立されたフォーマットで、練習に集中するために最適化されていいます。
問題: コンウェイのライフゲーム
セッションの長さ: 45分
開催時間: 午前８時３０分から午後５時か６時まで
ペアプログラミングは必須。ペアプログラミングにおける知識の伝搬が練習には必要であるから。
テスト駆動開発(TDD)を推奨
セッションが終わる毎に、ペアは組み替える
セッションが終わる毎に、作成したソースコードを削除する。ブランチに入れたり、バックアップしたりせずに、後を濁さずきれいに削除する
一日のすごし方
coderetreat は、５ないし６セッションで構成されます。おのおののセッションでは、以前のセッションで得た知見を生かしてコードの作成を行います。午前のセッションは、問題ドメインの理解すること、既存の慣習の打破すること、自身による発見をめざすことに、集中します。午後のセッションでは、ちょっと背伸びをして、抽象化、モジュール化設計、テスト駆動開発のスキルと知識の獲得を目指しましょう。
ほとんどのグループは、ソフトウエア開発に置ける基本、モジュールか設計、シンプルなデザインの４つのルールに集中すべきです。一日を、それらのコンセプトの練習に費やしましょう。
一日のラフなスケジュール
8 - 8.45am : 到着、コーヒや朝食など
8.45 - 9am : 趣旨説明、概要説明、問題ドメインの説明
9 - 9.45am : セッション #1
9.45 - 10am : ふりかえり、休憩
10 - 10.45am : セッション #2
10.45 - 11am : ふりかえり、休憩
11 - 11.45am : セッション #3
11.45 - 12pm : ふりかえり、休憩
12 - 1.30pm : 昼食、ディスカッション
1.30 - 2.15pm : セッション #4
2.15 - 2.30pm : ふりかえり、休憩
2.30 - 3.15pm : セッション #5
3.15 - 3.30pm : ふりかえり、休憩
3.30 - 4.15pm : セッション #6
4.15 - 4.30pm : ふりかえり、休憩
4.30 - 5pm : 最後のふりかえり
セッション毎のトピックの例
経験を積んで、ペアの観察に慣れてきたらファシリテーターは、この例に限らずいろいろなこと試せるようになるでしょう。最初の数回は、以下の例をガイドとしてください。
Sessions 1
ペアは、問題ドメインの感覚をつかむ。コンウェイのライフゲームを全員が知っている訳ではないので、このセッションはまずは問題を理解するために使わせてよい。最初のセッションの後に、コードを削除するというアイデアについてディスカッションしてもよい。抵抗する人もいるだろうが、ルールであることをやさしく説明すること。
Session 2
問題を表す適切なデータ構造についてディスカッションしよう。セルを保持するのに、配列を使うのが正しいだろうか？primitive obsession のアイデアについて説明する。
Session 3
チームに、ちょっと背伸びをするよう促してもよい。ブーリアンのフラグより、ポリモルフィリズムを使った方がいいかどうかについて議論しよう。primitive obsession を避けるようさらに促すこと。抽象化についても重点を置いて探求する。
Lunch / 昼食
昼食時間は十分にとること。参加者は、自己紹介して、午前中に経験についてディスカッションできる機会とする。
Session 4, 5, 6
午後のセッションでは、チームに自ら制約を課してコードを書くことを伝える。
以下に制約の例を示す。どの制約を課すかは、個々のチームの経験による
- if 文を使わない
- ループを使わない
- メソッドを小さくする(５行以下、１行？)
- 言語のプリミティブを使わない
- 本来の意味での TDD
さいごに
最後に全員集合してふりかえりを行うのが重要です。普通の方法は、全員集合して全員に３つの質問を尋ねる方法です。グループの人数にもよりますが、時間を区切る必要があるかもしれません。20-30人もいると、結構時間がかかりますよ。
３つの質問
- 今日、何か学んだことは？
- 今日、何かびっくりしたことは？
- 明日以降、何か今までとやり方を変えることは？
どんな言語でも
coderetreatで提示し、練習するアイデアは、どんなオブジェクト指向言語でも適用可能です。つきつめると、coderetreatは、複数言語でやるべきという意見もあります。coderetreatは新しい言語を学ぶための日ではありませんが、参加者が慣れていない言語で coderetreat をやってみるのは全く問題ありません。ただ、ペアの片方が開発環境が準備しておく必要があることは、ファシリテーターは強調しておかなければなりません。４５分はとても短いので、開発環境をセットアップしているとあっという間に時間がなくなってしまいます。
