プログラミングが上達するのに、プログラミングする以外の方法はありません。

なるべくたくさんのプログラミング練習法を知っていて、その時の自分の気分に合ったプログラミング練習法を使いわけて、なるべく長い時間飽きずに、プログラミングを続ければ、スーパープログラマになれます。

練習法の名前は軽い気持ちでつけています。かっこいい名前があれば教えて下さい。

練習法カタログ

写経

初めて使うプログラミング言語やライブラリをチュートリアルやGetting Startedに従い、自分の手で打って動作を確かめます。

未知の道具の典型的な使い方を体験します。「デッサン」のようなものです。説明を読んでもチンプンカンプンなプログラミング言語やライブラリも、自分でプログラムを書いて動かしてみると、あっさりわかります。

初歩的なプログラムでも動くと楽しいものです。チュートリアルはその趣旨から、手軽な例が多く応用例が少なく、飽きやすい側面もあります。飽きたらやめましょう。

今は、動画での解説もたくさんあります。ターミナルやエディタの使い方も、動かしているところを見ながら学んでいけます。

写経は、書き写しながら「ここを変えたらどうなるだろう」と、脱線していく過程に学びがあります。脱線が苦手な人には向かないようです。

CodeKata

プログラミングの練習問題を解きます。

典型的なプログラムの実装方法と用法を体験します。「なぞなぞ」のようなものです。問題が解けた瞬間が嬉しいです。

頭を使って疲れる割に、応用に近づいているのかわかりにくいです。作成したプログラムがうまく動いているか判定するため、プログラムの入出力を文字列やファイルに制限していることが多いです。 Webアプリケーションやジェネラティブアートのような、見た目の華やかさがありません。算数の問題を解いるときに感じる「これ何の役に立つんだっけ？」という気分にもなります。

この名前は CodeKata に敬意を払ったものです。現代では、プログラミングコンテストの練習問題などがこれに当たると思います。

RTA（リアルタイムアタック）

なるべく短い時間でプログラムします。

誰かと競い合うのは楽しいものです。「かけっこ」のようなものです。要求から実装までの速度の早さは、要求の正しさを検証するときの武器になります。

現代では、競技プログラミング、プログラミングコンテストのような成果を公に誇れるような競技があります。開始時間が決まっていることがあり、生活リズムと合う合わないなどの問題はあります。

競技だけを繰り返しても、速度が上がらないパラドックスもあります。苦手部分を繰り返し練習するなど、本番とは別に練習を工夫する必要はあります。

ソラプログラミング

似たようなプログラムを何度か書いたら、今度はリファレンスやサンプルコードを見ずに書いてみます。

お手本を見ずにプログラミングできる自信が付きます。今後、同じことをするときは、調べ直す時間が要らなくなり、コーディング速度が早くなります。

レビューのとき、その場でサンプルコードを書いたり、APIの使い方を説明するときにライブコーディングしたりできるようになります。応用の効きやすい練習です。

調べることで、新しい手法やAPIを知ることもあります。常に調べないほうが良いわけではありません。

治具

自分が使うための道具をプログラミングします。

ユーザーが自分なので用途を明確にできます。レアケースを考慮しないシンプルな機能を、プログラミングできます。不特定多数の人が使うためのプログラムは、汎用的に書くため手間がかかります。

シンプルなプログラミングを早く実装すると効果がすぐに出ます。これはソフトウェアの本質的な力強さです。素早く変えることでいろいろな仕事に対応できる、ハードではないソフトな力です。どの程度の繰り返し作業には、どの程度のプログラムを書けば効率がよくなるかわかります。どのような場面でどのようなプログラムが効果を発揮するか知ることができます。

普段、Webアプリケーションを書いているプログラマが、大量のファイルにを処理するプログラムを書いたりするなど、いつもとは違う入出力を使う事が多いです。ソフトウェアの普段知っているのとは違う側面が知れます。普段と違うプログラミングするのは勉強になります。

使い捨てのプログラムは役に立ちますが、汎用性が低く、他人に自慢しても「僕の役には立たなさそう」と思われ、反応が得にくい、自慢しにくいのが玉に瑕です。

車輪の再発明

普段使っているライブラリやフレームワークを自分で実装してみます。

自分で実装すると、魔法としか思えなかったものが、現実的な技術に見えてきます。魔法だと思っていると、何でも解決できると誤解しがちです。ライブラリやフレームワークの制約や制限が見えてきます。

似た用途のライブラリやフレームワークを比較するときに、内部の実装がイメージできると、他人の声に惑わされずに、細部を評価できるようになります。すべてのものを一つのフレームワークで解決する必要がなくなります。

自分の抱えている問題とうまくマッチする、ライブラリやフレームワークが見つからなければ「ならば作ってしまえ」と思えます。

マズローの言う「ハンマーを持つ人にはすべてが釘に見える」病気に効きます。

パーサープログラミング

パーサーのように一定量を実装するまで価値が出ないプログラムを作ります。

量が価値を生む体験をします。治具でピンポイントで効果的なプログラミングを体験したのと対象的に、実装量が価値を生むプログラミングをします。量を作り込むコストを評価できるようになります。

価値が出るまで時間がかかりしんどいです。実装中「作りきっても価値が出ないのではないか」という不安にさいなまれます。

プログラムオーナー

あるプログラムの発案から設計、実装、ユーザーへのデリバリー、サポートまで自分でやります。

プログラミングに関する、プログラミング以外の部分を一通り体験します。ソフトウェアと世界の境界を自分が超えることで、現実世界で使いやすいプログラムの届け方、要望の変化に対応しやすい設計方法を習得します。

自分の書いたプログラムが人の役に立つ楽しさがある反面、サポートの煩わしさもあります。

おわり

ネタ切れです。皆さんが普段やっているプログラミング練習方法にも名前をつけてみてください。

@ledsun blog

無味の味は佳境に入らざればすなわち知れず

たのしいプログラミング練習法