タイトル通りの記事です。

9月からAtCoderを始めて、先日のAGC41で水色になりました。
一旦この辺でこれまでやってきたことをまとめておこうかと思ったので記事にしてます。皆さんの参考になるかはわかりません。

#書いてる人について

中学受験を経験しているのと、旧帝大理系の大学院(化学専攻)を卒業している。そのためそれらに入学するだけの数学的素養は持ち合わせている。大学ではかなり遊んでいたので大学数学の記憶はない。
業務はIT系だが、インフラ寄りのためプログラミングをする事はほとんど無い。
Javaは1年ほど前に2ヶ月くらい触った。大昔にC++を少しだけ触ったこともある。というわけでプログラミングについて全くの素人ではない。
AtCoder始める前に知ってたことの例
- if, for, while
- 配列
- 標準入出力
- VSCode
AtCoder始めるまで知らなかったことの例
- pythonの文法
- 計算量の概念
- 再帰関数
- DFS・BFS

ABCのB問題くらいならさほど迷わず解けるが、競技プログラミングやアルゴリズムに関する知識はほぼ0、という状態からのスタート。
AtCoderはどちらかというと趣味として始めた。

#やったこと
**ひたすらAtcoder Problemsで丁度よさそうな難易度の問題を解く。**これだけ。
↓これは現時点でのABCの埋め状況。

まぁ4か月で330問やってるのだから短期間で詰め込んだ方だとは思うが、330問やって水色と考えればまぁ相応じゃない？という感想。最近はコンテスト埋めを多少やっているため、実際身になった問題でいえばもっと少ないが。

分からないことや知らないメソッドがあれば、場当たり的にググる。AtCoderの解説にはキーワードとなるアルゴリズムやメソッドが載っているので、「(キーワード) python」などで実装例を探しつつ、自分でも実装してみる。
作ったものは使いまわせそうならライブラリ化しておく。現状こんな感じ。

ちなみに　mathpyやscipyはまだ使ってない。
まだ全然使わなくても出来る。将来的には使えるようになるつもりだが。

低すぎる難易度を埋めるのは、モチベーション維持の面では良いかもしれないが、上達においては無駄(無意味とまでは言わない)だと思っている。A問題を4分で解ける人がスピードを倍にしても2分しか稼げないが、D問題に40分かかっているならそれを10%速くするだけで4分も稼げるわけだから、難しめの問題に取り組んだ方が上達につながりやすいと考えている。あと経験上、300点を10問解いても400点が解けるようにはならない。400点を解けるようになるなら400点に10問挑戦するしかない。
**自分の実力の1.1倍くらいの挑戦をし続けるのが成長においてベストというのはあらゆる分野で検証され尽くした真理である。**AtCoderにおいては「自分が1時間前後で解けるかどうかくらいの問題」に取り組むのがベストであるというのが今のところの結論。
問題は原則「完全に理解する」まで考える。解説を見て「あーハイハイなるほどね」と思ってもそこで終わってはいけない。ちゃんと自分の手で実装するまでやる。受験勉強もそうだったが、**問題数だけ積んで思考停止で手を動かして、それで解けるようになった気になるのが一番危ない。**一問一問を自分の血肉とするつもりでやる。ただ、解説を見て尚「まだ自分には早いな」と思うものも時々はあるので、そういうのは無理をしない。
他の人のpythonで提出した回答を見る。高度すぎてあまり参考にならないことも多いが、自分の知らなかったものに出会えることも多い。
いちおう蟻本は買っていて、半分くらいまでは読んだ。何となく停滞感を感じたときに読むようにしている。網羅的に書かれた本を読むのは大事。もちろん読むだけでコードが書けるようにはならない。

#pythonのメリット・デメリット

アルゴリズム力は言語には依存しない
実装力は言語選択ではなく言語の経験量に依存する
どの言語にも一長一短ある
1言語目より2言語目以降の方が学習コストは圧倒的に低い

というのは大前提として、そのうえで実際にpythonを使って感じたメリデメを挙げていく。

####○可読性が比較的高い
パッと見て何をやってるか分かりやすい……気がする。
これは自分が使うことのメリットというよりは、他人のコードを見たときのメリットと言える。正直、自分が書く分には少々書き方がくどかろうがカッコが多かろうが関係ない気がしている。現代でメジャーな言語はどれが本質的に優れてるとか劣ってるとか言えないレベルではあるだろうし（そうでなければ淘汰されているから）。
一方で、他人のコードを読むときは短くてすっきり書けるpythonは有利だなと思う事が多い。まぁこれも主観ですけど。

####○実装済のメソッドが多い
「これあるかな？」と思ったやつは大体ある。二分探索とか優先度付きキューとか順列列挙とか。そしてググれば基本的に出てくる。
最短経路メソッド各種もあるにはある(が、自前で実装しておいたものを持っておいた方が色々細かい改修ができてよい)。

####△メソッドの勉強が必要
当然だが知らないものは使えない。そのメソッドを使う問題にぶち当たるまでは知る機会がない。まぁ勉強すれば済むことではある。

####△メソッドごとの計算量に対する知識が必要
どの言語でもある程度共通することではあると思うが、同じ実装内容でも使用するメソッドによって速度が全く変わる。特にテキスト操作まわりは差がより激しい印象。
ただ、差が激しいというのはメソッドが豊富であることの裏返しだとは思う。細かなメソッドをいちいち自前で実装しなくて良いのは大きなメリットと言える。

####×pypyとpythonの選択が必要
基本的にはpypyを使えばいいのだが、再帰関数だけはpythonの方が速い。
コンテスト中で慌てていると選択を忘れてTLEする事もある(一敗)。

####？実行速度が速くはない
ただ、これまでのpython競プロ人生で「TLEが残ってるけど、もう削れる余地がない」となった事はまだ一度もない。
ここでも書かれているが、黄とか橙になるようなレベルでなければまず問題にならないと思う。言語変更する暇がない程の短期間で黄色になれるという自信があるならpythonはやめるべきだと思うが、そんな人が果たして世の中に何人いるだろうか……
あと、「定数倍改善は本質的ではない」という意見も個人的には少々疑問で、実際に書いたコードで勝負する以上、その言語の特徴を押さえて制限時間内に収まるように書き方を工夫するのは当然の事なのでは？と思っている。たとえロジックが正しくても、実行速度が遅いのであれば不正解となるべきだとむしろ自分は思っている。

#AtCoderをやってて思うこと

####シンプルに楽しい
自分は昔から受験勉強で大量の問題を解いてきたため、問題を解く事に対する報酬系が完成してしまっている。ジャッジを待ち、ACの表示が出たときの脳汁はやはりAtCoderを続ける大きなモチベーションである。

####コードの品質はあまり上がらない
特にコンテストの限られた時間内では、ほぼ同じ処理を何度もコピペで書いたり、必要以上に場合分けを増やしたりしがちである。きれいなコードを書くスキルは、それ自体を意識しないとあまりつかないように思う。

####実務にはあんまり活きない
もちろん業種によっては活きるのだろうが、自分の会社ではDB・フロントとのコネクションとか、フレームワークとかの方が大事なので、あまり実務に活きてる感じはしない。まぁそんなもんだと思っている。単純に趣味としてやってる感じ。

#今後の目標
まだまだ勉強しきれていない内容はいくらでもあるので、引き続きできる事を地道に増やしていって、それで行けるところまで行きたい。
青まではまぁ何とかなるんじゃない？という気がしている。

以上。
なんか思いついたことがあったら追記します。