僕のatcoderの学び方(〜緑)

6/25に書いたもの:

緑になった時点で読み返してツイートしよう

→7/5に緑になったので整理加筆してツイートした

まずはコンテストに参加する

どうやって解いたかを他人に説明するつもりで書く

解説を書いてる最中に「あれ？Aだと思い込んでたけどそうとも限らないのでは？」とか「ぐちゃぐちゃ試して最終的にこの書き方でACしたけど、振り返って考えるとコードのこの部分は必要ないのでは？」とか考えることで理解が進む

公式の解説PDFを見る

自分が解けた問題にも、もっとよいアプローチがあったかもしれない

自分が一度解いた後でそれを見ることで「なるほど！」となる

教科書を読むのに比べて「自分ごと」感が強くて脳に染み込みやすい

解けなかった問題の方針を知る

これで「なるほど！」となったら改めて問題を解く

強い人のコードを見る

特に「あれー、アルゴリズムはおかしくないはずなのにTLEするなー」というとき

「その問題のPythonでACのコード」を検索して速度でソートして速い方から見る

短いコードを検索することも1回あった

「もっと簡潔な書き方ができるはずだ」と思って。

でもゴルフ的に可読性を捨ててるコードがヒットしたので読むのが大変だからそれ以降やってない

最初は著者を意識してないのだけど、繰り返しているうちに「何度か目にした人」に気づく

情報単体ではなく、背後にいる「それを生み出した人」が認識されると、そこから情報源が広がることがある

例えばPythonの速いコードランキングにはしばしばmaspyさんがいる

この経験によって「maspyさんのブログに書いてないか見てみよう」という学習行動が生まれる

他人の書いたコードがパッと見でわからないとき

ローカルに保存してvscodeの変数名変更機能で分かりやすい名前に付け替えながら読んでいく

他人のコードを参考にして実装する

見て写すのではなく見ないで書く

1: 読んで理解して「なるほどそうやるのねー」ってなってから、それを見ないで自分で書く

2: 書けなかったらすぐ見る

という小さいサイクルを高速回転してる

例えば書いてるときに「あれ？この添え字は-1する必要があるかな？ないかな？自分の考えだと必要だな」と考えて書いて、その後でお手本を見て「お、確かに-1してるな」と確認する。他人のコードが「いいぞいいぞ！正しい方向に向かってるぞ！」と声をかけてくれるイメージ。短期間で報酬が与えられるのでモチベーションを保ちやすい。

この時、変数名やコードを将来読む自分のために整える

他人の書いた変数名ではなく、自分にとってわかりやすい変数名を使う

わかりやすい書き方に変える

例えば三項演算子で書かれてるのを見て自分が「わかりにくいな」と思ったら、自分がわかりやすいようにif文で書いたりする

省略されてるelse節を補って「この条件の時は〜だから何もしなくてよい」と書き足したりする

未来の自分が「あっ、この問題、前にといたアレじゃない？」って思って読み返した時、読みやすいコードの方がよい

読み返す時が来るかどうかはわからないが、この書き換え作業をすること自体が理解を深める助けになる

7/6

上の記事を書いてから別のことに気づいた

同じ問題文を見てても実装し始めるプログラムが人によって異なる

問題文に書いてあることをそのとおりに実装するのが一番素朴な形なのだけど、これはしばしばTLEする

この問題を見て、僕は無意識に変形してた

素朴な解き方をしてる人を見て「なるほど、自分は無意識に変形してた」と気づいた

この無意識の変形が何によって起きているのか気になった

そこで変形の過程で使われてるテクニックに名前をつけてScrapbox上のタグにしていくことを試し始めた

AしてからBしても、BしてからAしても同じ

ならばどちらが先であるか区別する必要がない

これはここしばらく試していることなのでまだどういう効果があるかうまく説明できないが、有益な感じがしている

7/11

atcoder problemsでおすすめ難易度の問題を見れることがわかったのでそれを眺める

easyは確かにeasy、moderateが「気づけば簡単だけど気づけなくて難しく感じる」ぐらいかな、これを解くと良さそう