虎塚さんの記事
http://d.hatena.ne.jp/torazuka/20140512/doukaku
を受けて。
正確なテストデータ / データの数
深く考えずに、40個ぐらいにしていることが多いんだけど、
コーナーケースが多そうなら多めに、コーナーケースが少なそうなら少なめにしてる。
仕様を網羅したいという希望はありつつも、べつに網羅できなくてもいいよね、とも思っている。
正確なテストデータ / データの作成方法
だいたい以下の順序で
- 典型的なケース。問題文中に例として挙げます。
- 典型的な例外ケース。該当するものがなかったらとかそういうの。
- 典型的なケースをいくつか。
- コーナーケースを思いつく限り。
- 乱数
「乱数」と、さらっと書いたけど、一様乱数でうまくいくわけではない。
たとえば「ポーカーの残り＋」( http://nabetani.sakura.ne.jp/hena/ord10pokarest/ )。
この問題の場合は（あんまりおぼえてないけど）全部の手についてのデータをまあまあ均等に出している。
解き方が複数ある問題にする
この要件が大問題で、ここに注力するとすぐに難易度が上がってしまう。
で。
『「自分では思いつかないけれど、誰かが別の方法で解いてくれるかもしれない」などと勝手に期待』することは結構あって、解き方がひとつしか思いついていない場合でも、いやこれはこの経路以外にありそうだという感触があればそれでよしとする場合もある。
もちろん複数の経路を実装しておきたいとは思うんだけど。
特定のプログラミング言語に配慮する
だいたい ruby に対する嫌がらせをしたいんだけど、いくら考えても他の言語に対する嫌がらせにしかならない。
C と Java、特に C を優遇したいと考えていて、入力データを固定長にしたりしている。
視覚的な演出になる図表を入れる
どちらかというと、できれば図を入れたくないと思ってる。
図を書くコードを書くのが面倒なので。
図が入っているのは、図を入れないと仕様が明確にならないと思ったときだと思う。
過去に出した図で一番気に入ってるのはやっぱり
折って切る( http://nabetani.sakura.ne.jp/hena/ord17foldcut/ )のアニメーション。
問題としてもすごく気に入ってる。
未見の方は是非解くことをおすすめする。
それ以外
どれ以外だと
- 数学的になりすぎないようにする。
- 参加者を想像して問題を作る。
- コンピュータがなくても解ける問題の方が良い。
あたりのことを考えてるって、前にどっかに書いたような。
参加者を想像して問題を作る
これはあんまり具体的にどう問題を作るかという話ではなく。
文字通り、参加者を想像する。
☓☓さんはこの問題を見たらどういう表情をするだろうか。
◯◯さんはこの問題にどう取り組むだろうか。
とか、そういうこと。
CodeIQ と違って、問題を解く人々の集う場があるので（問題だけではなく）その場を面白くしたいと思ってる。
どうしたら面白くなるのか全然わからないんだけど、たぶん面白くするための手段として、想像しながら問題を作っている。
