応用力をつける
次に応用力をつける方法です。応用力のうち、ここではパターンの習得について述べます。
パターンを習得するためには、次の2つが重要であると考えています。
- 既知のパターンを、自分でも使えるように練習する
- 新しくパターンを学ぶ、特に人が使っているパターンを真似て理解する
今回はプログラミング力という言葉を広く定義したので、ITシステムの作成についてもこれらのパターンを学ぶ方法を示したいのですが、今回は特にコードを書くという観点に絞って述べたいと思います。その理由はいくつかあります。システムは、大きなシステムでも小さなシステムでも、より小さなシステムを組み合わせて作りますが、コーディングも、小さなコードを組み合わせて大きなコードを作るわけで、コードを書くことと大きなシステムを設計することは使う頭が似ており転用が可能です。また、一般にはコーディングよりも設計のほうが難しく、コードを書くという能力を得てから設計に進んだほうが、ステップとしては易しいと思っています。コーディングであれば実行すれば結果が得られるのでフィードバックがすぐに得られますが、設計は時間がかかり、設計のフィードバックを得られるまでに時間がかかるからです。
既知のパターンを自分でも使えるように練習する
既知のパターンを自分でも使えるように練習することの初歩として、小さく易しいコードを大して頭を使わずに書けるようにすることをおすすめします。
どんな大きなコードでも、ほとんど全ては易しいコードの組み合わせでできています。小さなコードのパーツを「大して考えなくても書ける」状態にしなければ、大きなコードを書いているうちに、考えなければならないことが多すぎてヘトヘトになってしまいます。人間の脳という限られたリソースは、まだうまく行くと分かっていない大きな設計をするために利用し、小さなコードは「うまくいくと分かっているパターン」として大して脳のリソースを使わなくとも書けるようになる必要があるのです。
例えばですが、次のような処理を考えます。「いくつかの整数が入った配列が渡されます。この中から指定された値と同じ要素を取り除いた配列を返してください。ただし、新しく配列を作るのではなく、元の配列を変更して返してください」。一部の言語ではこれをやるライブラリがありますが、ライブラリを使わずに書いても難しくはありません（そうですね？）。しかし、やり方を検索し始めたり、if文をどう書くか試行錯誤を繰り返したり、果ては仕様を無視して新しい配列を作ったり、そういう人も多くいます。この程度の難しさのコードを、特に検索しなくても書けるようになりましょう。
小さなコードに時間がかかるのは、大体の場合、単なる練習不足です。逆に言えば、練習すればなんとかなるということでもあります。その練習としては、いわゆるコーディング面接（コードを書いてもらう面接）や競技プログラミング（コードを書いて問題を解くことを競技化したもの）で問われる問題の内、易しい問題を計算ドリルのように一通りやることは近道の一つです。これも情報処理技術者試験と同様に、問題と正答・解説があるという形式なので、自学自習しやすく、実力をつけやすいからです。
かつて競技プログラミングという名前が無かった頃、私も1,000問以上は解きました。数百問くらい解いた頃から、競技プログラミングに限らずとも、考えなくても大きなコードが書けるようになっていました。明らかに小さな関数で悩まなくなったからです。そういうわけで、実力をつけるには非常におすすめの方法です。
コーディング面接に出てくる問題を集めたサイトで世界的に有名なのはLeetCodeです（英語です）。このサイトは世界のIT企業のコーディング面接で出題された（らしい）問題を集めたサイトです。問題にはeasy、medium、hardの難易度が振られており、easyとmedium程度までをあまり考えなくても書ける程度になると、業務で必要な実力としては十分なことが多いです。mediumでも初めて取り組む場合は結構骨があると思いますので、easyから取り組み、アルゴリズムの基礎を学びながらmediumにも手を出してみるといいでしょう。
競技プログラミングは、競技化されているため上を目指せばきりがないのですが、ここでお目にかかることができないような考え方・アルゴリズムも多いです。業務で必要な実力を得る程度であれば、易しいとされる問題を悩まずに書ける程度になっていれば十分です。
新しくパターンを学ぶ、特に人が使っているパターンを真似て理解する
新しくパターンを学ぶには、人のコードを読んだり、人に教えてもらったりするのが手っ取り早いでしょう。そのためのおすすめの手段として、コードリーディング、コードレビュー、ペアプログラミングがあります。
コードリーディングは、すでにあるコードを読んでその内容を理解するものです。自分が使っているオープンソースのライブラリのソースコードなどを読む人が多いように思います。ただし、目的がないまま読んでも大変であるだけで実りが少なく、また、コードがすらすら読めるようなるまでにはかなり実力が必要なので、初期にお勧めできる方法ではありません。ある程度実力がついてきたら腰を据えてなにか読んでみると良いでしょう。
コードレビューとは、書いたコードを他人の目で読んでもらい、誤りがないか、もっと良い方法がないかを指摘してもらうものです。一部の企業では、コードをレポジトリにコミットする前に（あるいはコミットした後のところもあるそうですが）、コードレビューを義務付けています。手癖で書いてしまいがちなミスを見つけてもらったり、自分が書いたコードより良い書き方を教えてもらったりで、非常に勉強になります。コードレビューがマストになっていれば、レビューを通すためにきれいなコードを書く努力も必要になり、普段からきれいなコードを書く練習ができるようになります。また、業務のコードで行えば、普段使っているコードがきれいになるという直接的な業務上のメリットもあるため、非常におすすめの方法です。適切なレビューができるようになるためにはかなりの実力が必要ですが、まずは自分ができるところからレビューし、コードを書いた人に質問・疑問をなげてみるといいでしょう。初心者が勘違いしやすいコードは設計が悪いから、ということもあるため、初心者の質問・疑問も意外と設計の見直しに役に立ちます。
ペアプログラミングは、二人で目的のコードを書く手法です。一人がコードを書いている間、もう一人は画面をみながら書かれたコードに誤りがないかを探します。ある意味、書いたそばからコードレビューしていることになります。この方法は、ペアのコードの書き方をリアルタイムで見ることができるため、普段自分が使ったことがないIDEの機能やコマンドの叩き方、あるいはプログラミング上の工夫を知ることができる非常に良い機会になります。ペアがなにか魔法のようなことをしていたら、教えてもらって自分もできるようになると良いでしょう。そうするとどんどん自分の生産性が上がっていき、それを別の人とペアを組んだときに教えることで、良いやり方がチーム内で回っていくことになります。
