どうも、tatsuです！
今回は、プログラミング初級者が中級者へとステップアップするためのライフハック記事になります。
私の中でプログラマー（エンジニア）は以下のようなレベルに分けられると考えています。
| レベル | 能力 |
|---|---|
| 初心者 | プログラミング未経験 |
| 初級者 | プログラミングができる |
| 中級者 | より良いプログラムを書くにはどうしたらよいか考えてプログラミングができる |
| 上級者 | 最新技術にアンテナを張り、知識/経験からどのような開発方式をとるかを提案でき、技術的にチームをリードできる |
| エキスパート | 新しい技術を生み出し、IT業界をリードできる |
※上位は下位の能力を持っているものとします
この中で初級者から中級者になることがかなり大きなステップアップだと考えているので、その部分に関して話していこうと思います。
なので私が中級者になるために勉強したことを記事にしてみました。
目次
なぜ「プログラミングができる」だけではダメなのか
プログラミングができるだけでも、ソフトウェアを開発することは可能です。
時間が無いときなんかは何も考えずに動くものを作ってしまいがちですが、それはよくありません。
「プログラミングができる」だけで一番苦労するのはプログラムの改修時です。
プログラムを改修するのは大したことなくても、プログラムを改修したことによる他の機能への影響が大変です。
よく考えて作られたプログラムであれば、機能を1つ改修するのはその機能のみに集中していれば良いです。
しかし、とりあえず動くプログラムを作った場合、機能を1つ改修したら他の箇所でバグがでて、それを直したら他のバグが・・
という負のループにハマってしまうことがあります。
こうならないためには、これから紹介する技術を学んでプログラミング中級者へとステップアップする必要があります。
中級者になるために必要なこと
中級者になるためには以下のことを学んでいく必要があると考えています。
※実際にすべてを実践するかどうかは別として、考え方を学んでおく必要があるということです。
順番は学ぶのにオススメな順になっています。
- 単体テスト（ユニットテスト）
- リファクタリング
- デザインパターン
- ソフトウェアアーキテクチャ
- 継続的インテグレーション（CI）
ひとつずつ説明していきます。
※具体的な方法については記述しません。あくまでこのようなことを勉強する必要があるという意識で読んでいただけると幸いです。
単体テスト（ユニットテスト）
プログラムが完成したらテストすると思いますが、どのようにテストしていますか？
適当に何パターンか動かしてみる？
Excelにパターンを書き出して手動でテストする？
一回作ったら二度と変更しないプログラムであればそれでも良いでしょう。
ですが現実的に考えてプログラムというものは変更されるのが常です。
上記のようなテストしか行っていない場合、機能改修後に既存機能に影響が出ていない事を確認するためにはもう一度手動テストをしなくてはなりません。
少しの変更で全てのテストをし直すというのはとても骨の折れる作業であり、大抵の人はやっていないのではないでしょうか？
単体テストコードというものを書いておけば、既存機能への影響テストは数秒～数十秒で済みます。
単体テストツールとして、JUnit（Java）やRSpec（Ruby）などがあるので調べてみてください♪
単体テストをコードを書く前に作成して、そのテストを満たすように開発していく手法をテスト駆動開発（TDD）と言います。
単体テストについてはテスト駆動開発に関する書籍を読むと理解が深まると思います。
オススメは以下です。
リファクタリング
順番的には単体テストが先となっていますが、本当は同じ順番にしたいくらい先に学んでほしいのがリファクタリングです。
リファクタリングとは、ソフトウェアの動き・振る舞いを変えずにソースコードを綺麗にすることです。
このサイトでも何回かリファクタリングに関する記事を出しているのでリンクを貼っておきます。
また、私が参考にしている書籍は以下です。
デザインパターン
デザインパターンとは、プログラミングを行うにあたって「このようなパターンで実装すると良い」といったパターンをまとめたものになります。
デザインパターンはリファクタリングと密接に関係しているので、リファクタリングと同じタイミングで学ぶことをオススメします。
有名なものとしては、GoF呼ばれている人たちがまとめたデザインパターンです。
私が参考にしているのはGoFがまとめたデザインパターンをわかりやすく日本語でまとめている以下の書籍です。
ソフトウェアアーキテクチャ
ソフトウェアアーキテクチャは、リファクタリングやデザインパターンよりももっと外側のお話になります。
システム設計方法といった方がわかりやすいでしょうか。
例えば「画面表示するソース・データを加工するソースを分けましょう」といった、ソフトウェアを作る上でのルールになります。
ソフトウェアアーキテクチャはソフトウェアを開発する前段階で十分に検討して決めておくことが望ましいです。
最近ではクリーンアーキテクチャというアーキテクチャが流行っているイメージがあり、私は以下の書籍を読みました。
継続的インテグレーション（CI）
継続的インテグレーションを端的に言うと、
共有リポジトリにコードをアップしたときに自動ビルド&自動テストを行う開発手法
です。
継続的インテグレーションはDevOpsという開発手法の1つです。
DevOpsについて調べてみるとより理解が深まるかと思います。
詳しく説明します。
Gitを使ったチーム開発をイメージしてください。
中央リポジトリからクローンしたブランチで開発し、開発が終了したら本線にマージしますよね。
もちろん他の人も並行して開発しているため、自分の変更した箇所が他の人の変更箇所に影響を与えている可能性があります。
マージ時に自動でビルド&テストを行うことで、バグの早期発見につながります。
これが継続的インテグレーションです。
また、継続的インテグレーションの代表的なツールとしてはJenkinsというものがあります。
以下は継続インテグレーションのオススメ書籍です。
まとめ：ひとつずつ学んでプログラミング初級者を卒業しよう！
いかがでしたか？
学ぶことがたくさんあって混乱してしまうかもしれませんが、一気にやる必要はないのでひとつずつ確実に学んでいきましょう。
私もまだまだ詳細まで知り尽くしているわけではないので、間違っている箇所・追記した方がいい箇所がありましたら、コメントで教えていただけると助かります！
それでは！
コメントを残す