ハーフマラソンの立ち回り

はじめに

主に自分がハーフマラソンでやっていることを書きます．あんまり技術的なことは書きません． 技術的なことは色んな人が書いてるし，説明できるほど自分はちゃんと理解していません．どちらかというと事故を避けるための立ち回りを中心に書きます．

ハーフマラソン

競技プログラミングの一種にマラソンというものがあります．出された問題のスコアを期間内にできるだけ上げていくものです，期間はだいたい1〜2週間です．ハーフマラソンはそのマラソンをもっと短期間でやるものです．具体的には4時間(日本橋ハーフマラソン)や8時間(HTTF)などです．

各時間でやること

開始

最初はゆっくり問題文を読みます．問題を勘違いすると致命的なので10〜15分ぐらいかけて問題を噛み砕いて方針を固めます．このときコードは書きません．ツイッターで誰かがマラソンは最初はコードを書かずに考察したほうがいいといっていたのを参考にしています．ただし4時間マラソンは結構時間ギリギリなので，方針固めと次のクラスづくりの工程を同時に行ったりします．

問題理解後

まずは問題内に出てくるオブジェクトのクラスを作ります．例えばHTTF2019の問題なら，討伐依頼とスキルと行動です．あとはスコア計算などの不変な計算．使う定数などを書いておきます． これら基礎となる部分は方針にかかわらず無駄にならないので．最初に作ると間違った方針を立てててもリカバリーしやすいです．

基礎作成後

まずは入力を受け取り．自明に得点を取れるコードを書きます．そういうのが難しい問題もありますが．とりあえず一番最初に思いついて実装が簡単なやつです．だいたい貪欲になります．他の人も同じようなことをやっているはずなので．これを提出すると順位表で得点が横並びになります．ならなかったら作った基礎などのバグを疑ったほうがいいです．このときのスコアは後の方針に対するベンチマークにもなります．

貪欲作成後

このあたりから問題によっていろいろ変わります．技術的な話も出てくるのでそのあたりは他の人に任せます． ここでは実装中に気をつけてることを書きます．

高速化は終盤までしない

高速化は大体コードの可読性が下がります．バグも埋め込みやすくなりますし，使い回しもしにくくなります．今の方針がだめだったり新しい方針を思いついたときに，高速化部分が無駄になったり，書き換えが煩雑になったりして余計バグを埋め込んでしまったりしてしまいます．本当に最後に特にやることもなくなったときにしています．

お知らせには気をつける

問題を作っているのも人間です．いくら気をつけててもミスをします．テスターだったりビジュアライザだったり問題文だったりがバグっていることがあります．おかしいと思ったら質問の欄をみたり公式のツイッターを見たりします(動き出しが遅いので，自分が気になったことはだいたい先に質問されてて質問をしたことはない)．Atcoderの新仕様なら全体公開の質問・解答がされた場合わかるようになってたと思います(質問タブの横に数字がでた気がする)．重要な修正があったりするので気をつけてます．

最後の最後は作法を無視する

これはまあ自然にそうなるんですが，残り10分で実装しようとしてるときとかは可読性とかプログラミングの作法とか全部無視して書きます．変数の使い回しとかグローバル変数かコピペとか．ギリギリになると読み返すこともまず無いし．バグらせたらその時点でほぼ詰みです．

おわりに

以上です．もしかしたら誰かの参考になるかなという気持ちもありますが，主に自分のハーフマラソンでの行動を整理するために書きました． もちろんその人に会う立ち回りというものがあるので，一つの参考として見てもらえればありがたいです．急ぐと頭が回らなくなる人には合ってると思います．(自分がそうです)