カラムを追加するところから開発を始めました。個以下のメールアドレスを登録できるようにしてください、という問題でしたので、自然な発想です。この方針のまま進むと、メールアドレスの重複を防ぐためのバリデーションの実装が難しくなります。いま、顧客Aと顧客Bにそれぞれ2つのメールアドレスを設定すると仮定します。顧客Aのメールアドレスをma0、ma1、顧客Bのメールアドレスをmb0、mb1とします。このとき、ma0は、ma1、mb0、mb1のいずれとも異なっていなければなりません。email2)に格納すると、Rails標準のuniquenessバリデーションが使えなくなります。制約の仕組みも利用できません。テーブルを定義しました。カラムを除去するマイグレーションを作成しました。endendさて、今回はコミットが11回も行われていることから想像されるように、開発過程はやや複雑なものとなりました。時間的制約から全体を詳細に解説することができないので、特徴的な工夫を2点紹介します。モデルのソースコード。ブロックをご覧ください。制約違反を回避するための工夫です。制約のためにエラーになります。書き換えれば、この問題は発生しません。フォームから送られてきたデータにより書き換えられています。配列に対して二重のループ処理を行って、同一顧客の2つのメールアドレスを比較しています。書き換え後のメールアドレスが重複していることを表現しています。この場合は、バリデーションエラーです。ある書き換え後のメールアドレスが書き換え前の(すなわちデータベースに格納されている)メールアドレスと重複していることを表現しています。属性を「真」にセットします。よるテストコードです。この種の複雑なロジックを含むソフトウェアの開発を、テストコードなしで行うのは至難の業です。テスト駆動開発(TDD)が特に効果を発揮するのは、このようなケースです。