とあるきっかけで競技プログラミング的なものにトライしてみて、TDDをせず痛い目を見たので書いてみる。
トライ1回目
テストコードを書くのをすっとばす
普段ならテスト駆動開発を行っているので、まずテストを書くのだが、 競技中は制限時間を強く意識してしまって即座に処理の構築に取り掛かってしまう。
コーディングの途中途中でのリファクタリングをすっとばす
ある処理が意図通りに動くようになったら、普段なら関数化したりわかりやすくしたりと手をいれるが、 競技中は制限時間を強く意識してしまって、次の処理に即座に取り掛かってしまう。
結果
非常に苦しい戦いになった。
制限時間が減っていく中、 処理を書いて実行してみて意図と異なる結果になったとき、 ただでさえ「え、なんで？？」と焦るのに、 関数化など綺麗に書いていないのでどこで何をしているのかパッとわからずさらに焦りだす。
なんとか原因がわかっても処理が綺麗にわけられていないので、モンキーパッチ的な修正をしてしまう。
これにより、さらにコード内容の把握が難しくなっていく。
「もう一歩で完成、もう一歩で完成、、」を何度か繰り返してストレスMAXなコードが出来上がって、なんとか完了。
トライ2回目
しっかりとテストを書き、リファクタを行うようにした。
制限時間があろうがいつも通りの手順で作業する。
結果
余裕をもってクリアできた。
書いた処理が意図と異なる結果になっていても、 対応するテストの条件を変えてみてエラーになる条件を特定し、 その処理の流れをデバッグする。 処理も小さく分割されているのですぐに原因が判明し、それほど焦る状況に陥らなかった。
まとめ
これって普段の開発で起こる事が超短いスパンで起こっているのだと感じた。
普段の開発でも、適宜リファクタやテストを書いて進めて行かないと後半になって開発速度が鈍化する。
それは、1時間~2時間のこんなに短い期間のなかにでも起こる現象なのだと思った。
「すぐ出来そう」「早く次を作りたい」という気持ちに引っ張られて、コードを解りやすくする作業を怠ると、すぐに開発が破たんするのを体験できた。
（おまけ）標準入力からのデータの受け取り方に慣れておく
地味に手間取った。 ロジックが出来て「あとは関数に入力値を入れればいいだけ」という状態になったが、 あまり標準入力からデータを受け取る事に慣れていなかったので その辺の処理を書くのにまごついた。
あらかじめ慣れておいた方が良いと思った。
