DBリファクタリング読書会 第三回に参加しました

DBリファクタリング読書会は、前から気になっていた勉強会で、今回たまたまタイミングがあったので参加して来ました。

今回は3章の「データベース・リファクタリングのプロセス」でした。

まずは、ビールとピザで腹ごしらえをしてから講演、全員が参加してのディスカッションという流れで読書会は進んでいきました。懇親会が本番みたいな勉強会が多いので最初から懇親会というコンセプトは話も弾んで良かったと思います。

読書会中のツイートはこちらでまとめられています。また、全体的な流れはgarage-kidさんがブログにまとめているのでそちらを参照されると良いかと思います。ここでは読書会の本編とも言える座談会の内容について個人的に気になったテーマをピックアップして紹介します。

実際のプロジェクトでDBリファクタリングを実践したことがある人？

15人位中 3人

やはり、DBの修正はできれば避けたいというのが一般的ということなのでしょうか。そんな中、DBリファクタリングを実際のプロジェクトに適用したt-wadaさんの経験談が非常に勉強になりました。railsのプロジェクトでは開発プロセスの一部として当たり前のようにDBリファクタリングをしているそうです。ただし、シングルアプリケーションに限ります。

マルチアプリケーションのデータベースリファクタリングについてもディスカッションがありましたが、シングルアプリケーションの場合と比べて単純ではない、でも出来なくはないという印象でした。

マイグレーションを適用した後にロールバックすることは何処まで実現できるか？

個人的に凄く気になっていたので質問してみました。

• そもそもプロダクション環境でロールバックが必要にならないよう、その前段階で十分に検証を重ねることが前提。
• 逆変換が書ければロールバックは基本的にはできる。逆変換がないマイグレーションがpull requestされてもリジェクトする。
• データを統合するようなマイグレーションの逆変換を書くことは不可能なのでそういう状態にならないように設計段階で注意をする。

というお話を聞けました。 さらにマイグレーションに関して、

• マイグレーションは細かいステップで作ったほうがレビューをしやすい。
• ただし、プロダクション環境に適用する前に見直して重複した更新を省いたり、更新したけど結局戻したみたいなマイグレーションを整理して軽くする。
• マイグレーションの適用時間 = システムの停止時間となる場合が多い。

という話も聞けました。

DBリファクタリング適用の移行期間を設ける必要があるのはどういう状況か？

• マルチアプリケーションの場合に必要となるケースが多い。
• DBを利用するすべてのアプリがすぐに対応できるわけではないので対応待ち期間を作る。
• そもそもどのアプリが使っているのかがわからないケースがあるので、移行期間を設けて問題が起こらないことを確認するという場合も。
• データ参照しかされないのであれば、Viewが使えることが多い。
• 先にスキーマ変更してから移行期間に古いスキーマをViewで見せるか、新しいスキーマをViewとして見せて、移行期間後にスキーマを更新するかはケースバイケース。どっちでも良い。

ステージング環境は何処まで本番と同じ環境が作れるものなの？

• それクラウドなら(ry
• データに関しては極力本番に近いデータが望ましい。

まとめ

講演、座談会のどちらも内容が非常に濃くて大変勉強になりました。 読書会の運営スタッフの皆さん、会場を提供してくださったOracleの皆さんありがとうございました。

次回は4章の「稼働環境へのデプロイ」についてです。最近、継続的デリバリー という本を読んでいて非常に気になるテーマなのでタイミングがあえばまた参加してみたいです。

CoderetreatでTDDに挑戦してきた

Coderetreat in Drecom powered by AgileSibuyaに参加してきました。

イベントの詳細については、HIROCASTERさんがここに詳しく書かれているの詳しくはそちらでどうぞ。

このエントリーでは１ヶ月前まではCoderetreatという言葉すら聞いたことなかった私がどんなことを考えながら参加していたのかをつらつらと書き綴ってみようと思います。今後、Coderetreatに興味を持った方がイベントの雰囲気をつかむ手助けになればと思います。

イベントへの参加目的

目的というほどのものではないのですが、Coderetreatへの参加を決めてから漠然と

• テスト駆動開発を実践してみたい
• 新しい言語に挑戦してみたい（RubyかJavascript、できればHaskellとか）

ということを考えていました。特に新しい言語という部分に関してですが、自分で環境構築などをするとどんなものがいいかなど結構調べるのに時間がかかるので既に構築している人とペアプロすることで自分の環境を作る時の足がかりにできたらいいなと思っていました。

各セッションで考えたこと

4/28に実際にイベントに参加して来たわけですが、各セッションでは自分なりにテーマをもって楽しむことができました。

Session1. PHP

ペアでコーディングを進めていくにあたって、どうやって意思疎通の方法を探っている間に終了してしまいました。 今振り返ると、ドライバーとナビゲーターを交代するタイミングが曖昧だったのは良くなかったなと思いました。

Session2. PHP

テスト担当と実装担当にわけて進めていきました。テスト担当者がテストを追加したらドライバーとナビゲーターをスイッチして実装担当者がテストを成功させるところまでコーディングするという流れです。

私はテスト担当だったのですが、テストデータの作り方が悪かったせいでセッション後半でテストが簡潔に記述できなくなっていきテストデータを整理するのにかなり時間を使ってしまいました。fixtureの管理は重要ですね。

Session3. PHP

このセッションでも基本的にテスト担当と実装担当にわけて進めていきました。前回のセッションで得られた教訓をいかしてテストデータも簡潔に記述でき、結果として結構順調に進めることが出来たのではないかと思います。

このセッションではテストが実装の方向性を作っていくという流れが作れたのが非常に良かったと思います。

Session4. Javascript

このタイミングで実装言語を変えてみたいと思い、Javascriptの開発環境を準備されていた方とペアを組ませてもらいました。私はJavascriptでの開発経験がとぼしかったので、テストの書き方等の基本的なことを教わりながら進めていきました。にもかかわらず前のセッションよりもさらに実装が進みました。

Session5. C#

前のセッションで違う言語でやっても案外いけると調子にのって火傷を負ったのがこのセッションでした。例によってテストを担当していったのですが、しょっぱなでデータ構造の選択をミスったため最後の段階でコーディングが複雑になりました。データ構造の選択は重要ですね。

また私の準備不足が原因で、ペアの方を待たせてしまったのが申し訳なかったです。

Session6. 不参加

HPが0に近づいた人達(?)で集まって、エクストリームフィッシュボウルをやりました。Rubyをかける人がほとんどいないのに何故かRubyを選択し、残念な結果となりましたがそれはそれで学ぶことが多かったと思います。それと最後にRSpecのモダンな書き方を実演してもらえたのが凄い勉強になりました。

まとめ

• ペアプロは怖くない、むしろ楽しい。けど、ずっとはしんどい。
• テストファーストによって実装は導かれるという経験ができて良かった。
• あわよくば、関数型言語で導いてくれる人と出会えるといいなと思ってたけど出会えなかったのが残念だった。（同日に開催されていた名古屋の会場ではF#が猛威を奮っていたようですが・・・。）

余談

PHPのリファクタリングツールが貧弱なことに絶望して、今年に入ってからPHP用のリファクタリングツールをVimスクリプトでコツコツと作成しています。まだ機能は少ないですが順次機能追加していくので良かったら使ってみてください。