AtCorderに挑んでみた

この記事は書きかけの記事です。一通り終えたら、清書し直す予定です。

プロコンをやってみたきっかけ

  • 特に無い。
  • 思いつき。
  • 自分がどれだけ書けるのは興味がある。

目的

やってみた後に考えてみた。

  • C++にもっと慣れたい。(プログラマー歴に対し、C++歴がとても浅い)
  • 数をこなしたい。

目標

  • 水色(上位10%)!

現状の実力(主観)

  • プログラミング歴:9年(大学1年から)
  • 言語
    • Java・・・3年:品質を意識して商用レベルが書ける
    • JavaScript・・・3年:品質を意識して商用レベルが書ける
    • Matlab・・・ 2年:書けはするが、あまり好きじゃない。
    • C++・・・1年半:最初はCの延長で適当に書いてたため適当。
    • C・・・9年:ロボコン用の汚いコードを量産。(コンパイラの成約でC99止まり)

元Web屋さんという背景から、ミドルウェアAPIOSSなどを扱う機会が多く、実は、各言語に向き合ってちゃんと勉強したことは少ない。製品化する過程でコーディングもするし、品質も意識したり、周りの人のコードのレビューも行っていたことから、コーディング自体に不安はあまり無い。

自分にとってプロコンの意味あるのか?

仕事でやるようなWebや組み込みシステムを作りコード(品質を考えたコード)とプロコンのコードは異なることは理解している。「プロコンが強い人材≠仕事で書くソフトの品質も高い人材」も理解している。(相関はあるとは思う)

広義のソフトウェアエンジニアとしての力量はコーディング能力だけでは測れない。アーキテクチャデザインパターン、運用など、ソフトウェアにおけるサプライチェーンまで含むすべてが対象になると考えている。

ただ、仕事で書くコードに「工夫の幅」を広げるために、プロコンで使われるようなスキルが役に立つのでは?という期待はある。

(初期戦略)進め方

AtCoder(主にAtCoder Beginner Contest(以降:ABC))の問題はA~Fまであり、後半になるにつれ難易度が上がる。初レート戦に挑む前に、試しに5回分ほど過去問を解き、以下に分類。

(1) 解ける(毎回安定する)
(2) 解ける(たまにミスる)
(3) 解けない(回答を見たら理解できる)
(4) 解けない(問題文が理解できない。回答を見ても理解できない)

当初。Aはほぼ安定(1)。Bはたまにミスる(2)。Cは回答できることもあるがほぼ(3)。D以降は解けない(4)という状況でした。

当面の進め方は、「過去問を解き(2)(3)の正答率を上げつつ、(4)については徐々(3)に近づけるよう勉強する。」とした。

(4)に該当しているのは、そもそもの手法を知らない、考え方がわからないため、手を付けられないものである。 これはレート戦でも最初は相手にせず、QIitaの解説記事を見ながら徐々に学習していくことを優先した。

環境準備

過去問を1,2回やる中で、競技プログラミングタイムアタックの性質上、ローカルの実行環境を整える必要性があると判断。普段遣いのPC(Ubuntu 20.04)で作業しやすいようにワークスペースを作成。以下のコマンドなどを用意。

  • テンプレートからcppファイルを出題数分(6個)生成するコマンド
  • ビルドコマンドの省略化するためのコマンド
  • IDE(clion)でビルドするために、CMakeLists.txtを整備
  • 解いたコードを退避し保管するコマンド

特にワークスペース作成コマンドは問題に取り掛かる初動がとても早くなったことから有用である。(たぶん、誰でもやってることなのかな?)
ワークスペースgithubで公開済み。
github.com

仕事でもココらへんは自主的にやってる(好きでやってる)


To Be Written....