案件ふりかえり
とある案件が終わった。相変わらずきっつい納期だったうえに、全メンバー片手間の情況でよくやれたなと自画自賛していいと思う。
ふりかえりをツイートしたら清水川大明神先生様に「それブログで」って言われたので、すこし整理してみた。
テスト
テストを書く習慣が付いたのはつい数ヶ月前のことなのだが、この案件ではテストが非常に役立った。
もともとFlashゲームのバックエンドAPIサーバーを作る仕事だったのでサーバー側のテストがしやすいというのもあったが、初期からテストのしやすさを意識して書いた。
マイルストーン期日が押していても1機能に対して最低ひとつ、想定通りの値で想定通りの結果が返ることを確認するテストを書いた。
それだけでも下らないバグは十分に防げた。
目標設定
テストの数が50を越えた頃から、100テストを目標にしていた。
カバレッジとかは一切計算していないし、100という数字にも何の根拠もない。単純にわかりやすいのと、3桁に対する憧れみたいなものがあったというだけ。
強いて言うなら「全くテストしてない機能」をゼロにするように心がけた。上でも書いたけど。
数が多くなってくるとただテストが走りきる様を見ているだけでも楽しくって、自然とテストを走らせる回数も増え、バグによる手戻りの回数はかなり少なく抑えられた。
ついでにテストを走らせるコマンドの名前を案件のキャッチコピーにして、パスを通してどこでも走らせられるようにしておいた。
中盤以降は殆ど儀式的にそのコマンドを打ち、テスト数が増えていることを確認してにやにやしながら、バグを潰してpushという流れができていた。
たのしみをつくる
楽しいというのは結構重要で、今回は楽しみの源泉であるテストを増やすために機能実装をしていた感すらある。
もちろん受託仕事の目的はモノを作って納品してそれがうまく動くことであってテスト100個ではないのだが、モチベーション維持にとても役立ったのは確かだし、結果的に品質も開発スピードも向上させることができた。
いくら仕事とはいえ面白くなさそうに作ってちゃ良い物ができるはずもない。
そういう意味で、個人的orチーム的な範囲で、楽しくやるためのエンターテインメント的要素をひとつぐらい設定してみるというのはありだと思った。
結果
結局、12000行ぐらいのロジックに対して160項目のテストを書くことができました。
すくないっちゃすくないかもしれないけど、進歩はしている。
次もこの調子でいきたいね。
5/50