少しプログラミングが出来るようになると、それはそれでまた伸び悩むこともある。始めたばかりの頃は、プログラムが動くだけで楽しかったけれど、実用的で、少し複雑で難しいものを作ろうとすると、途端に時間がかかってしまう。
プログラミングがうまくなる近道などないとはいえ、経験者だからこそ伝えられることもあるのではないか。そう言えば、私も若い頃に先輩から、コードを書くこと以外にも、プログラミングをする上での姿勢や習慣などを教わった。
私もプログラミングを再開したがブランクがあるので、今となっては古い習慣もあるかもしれないが、私が先達から学んだことを伝えておくために残しておこう。もしかしたら、抽象化すればビジネスにも通じる習慣もあるかもしれない。
目次
エラーが出ても慌てず、メッセージを読もう
プログラミングをしていてエラーに出会わないことはないだろう。うまく出来たと思って実行ボタンを押したけど動かない、落ちてしまう。そんな時「xxx 動かない」と、慌ててググってしまいそうになるのもわかる。
しかし、まずはエラーメッセージを読む習慣を身に付けよう。何が起きているのか、ログを読めば大体わかる。エラーメッセージも英語だけれど、ちゃんと読めばわかるはずだ。
それだけで意味がわからなくも、そのメッセージを元に推測をしていく。ロジカルにエラーの原因を突き止めていくのは、論理的思考を考える訓練にもなるだろう。
ネットの情報を鵜呑みにしない
それでもわからないことはググる。もしくは、新しい機能を作るために、どうすれば実現するかわからないときもググる。使い方のわからないライブラリがあってもググる。上手にググれることも、今となっては重要なスキルと言える。
しかし、何かしら記事を見つけたときに、そこに書かれていることを鵜呑みにするとうまくいかない。大体ハマってる様子をみると「書いてある通りにしても動かない」って言う。公式ドキュメントならいざ知らず、誰かのブログ記事でハマっていることがある。よく読めば、もはや古い情報だったりする。
今や沢山の情報がインターネットにあるが、そこに書かれていることが正しい保証はない。そんな当たり前のことを忘れてはいけない。特に技術系の記事なら、書かれた日付もちゃんと見よう。もっと新しいライブラリも出てるかもしれないし、表現のトレンドも変わってるかもしれない。
ググって一番上の記事を一つだけ読んで、そのままコピペして作るのはやめよう。複数の記事を見つけて読み比べて理解を深めてから、自分の書きたいコードを考えるのだ。自分のコードを書こう。
公式ドキュメントから読もう
ハマった時などは、Qiitaやブログ記事がとても役に立つが、その前に目を通すものがある。それは公式ドキュメントだ。メジャーなライブラリであれば、それなりにドキュメントはしっかりしているはずだし、大事なことが書かれている。
確かに、ボリュームもそれなりにあるような公式ドキュメントを読むのは億劫な気持ちになる。英語だとなおさらだ。しかし、急がば回れ。結局は、最初から読んでおけば良かったと思うことの方が多い。
また、当たり前のようにサンプルコードがついていることが多い。公式のサンプルこそが一番に参考にすべきコードだろう。コードなら英語も日本語もなく読めるはずだし、動くサンプルが一番わかりやすい。
当てずっぽうで試していかない
エラーが出て直すときや、デバッグをするときなど、手当たり次第に変えてみることは、やめよう。やるにしても、それは最終手段だ。しかも、それで動いたあとで、なぜ動いたのか追求して理解しておかないと、いずれ困ることになる。
動くまで当てずっぽうで試すのは、もはやプログラミングとは言えない。たまたま動いただけかもしれない。思わぬバグをさらに埋め込むことにもなりかねない。意志なく書かれたことで埋め込まれたバグは、とてもタチが悪い。
プログラミングをする際は、そのプログラムの設計（コードそのもの）に意図を込めるようにしよう。なぜ、そのように書いたのか、他の人が読んでわかるように書くことが理想だ。少し未来の自分は、もはや他人なのだから、自分のためにも。
未知のものは、まっさらな環境で試そう
ドキュメントを読むだけでは理解は難しい。プログラムは実際に動かしてみて、そのコードと動きの関連が頭に入ってくることがある。サンプルコードを真似して、そこから少し変えてみて動いたり、動かなかったりすることで理解が深まる。
そうした原理を理解するためにコードを書いて試すのは良いが、実際に作ろうとしているプログラムの本体で試さない方が良い。例えば新しいライブラリを試したいと思ったら、なるべくまっさらな環境で、それだけを動かしてみよう。
試すときに、最初から本番の大きなプログラムに組み込んでしまうと、動かなかったときの原因がどこにあるかわからなくなってしまうことがある。本体とは別の小さなプログラムで試してみると良いだろう。
ライブラリを見つける力と目利きを鍛えよう
プログラミングの世界は、非常に広大な知識が必要になる。今やオープンソースの文化によって、探して使えるライブラリの数も相当な数になる。あらゆるライブラリに精通してから作ろうというのは、現実的ではない。
実際に作りたいものがあって、それを実現するための知識さえあれば良い。全てを理解して身に付けてから始めようと思うと、いつまで経っても始められない。むしろ、作っている最中に新しいものを見つける目利きを磨いた方が良い。
githubであれば、最近のコミットはいつか、どれくらいのスターが付いているか、そうした辺りも確認した方が良いだろう。
大雑把に理解できる力を身に付けよう
わからないことを調べていくと、どんどん深みにはまっていってしまい、本来やるべきこと以外のことを調べていたりすることもあるだろう。興味のままに調べて知識を得ることも、とても大事なことだ。好奇心を失ってはいけない。
一方で、作ろうとしているソフトウェアに必要のないことまで調べてばかりいては、時間がいくらあっても足りない。どの程度まで理解すれば十分なのか見極めないとキリがない。特に仕事でプログラミングをするなら、プロとして時間を意識しよう。
また、実現しようとして必要な知識をパッと得るだけでなく、書籍を読むことも大事だ。ソフトウェアエンジニアリングやコンピュータサイエンスの書籍を読んで、バックグラウンドを身につけるのは、新しい技術を大雑把に理解することに役立つ。
一度に大きく作ろうとせず、小さく進めよう
どんな大きなソフトウェアも、小さなプログラムの組み合わせで出来ている。一気に作ろうとせずに、少しずつ動くことを確認しながら進める方が良い。ずっと実行しないで、コードを書き続けて、最後に一発で実行して成功するのは難しい。
エラーが出てもどこに問題があるのかわかりにくい。少し書いては実行して動くことを確認することを繰り返していけば、エラーが出たときの問題箇所の特定が楽になる。どの時点でも、「正しく動く状態」をキープし続けよう。
何日も仕掛かり中の状態を残さないようにするためにも、一度に作る単位を小さくすることが大事だ。
コミットする前には、動作確認しよう
もはやgitのようなバージョン管理ツールを使うのは当然のことだが、バージョン管理に保存するのも、なるべく動く状態にしてからコミットしよう。
例えばIDEを使うときなど、新しいプロジェクトを作ったら、まず何のコードも書いてない状態でも実行してみる。まずはそれだけで動けば、gitにコミットしてしまうと良い。常に動く状態を残し続けると良いだろう。
コミットする際には、必ず差分チェックをして、自分がやろうとしていたことだけが含まれているかどうか確認をしてから行うようにしよう。
最初にTODOリストを作ってから、始めよう
料理にレシピがあるように、プログラムを作るときにも手順がある。料理と違って、どのプログラムもユニークなので、レシピを流用することは出来ないが、作り始める前に、これから何を、どういう順で作っていくのか考えよう。
プログラミングを始める前に、TODOリストを作ると良い。これから自分が手を動かしていくことを順にリストアップする。TODOリストがあれば、今どこをやっているか明確になるし、余計なことを考えずに集中できる。
１つのTODOは30分〜1時間で終わる程度にして、その単位でコミットする。TODOリストは仕様書ではない。あくまで自分のための手順書だ。最初から完璧なTODOリストでなくても構わない。TODOリストは自分のためのものだから、途中で書き換えても構わない。
頭から順に書き始めずに、構造化しよう
TODOリストを書くには、頭の中でどんな構造のプログラムになるか考えておく必要がある。そのように手を動かす前に、頭で考えておくこと、ロジックを通しておくことが大事になる。
プログラムがコンピュータで実行される時は、基本的にはコードを上からシーケンシャルに１行ずつ実行されていく。だが、ソースコードというのは、それがコンピュータで実行される状態を抽象化して構造化されたものになる。
1〜10をカウントアップしながら1行ずつ出力表示するようなプログラムを作るにも、丁寧に1行ずつ全部書く必要は無い。繰り返し処理にして、数字部分を抽象化すれば短いコードで済む。非常に単純化して言えば、抽象化とはそういうことだ。
頭で理解しきれないなら、絵にしてみよう
もし、これから作ろうとするプログラムの構造がどんなものになるのか、どういった処理の流れか、頭の中で考えきれない時は、絵を書くことだ。プログラムを書くよりは早く、具象化してイメージすることができるだろう。
インスタンスがいつのタイミングで生成されて、どのようにやりとりされるのか、実体を絵にしてみることから始めると良い。インスタンスの動きが見えたら、そこからクラスを抽出して考えることができる。逆から考えても良い。
頭で考えていると複雑になってしまうことも、絵にしてみると単純なことだったりする。頭の中でコーディングする際も、頭の中のメモリが足りなくなる時がある。そんな時も紙を使って書き出しておくのも、頭の整理には重要だ。
メンテナンスの前に、コードを読み込もう
動いているプログラムを修正するときは、しっかりとコードを読み込むことから始めると良い。自分がこれから書くコードのことだけ考える前に、そのプログラムがどういう構造になっているのか知っておこう。
コードを読み込んで、時にはリファクタリングまでしてしまうのも良いだろう。リファクタリングできるくらいに読んで理解しておくと、メンテナンスで追加するコードもイメージしやすくなる。
実際に追加で書く時間よりも、読んでいる時間の方が長くなるかもしれない。そう考えると、コードを読みやすい状態にしておくことの大事さもわかるだろう。他の誰が読んでも読みやすいコードを書くことがプロの仕事だ。
プロとしての仕事を身につけたい最初の第一歩を始めたいと思ったら以下もどうぞ。
＊＊＊
【ソニックガーデンキャンプのご案内】
私たちソニックガーデンでは、プログラミングスキルを磨きたい方、エンジニアとしてより一層成長したい方向けに、仲間と一緒にゼロからWebアプリを制作する「ソニックガーデンキャンプ」を実施しています。
これは講師が手取り足取り教えるスクール形式ではなく、参加者同士がコミュニケーションを密に取り合いながら開発・学習を進めていく形式です。
自分だけでは成長に限界を感じていたり、どうすればエンジニアとして働けるかわからず悩んでいる方がいたら、ぜひチャレンジしてみてください。
ソニックガーデンキャンプ → https://camp.sonicgarden.jp/
