Cside::Quote

私は昔、趣味で作っていたアプリに機能を「追加」する度に、アプリケーション(実行ファイル)の総サイズを「減らす」、というのを繰り返していたよ。速度も同様に。
これによって「あるパターンはこう簡潔に直せる」というパターン知識が積み上がっていった気がするな。
さらに、それを実現する過程で、限界に見えた状況を打開するために色んな既存アルゴリズムを勉強して実際に使って身につけていくことになった。
ある問題があるときに、的確に適合するアルゴリズムや構成が発見(選択)できると、劇的に簡潔になることがある。そこにたどり着けるかどうか考えるのが楽しい。

あと、同じコードを何年も「育てる」という経験をすると、保守性の低いコードがどう困るかが身に染みるようになるよね。ソースコードは「人が読む物」でもあり、読みやすいというのも保守するなら重要なパラメータになる。これはコメントを書けという意味じゃない。コメントそれ自体は保守コストを「上げる(悪化させる)」。それでもなお必要な事だけを書く。読みやすくすべきはコードそれ自体。

あとは、「自動化」。何かコードを書くそれ自体以外の作業も、ツールを即興で作ったり組み合わせて解決する経験を積んでおくといいよ。