RoRのmigrationで思ったこと
最近、それなりに本格的なシステムをRailsで開発しているのだけど、ActiveRecord::Migrationに衝撃を受けた。これはすごい。
昔話
20年ほど前、ソフトウェア開発の生産性が目に見えて向上した時期がある。ここで話しているのはビジネスソフトウェアのことね。
自分が入社した87年は、こんな感じで開発する文化がまだ残っていた。おそらく最後の頃だと思うけど。
- ロジックの設計をするSEがいる
- それをもとにコードを「紙に手書きする」プログラマがいる。専用の用紙があったのだ。
- その紙を元にコードを入力するコーダ→コードは80桁のカードに入力
- プログラマはカードの束をカードリーダに突っ込む
- バッチ処理でコンパイルされて、結果がリストに出力される
- コンパイルが通らない場合はプログラマが原因を突き止めて、修正したコード入力をコーダに依頼する
- 以下繰り返し[*1]
要するにプログラマはコーダへの作業指示をしていたわけだ。
この構図が激変したのは、TSS端末(とそれを接続するネットワーク)の価格が下落したことにより、プログラマ一人一人にコーディング環境が提供されるようになったあたりからだ。コンパイルして記述ミスを見つける作業が、それまでの数時間単位[*2]から10分単位に縮小された。外注していたコーダーは不要になった。ものすごい生産性の向上だった。
RailsのMigration
時は流れて20年。今どき、コードや作業指示を手書きやワープロで用意して他人に頼むことなんて...あるらしいのですなこれが。データベース周りだ。
Refactoring Databases: Evolutionary Database Design (Addison-Wesley Signature Series (Fowler))
- 作者: Scott W. Ambler,Pramodkumar J. Sadalage
- 出版社/メーカー: Addison-Wesley Professional
- 発売日: 2006/03/13
- メディア: ハードカバー
- クリック: 3回
- この商品を含むブログ (15件) を見る
データというのはコードと同様、「価値」を持ったものだから大事に扱わないといかん。コーディングみたいにコンパイルしてだめだったからやりなおす、などという考えではいかんのだよ。だからデータベースは専門担当にやらせるべきだ、という考えはデータベース誕生の頃からあったらしい。
北米では[*3]「プログラマはデータベースの構成にタッチすることは許されない」、というのがビジネスアプリケーション開発現場での伝統だった。日本でもこれは似たようなものでしょ? [*4]
でも、RailsのMigrationみたいなことが普通に受け入れられると、DBAの仕事というのはデータベースの初期導入とチューニングだけになる。開発者はテーブルの定義や変更の都度、DBAに依頼書を書いて作業終了を待つ、ということから解放される。
もう一つある。紹介したRefactoring Databasesにも書かれているけれど、DBAの人はテーブル構成の変更を極度に嫌うのが常らしい。なので開発者は事前に充分にテーブル構成を検討しておく必要がある。これだけで設計フェーズのかなりの工数を食うはずだ。でも、RailsのMigrationみたいなことが普通になれば、この先行設計の負荷からも解放される。
なーんてことを考えたのだけど、体制図固めることが仕事のおじさん達はRailsなんかに興味持たないのがそもそもの問題なのね...