Ruby on Rails Summer Festival 2008 に行ってきたまとめ

event Rails

昨日、Web Career さんが主催しているRails セミナーに行ってきました。
スピーカーは、RAWHIDE. のCTO 吉見 和也さん（あとで読むRailsのススメ - ヨシミ＠RAWHIDE. - builder by ZDNet Japan でblog 執筆中）でした。内容は、技術面というより、開発チームメンバー同士がどんな風に連携をとればいいのかとかそういう話。プロジェクトチームの連携が上手くいかないな〜と思っている人には大変参考になるかと思います。
以下、セミナー内容のまとめです。

以前の開発

RAWHIDE. 設立当初は、カウボーイコーディングと呼ばれる1人1人がアプリを作成するスタイルをとっていた。

  • 1人で作成するから基本は速い
  • ナレッジの共有ができてなかった
  • バグがそのアプリを開発した人でないと直せない
  • 動くこと最優先で、その場しのぎのツギハギコーディングをしていた。当然、後々壊れて行く


当初は、「アジャイルがいいんだ！」「アジャイルってのは、イテレーティブにリリースを繰り返すことだ！とにかく動く物を作ることなんだ！」と勘違いしてしまっていた。
現在は、アジャイルといのはやや抽象的なもので、アジャイル開発手法として紹介されている様なプラクティスを実践することで少しずつ身につけられるものだと考えている。
現在も、プラクティスを自分たちで考えながらTry and Error で試している。

現在実行しているプラクティス

1. 朝礼に始まり終礼に終わる

朝礼以外に、19時に終礼をやっている。ここでは、その日にやったことと、その作業を通して発見された問題点を報告。
次の日の朝礼で報告すればいいと思っていると案外忘れてしまっていたりする。また、19時に必ずやるので、仕事は終わりという意識が持てる。このおかげで、なんとなく深夜まで働いてしまったりすることが減ったという。

1.5. ランチミーティング（紹介されていたけど、スライド上で2になってなかったので1.5）

週一回（だったかな）ランチミーティング、というか、ただメンバーと一緒に昼飯を食べる。特に、開発の話をするという決まりがあるわけではない。

2. 開発規約

Rails にある、「設定より規約」に併せて、「設計より規約」というのも念頭においている。
開発者によって様々な設計をするけど、開発環境や設計上で一定の規約を守ってもらっている。

  • Rails は2.0.2
  • セッション管理はmemcached
  • web サーバはApache2.2
  • app サーバはmongrel
  • win で開発する場合はcolinux
  • ActiveRecord のfilter は使わない
  • ポリモフィックアソシエーションは使わない
  • 無印のrescue は使わない
  • save!メソッドは使わない（save を使う)
  • ソース内にコメントは書かない
  • 上記に反する際には、「何故規約に従わないか」をきちんとコメントで示す


ちなみに、テストサーバではPassenger を使っている。テストサーバ上で10以上のテストアプリが立ち上がるので、その度にmongrel プロセスが増えるのは困る。Passennger はその問題を解決してくれるので、テストサーバ用にあってる

3. テスト駆動開発
  • Test::Unit でなくRSpec 使ってる
  • RSpec 楽しい。テストが書きたくなるツールだと思う。autotest とか、Growl での通知とか便利

Rspec いいよ！なんだかんだ言ってないでとにかく入れてみるといいよ！


テスト駆動開発を行うにあたってやったこと

そんなことやってたら、自然とテスト駆動開発できるようになってた。

4. コードレビュー
  • ソースはSVN 管理してコミットするとメンバーにメールが飛ぶようにしてる
  • レビュー専門の人はいない。誰かがやる

基本的に、コミットした人が、レビューを直接頼みに行く。で、頼まれた人がレビューを行う。頼まれた人は、２日以内くらい（?）にレビューを行う。
レビューの際には、そのソースを書いた人に、動きを解説させる。書いた人自身でも動きが把握できてない場合があるので、それをあぶりだす


レビューは時間がかかるけど、それでも導入してみた。そしたら、レビュー段階でバグが沢山見つかることに驚いた。

  • ペアプロも導入したいと思っているが、なかなか上手くいってない
5. 振り返り
  • 毎週金曜日に振り返りを行う

今週について報告、来週やることを決める

  • 振り返りの報告軸はKPT（Keep Problem Try）
    • Keep: 今週こんなことやったら上手くいったよ！来週も続けて行きたいということ
    • Problem: 今週起こった問題点
    • Try: Problem に対する解決策として考えていること、やったこと
6. とことん自動化

例えば、以下のようなこと一発でやってくれるスクリプト（うろ覚えです・・・）

    • プロジェクト作成
    • deploy_project
      • テストーサーバでsvn co
      • httpd.conf 書き換え
      • DB作成、設定


他にも、backup とかを始め色々自動化してます。



以上、まとめでした。多少間違いがあるかも（汗）。実際の資料は、Web Career さんのページで近々公開されるとのことです。


講演をしてくださった吉見さん（はてなid があればコールしたいけど分からない）、セミナーを主催して下さったWeb Career さん、ありがとうございました！