Coding dojoガイドライン - hamamatsu-rb/hamamatsu-rb.github.com GitHub Wiki

Coding dojoとは

皆で１つの課題をプログラミングし、書いたコードをお互いにレビューします。 ペアプログラミング、TDD/BDD、コードレビューなどを体験できます。 （ http://www.atmarkit.co.jp/fcoding/rails/articles/passionate/03/passionate03a.html ）

  1. ランダムでペアを作る
  2. テストを書き、テストが通るようにコーディングする
  3. 2を繰り返して課題を完成させる
  4. 各ペア間でコードを見せ合い、レビューを行う。
  5. 次回のお題を決める
  • PCが持ち込めなかった人は持ってる人とペアになりましょう
  • プロジェクタに繋げるとコードレビューが楽です
  • 次のお題の持ち込みを歓迎します。できれば数十分でできるようなサイズが良いです。

お題

課題リストにストック中

ペアプログラミング

自由にルールを作り、カスタマイズしながら進めればよいのですが(ルールは明示化した方が良いです)、その基本となるルールがない場合の叩き台にどうぞ(suchi)

  • ドライバー: キーボードを打っている人
  • ナビゲーター: 横でレビューしている人

ペアプログラミング10箇条

古いメモからなので出典がわかりませんでした→オブラブ(旧オブジェクト倶楽部)でした。

  1. ドライバー、ナビゲーターは5-10分毎で適当に交代しよう。ドライバーは引き際が肝心。ナビゲーターの助言が多くなったら交代。
  2. やることを紙に項目として書き出そう。終わった項目を横線で消そう。
  3. コードより先にテストを書こう。テストをパスさせるための最もシンプルな実装をしよう。
  4. ナビゲーターは、ツッコミの要領で助言しよう。
    1. もっとシンプルな方法はないか
    2. コードは意図を表現しているか
    3. クラスやメソッド、変数の名前は意図を表しているか。
    4. タイプミスはないか。括弧の数は合っているか。
    5. テストは先に書いたか。
    6. 次のテストはどう書こうか。テストし忘れていることはないか。
    7. 全体から俯瞰してバランスはとれているか。ヘンな方向に突き進んでいないか。
    8. コーディング標準にあっているか。
  5. ナビゲーターは、じれったくなったら「わたしにやらせて！」と言おう。
  6. ナビゲーターは、理解できないコードを見たらドライバーに聞こう。「なんでそうなの？」
  7. ドライバーは、ナビゲーターの助言にいつでも耳を貸そう。そしてその助言に返事をしよう。
  8. ドライバーは、行き詰まったら助けを求めよう。このメソッド、ちょっとお願いできないかな？
  9. 腹が減ってはプログラミングはできぬ。一緒にお菓子を食べよう。
  10. 楽しくやろう。Enjoy Pair Programming!

TIPS

上に独自ルールを加えるとよいでしょう。たとえば「ナビゲータがコメント(とくに間違いの指摘)するときは5秒待ってから」(ドライバーが直そうとしているときに横から指摘されるとストレスになる(今やろうと思っていたのに))、「画面を指で触らない」(そういうメンバがいた)、「モニタに付箋を貼らない」(視線にモニタ以外の文字が入ることが気になるメンバがいた)などがあります。

エディタやキーバインドをカスタマイズしていると作業効率が落ちるので、事前にどちらのマシンを使うか、どのエディタを使うか、もしくはファイルを共有して個々のマシンを使う、など進め方を相談してから始めるのがお奨めです。

TDD(Test Driven Development)

テストを書く→エラーになる(赤)→コードを書く→テストが通る(緑)→リファクタリングする→テストが通る(緑)→新しい機能のためのテストを書く→エラーになる(赤)→コードを書く→テストが通る(緑)→ …… と、新しいコードの追加をテストから始める(駆動する)開発方法です。

@t_wada さんの「RSpecの入門とその一歩先へ」を写経してみるのが良いとおもいます。

Coding Dojoに来る前にやっておくこと

  • 環境

    • ruby(1.9推奨)を使えるようにしておく
    • rspecが使えるようにしておく
    • gitが使えるようにしておく
    • githubのhamamatsu.rbに参加する(@suchi or @mackato or @Cherenkov にユーザ名を連絡してください)
    • githubのcoding dojoを取得したりブランチしておく
    • work/test.txtを適当に変更してpushやpullリクエストを送る練習をしておいてください。

  • 知っているとスムーズに進めること

    • gitの基本

      • git init

      • git clone

      • git branch

      • git checkout

      • git add

      • git commit

      • git log

      • git push

      • git pull

      • git remote

    • 簡単なrspecの使い方

RSpecのマッチャ－一覧

綺麗にまとまっていたので載せておきます。[「RSpecの標準matchers(マッチャー)一覧」] (http://morizyun.github.io/blog/rspec-builtin-matcher-rails/)