僕がどうやってプログラミングを覚えたか（後編）

これは、プログラミングを覚えるための方法について、自分なりの知見をまとめる記事です。

前編では僕の道筋を示しながらプログラミングを覚える過程を雑に書いてみました。後編であるこの記事では、プログラミングを覚える・上達するための方法を掘り下げていきます。

・ まずはコードを書いて動く環境を作る
・ 初学者が最初にやるべきこと（写経 + 改造）
・ 題材探し
・ ブログを書く
・ インプット・アウトプット・実践のバランスを取る
・ 実験してみたいという好奇心
・ ユニットテスト
・ TDDという設計手法
・ 英語の読み書き

について書いています。

まずはコードを書いて動く環境を作ろう

コードを書いて動くようにするまでを、一番最初に整えるのは鉄則です。プログラミングとはコードを書いて動かしてその結果を見る、というサイクルをひたすら繰り返す行為だからです。サイクルはなるべく小さいモノを大量にまわすことが重要です。これはプログラミングの基本にして奥義です。

まずはVSCodeをインストールし、RubyでもPythonでもNode,jsでもいいから、実際にプログラムを動かす環境を整えましょう。

お気に入りのテキストエディタがあってVSCodeを使わないという人も、なるべくならそのこだわりを捨てましょう。VSCodeは現代において無料で入手できる最強のプログラミング環境であり、デファクトスタンダードです。

IntelliJなどのIDE製品を使っている方は、お好みでいいですが、今後もVSCodeは進化を続けて、他のIDE製品を引き離す可能性があることは忘れないでください。

あと、なるべく全自動で出来る方法を確立しましょう。手動の手順を減らすようにすると、どんどん楽になりますし、サイクルを回す速度があがりますし、それは上達にとってとても重要なことです。

初学者が最初にやるべき、写経と改造

それは写経と改造です。

まず、本やブログに書かれてあるサンプルコードを実際に打ち込んで、動かしてみましょう。これを写経といいます。

動かない場合はタイプミス（typo）があるかもしれませんし、サンプルが悪いという可能性もあります。

エラーメッセージを読むことはとても大切です。大抵は「何故エラーになったのか」を書いてくれています。

写経の効能として体に覚え込ませることがあるので、自分の手で打ち込むことが重要です。

ただし、打ち込むだけでは写経の効果のすべては発揮されません。重要なのは打ち込んだコードを理解することであり、それをする手っ取り早い手段として改造があります。

文字列を表示するなら文字列を書き換える。文字列以外のモノを指定するなど思いつく限り、色々やってみましょう。

可能な限り、もっともシンプルなところを探ってみましょう。サンプルでやっている事柄に不要なコードや設定はあるかもしれません。それらを実験すると、より本質的なことを理解しやすくなります。

題材探し

サンプルコードの写経と改造をやりだして物足りなくってきたら、題材探しを始めましょう。

今の時代はオープンソースが当たり前であり、GitHubには、世界中の様々なプログラムのソースコードが公開されています。

さて、題材ですが、もちろんあなたが興味をもてるものがいいです。

たとえばゲームが好きでゲームを作りたい人なら、ゲームのソースコードを探しましょう。最近のRPGツクールはJavaScriptを内蔵していますし、ソースコードを公開しているゲームも数多くあります。

もしかしたら誰かが「初学者にお勧めソースコードURL」の記事を書いてくれるかもしれません。

もちろん自分が好きなゲームやアプリから入るという手もあります。ソースコードが公開されていれば、まずはそれを手元で動かしましょう。動いたら、細かい何かをいじってみましょう。壊したら元に戻せばいいだけです。

ブログを書こう

ブログを書くというのはとても良い上達方法です。誰かに説明するというのは理解を深めるのに最適な行為だからです。まずはnoteにでも書いてみましょう。

「初学者なので間違いがあるかもしれません。そのときはご指摘をいただければ幸いです」とでも書いていれば間違っていても問題ありません。

題材は、WindowsにVSCodeをインストールしてみた、Node.jsをインストールしてみた。ソースコードを写経して改造して、どういうエラーが出た！どう直したらちゃんと動くようになったなどでかまいません。

失敗を振り返ることにも大きな価値があります。

noteであれば匿名で活動することも可能でしょう。恥ずかしいという気持ちをもつ必要はありません。とにかく書いてみましょう。

インプット・アウトプット・実践のバランスを取ろう

ブログを書くというアウトプットを紹介しました。アウトプットするためには実験やインプットが欠かせません。

インプットが足りてないのに、実験やアウトプットをしようとすると、足りないピースで無理矢理パズルを解こうとするのと同じように答えが出ません。

実験が足りてなければインプットしても、適切なアウトプットは出せません。

アウトプットをしなければ、インプットや実験をしてもそれらは変な方向に固まってしまい、いつかは頭打ちになります。年を取れば取るほどそれは取り返しに苦労することになります。

アウトプットにかぎらず振り返り自体も重要です。自分が今日やったこと、書いたコード、デバッグした手順、どういうものだったか思い出すだけでも価値があります。その上で、次はどうすればよりうまくいくかほんの少し考えるだけでも、プログラミング脳を鍛えることができます。

実験してみたいという好奇心を大切にしよう

プログラミングに限りませんが「あれを実験してみたい」という気持ち、好奇心はプログラミング上達の大きな推進力になります。

アルゴリズムを試してみたい、ライブラリを試してみたい、新しい設計の考え方を試してみたい。よりシンプルな方法を見つけたい。より効率的な方法を見つけたい。

ひたすら実験を繰り返すのです。

昔のひとはいいことを言いました。「好きこそ物の上手なれ」

ユニットテストを書いてみよう

ユニットテストというのは、ある単体の関数などを自動でテストするためのものです。

ユニットテストはとても強力な武器です。ソースコードの信頼性を高める武器であり、手動でテストすることを減らせられます。

それにユニットテストができるプログラムというのは、メンテナンスしやすい良いプログラムです。ユニットテストしづらいプログラムは汚くメンテナンスしづらいプログラムです。

これは初学者を抜け出して、自分で設計を考えられるようになってからの話になるかもしれませんが、ユニットテストにチャレンジするというのはとても良いプログラミング上達方法なのです。

一番ユニットテストしやすいプログラムは、入力に対して出力がはっきりしていてそれ以外のことをしないコードです。それ以外というのは、画面出力だったりファイルの読み書きだったりネットワークアクセスだったりです。

もちろん画面出力やファイル読み書きやネットワークアクセスなどはプログラムでは必要です。それをどうやってテストしやすい構造にしていくか？というと、たとえば色々な場所から直接アクセスするのではなく、あるインターフェースを通してアクセスする、あるいはアクセスするためのクラスを作るなどです。

これはどういう風に設計すればいいか？という話になります。

TDDという設計手法

TDD（テスト駆動開発 test driven development）は開発という名前がついていますが、実はテストを書きながら設計するための、設計技法です。

設計する対象は、たとえばあるクラスのメソッドを、どういう名前・パラメータ・戻り値などを持たせるか？何をさせるのか？ということです。

まず、あなたの理想を、インプットとアウトプットの組み合わせで考えます。たとえば消費税込みの価格を計算する関数なら、100をインプットとすればアウトプットは108でしょうか。

次にコンパイルエラーにならないための最低限の関数を作ってから、その関数をたたいて100を入れれば108が返ってくるというユニットテストを書きます。この時最低限の関数なのでユニットテストの結果はエラーになるはずです。

あとはユニットテストが動くように実装したりリファクタリングするのがTDDです。この記事はTDD自体を紹介するものではないので、詳しくはさまざまな解説記事や本を読んでください。

さて、重要なのは、この関数がこの設計で正しいか？です。消費税は、それを計算する年月日によって税率が異なります。ならば、何らかの形で計算する年月日の情報が必要になるはずです。

TDDにおいて実装はさほど重要ではありません。どういう構造であれば、目的を果たせるかを確認するための手段です。

TDDがもっとも効果を発揮するのはイチから何かを作るときです。TDDをしながら設計を考えるのです。この構造は扱いやすい？扱いにくい？足りてる？足りてない？むしろ過剰？など。

英語を読み書きしよう

ここまで色々書きましたが、身も蓋もない結論をいうと、プログラミングの上達で一番手っ取り早く、一番重要なことは英語の読み書きです。理由は2つあります。ここではまずその1つであるプログラミングが英語をベースにしていることを説明します。

そもそもプログラミング言語は、よほど特殊な事例を除けば、英語をベースにしています。ifもprintもforもwhileもcreateもreadもwriteも全部英単語です。よほど変なプロダクトでなければ、名前はすべて英単語かその省略系です。

メソッドや関数・命令といったもののネーミングは命令です。「ファイルを読め」が readFile, read_file という名前になったりします。

オブジェクト指向とは、突き詰めるとオブジェクトに命令を出すという考え方です。たとえば wallet （財布）というオブジェクトに、send （送金）しろという命令を出すのです。オブジェクトやそのひな形であるクラスなどは、命令をどう解釈して何をすればいいのかを自分で責任を持っているのです。

最低限の英語の読み書きが出来なければ、ここらへんをスムーズに理解、実践ができません。自分たちのコードはすべてローマ字や日本語で書くから大丈夫という人がいたとしても、利用するライブラリなどはすべて英語ですよね。

もちろん「相撲」に関するプログラミングであればローマ字の出番です。相撲は日本に固有の知識だからです。いってみれば日本固有の言葉が英語化するのと同じです。Tsunami や Karoshi や Karaoke は世界でも通じる言葉です。

英語を読めないと良質で大量で素早い情報を得られない

日本は残念ながらプログラミング後進国です。世界レベルのものは日本にもいくつかあります。それでもプログラミングの最先端や様々な事例、知見は、圧倒的に英語圏です。

アメリカが強いのはもちろんですが、最近では中国は日本を圧倒していて、中国語の情報も多いですが、彼らは日本人よりも多言語に慣れているため英語での発信を全く恐れません。

あなたが利用する言語、ライブラリ、サンプルコードの大半は英語圏（中国なども含む）で書かれたものです。そしてその知見の大半が英語圏で共有されています。

もちろん日本の有志による日本語翻訳というものもありますが、変化が激しく早い現代では、新しい事情に追いつくことが出来ている翻訳プロジェクトはあまりありません。多くの翻訳情報は更新されず古く間違った情報を垂れ流し続けています。

もっとも英語を読むのはさほどムズカシイものではありません。英語の文学を読むわけじゃないですし、日本人並に英語が苦手な人たちは世界中にいて、それらの人たちは結構でたらめな英語を読み書きしているのです。

多くのオープンソースプロダクトでは、英語を苦手とする人でも読めるような簡単な英語を使っています。中学レベルの英語と、あとは頻出する単語だけ覚えれば大体なんとかなります。

それにGoogle翻訳という最終兵器もあります。これを常用することは、英語力が伸びないため、お勧めしませんが、分からないフレーズがあるといった時にとても便利です。

Google翻訳片手にいくつか読んでいけば、少しずつ慣れていくものです。

まとめ

英語の読み書きに慣れましょう。Google翻訳片手でもいいので少しずつ読み書きです。

プログラミングではなるべく小さいサイクルを回し続けることが重要です。コードを書いて動かすというサイクルや、インプットして実験してアウトプットするというサイクル、TDDのように、テストを書く、実装しリファクタリングする、設計がこれでいいか考えるというサイクルなど。小さいサイクルを素早く大量に回すことが、プログラミングの基本であり奥義です。

そして実験してみたいという好奇心は大きな推進力です。