先日つぶやいたりニュースフィードったりした発言で、何カ所か質問がきたので、その辺の解説を。
https://twitter.com/gallu/status/311293551487094784
[開発のDB周りの話]そういえば「テストデータは原則として作らない」「trancate祭り」とか、知っている人は知っているんだけど、意外と知られていないことも多いような。…こんどどこかで書こうかしらん？
一言で片付けると、うちの愛弟子の発言で終了してしまうのですが。
テストデータ作らないのは、開発者にとって都合のいいデータになりがちだからかな？ truncate祭り行うのは、create table文などの管理が継続して行われているかのチェックにもなるから かな？
もうちょいと、かみ砕いて(砕かないと、Blogにする意味が果てしなく薄くなるからｗ)。
ありがちなパターン…直近で似たのがあったので、それを例にとって(若干、事実と異なる部分があります。実際にはミスをさせない流れにしたのですが、会話の流れ上「ミスった」方向に嘘をつきます)。
ゲーム作ってまして。
キャラクタの初期登録があるのですが、まだいろいろとできあがっていないので「一端テストデータ」でキャラクタデータを作成して、それ以降のプログラムを続けていきました。
作成も一段落しまして。
いざ「αテストで、社内の開発外の人たちに遊んでもらおう」としたら、開発中には出てこないバグの連続 orz
上述、実際には食い止めたのですが。似たようなケースで「実際にこけた」状況は、山盛りで見てるんですね。
で、思うんですが。
「マスターデータ」で、それが「エンジニアによるSQL直接発行なSE作業」であればよいのですが、そうでない場合「とりあえず登録部分未作成だからSQLで一端テストデータを作成してぶち込んで」は、そこそこいい確率で「後々トラブルを生む」んですね。
まさに「開発者にとって都合のいいデータになりがちだから」。
根本的に間違ってるのは「とりあえず登録部分未作成だから」の部分。
開発順番がおかしい。
開発のタスクを分解したら、次にやるのは、上述のような「無駄な足止め」が発生しないように、タスクの順番を適切に整理する。
そうすると「とりあえず登録部分未作成だからSQLで一端(自分にとって都合のよい)テストデータを作成して」っていう作業が減ります。SQL作るのに無駄で、その後もう一度テストする必要がある二度手間で、ダブルの無駄が防げます。
なので。「テストデータを作らなきゃいけない」ような開発の流れからは、とっととおさらばしたほうが、いろいろと心地よいです。
これとあわせて。
「新規作成時」に極端に有効なのが、おいちゃん通称「trancate祭り」。
trancate祭りは、以下の手順で行われます。
・やる日付を宣言する
・当日。以下の手順でDBを整理する
->drop database;
->create database;
->create table 各種
->「きちんと管理されている」マスタ系insert文の発行
おいちゃん的に(鬼畜)ポイント。「あえて」drop database前のバックアップをとらない*1。
これをやる目的は、これもやっぱりコメントの通りで「create table文などの管理が継続して行われているかのチェックにもなるから」。あと、プログラム作成中に「おかしなデータがDBに混入すること」が、特に開発初期では多いので。その手の「ゴミデータ」で「間違って動かなかったり」「間違って動いたり」って系統の誤謬を一通り抹殺する意味も含めて。
印象的には、週１〜２週に１回くらいの頻度でやると、いろいろときれいになります。所用時間は、トラブルのヘッジも込みで、だいたい半日未満、くらい。
手法としては比較的荒っぽいですが、効果は結構がっつりとありますので。
興味がある方は、是非お試しくださいませませ。
*1:実際のところは。１回目２回目の祭りの時はとっておいたほうがよい場合も多いです、が、でもそれ以降はとらない方がいいと思う B-p
