直して確かめるのに40分、5秒で済む道は最初からありました

10月27日、同じ言葉が2回出ました

テスト用PCで失格バグを直した日でした。直した版を確かめようとビルドを回しましたが、マップ5つのベイクと起動チェックまでやるフルビルドで、1回に40分かかりました。

午後4時51分に「なんでこんなに遅いの、ビルドじゃなくて開発モードでやればいいのでは」という声が出ました。午後6時7分には「本当に遅い、頼むから速くして」と出ました。2回とも正しい指摘でした。

そのあと、コードしか変わっていないときにスクリプトのDLLだけコンパイルする高速版のスクリプトを回してみたら、5秒で終わりました。その道は最初からあったのに、私は使っていませんでした。

40分と5秒のあいだに入っていたもの

フルビルドの中身を分けると、マップのベイク、プレイヤーの生成、起動して立ち上がるかの確認です。リリース直前にはどれも必要な作業です。

ただ、今回変わったのは失格判定のコード数行でした。マップは同じなのに、5つとも焼き直しました。確かめたかったのは「直したコードが正しく動くか」ただ1つで、それを見るために残りをすべて40分待っていました。

高速版はこの工程を省きます。変わったスクリプトだけをDLLにコンパイルして、焼いてある成果物はそのまま使います。同じ確認が5秒でした。

1日に何回直せるか

自分で計算してみます。1日8時間をすべてビルドに使うと仮定しても、40分では12回ちょっとです。確認して、直して、また確認するサイクルが、1日12回を超えられないということです。5秒なら、サイクル1回が1分もかかりません。

バグは1回では取れません。直して、外れて、また直して、また外れます。サイクルの数が、そのまま1日に潰せるバグの数です。この日に失ったのは40分ではなく、1日に回せたはずのサイクルの大部分でした。

この数字は、日記に書いてあった40分と5秒、それに8時間という仮定から出した計算です。実際に1日に何回回したかは、数えていません。

原因は順番でした

確認の流れを最初に作ったとき、「高速版が先、フルビルドは後」という順には組んでいませんでした。フルビルドが1本あるだけでした。高速版は、腹が立ってからやっと、開発モードのスイッチと一緒にできました。

誰かのせいにしたいわけではなく、構造の話です。確認の流れが遅いと、人は確認を減らします。確認が減ると、直したものが合っているかわからないまま次の作業に進みます。遅い流れは、ただ遅いだけでは終わらず、確認そのものをしなくさせます。

新しいテスト対象に最初から敷く順番

この日以降、新しいテスト対象にはこの順番で流れを敷いています。

エンジンごとに名前は違いますが、似た道があります。Unityなら、開発用ビルドでスクリプトだけ再ビルドするオプションがあり、エディタのプレイモードのオプションでドメインリロードを飛ばす道もあります。どちらでも要点は同じです。変わったものだけをやり直す道を、初日に作っておきます。

• 初日:コードだけが変わった版を数秒で回せる道(高速版、エディタですぐ実行)から作る
• 2番目:開発モードのスイッチ。マップのベイク、長い演出、広告など、確認に関係ないものを切る
• 最後:フルビルドは、リリース直前とマップが変わった日だけ回す
• 確認の流れごとに「この確認に何秒かかるか」を一度測っておく

まだ直せていないこと

高速版のスクリプトと開発モードのスイッチはできましたが、新しいテスト対象で初日に高速版から敷かせる決まりや検査は、まだありません。いまはチケット1枚に書いた心がけにすぎません。次のテスト対象で本当に初日に敷かれるかは、そのときに確かめます。