結局は、最初から読んでおけば良かったと思うことの方が多い。当たり前のようにサンプルコードがついていることが多い。公式のサンプルこそが一番に参考にすべきコードだろう。コードなら英語も日本語もなく読めるはずだし、動くサンプルが一番わかりやすい。当てずっぽうで試していかないエラーが出て直すときや、デバッグをするときなど、手当たり次第に変えてみることは、やめよう。やるにしても、それは最終手段だ。それで動いたあとで、なぜ動いたのか追求して理解しておかないと、いずれ困ることになる。動くまで当てずっぽうで試すのは、もはやプログラミングとは言えない。動いただけかもしれない。思わぬバグをさらに埋め込むことにもなりかねない。意志なく書かれたことで埋め込まれたバグは、とてもタチが悪い。プログラミングをする際は、そのプログラムの設計(コードそのもの)に意図を込めるようにしよう。そのように書いたのか、他の人が読んでわかるように書くことが理想だ。未来の自分は、もはや他人なのだから、自分のためにも。未知のものは、まっさらな環境で試そうドキュメントを読むだけでは理解は難しい。プログラムは実際に動かしてみて、そのコードと動きの関連が頭に入ってくることがある。サンプルコードを真似して、そこから少し変えてみて動いたり、動かなかったりすることで理解が深まる。した原理を理解するためにコードを書いて試すのは良いが、実際に作ろうとしているプログラムの本体で試さない方が良い。新しいライブラリを試したいと思ったら、なるべくまっさらな環境で、それだけを動かしてみよう。試すときに、最初から本番の大きなプログラムに組み込んでしまうと、動かなかったときの原因がどこにあるかわからなくなってしまうことがある。本体とは別の小さなプログラムで試してみると良いだろう。ライブラリを見つける力と目利きを鍛えようプログラミングの世界は、非常に広大な知識が必要になる。今やオープンソースの文化によって、探して使えるライブラリの数も相当な数になる。あらゆるライブラリに精通してから作ろうというのは、現実的ではない。実際に作りたいものがあって、それを実現するための知識さえあれば良い。全てを理解して身に付けてから始めようと思うと、いつまで経っても始められない。作っている最中に新しいものを見つける目利きを磨いた方が良い。githubであれば、最近のコミットはいつか、どれくらいのスターが付いているか、そうした辺りも確認した方が良いだろう。大雑把に理解できる力を身に付けようわからないことを調べていくと、どんどん深みにはまっていってしまい、本来やるべきこと以外のことを調べていたりすることもあるだろう。興味のままに調べて知識を得ることも、とても大事なことだ。好奇心を失ってはいけない。一方で、作ろうとしているソフトウェアに必要のないことまで調べてばかりいては、時間がいくらあっても足りない。どの程度まで理解すれば十分なのか見極めないとキリがない。仕事でプログラミングをするなら、プロとして時間を意識しよう。実現しようとして必要な知識をパッと得るだけでなく、書籍を読むことも大事だ。ソフトウェアエンジニアリングやコンピュータサイエンスの書籍を読んで、バックグラウンドを身につけるのは、新しい技術を大雑把に理解することに役立つ。一度に大きく作ろうとせず、小さく進めようどんな大きなソフトウェアも、小さなプログラムの組み合わせで出来ている。一気に作ろうとせずに、少しずつ動くことを確認しながら進める方が良い。実行しないで、コードを書き続けて、最後に一発で実行して成功するのは難しい。エラーが出てもどこに問題があるのかわかりにくい。書いては実行して動くことを確認することを繰り返していけば、エラーが出たときの問題箇所の特定が楽になる。どの時点でも、「正しく動く状態」をキープし続けよう。何日も仕掛かり中の状態を残さないようにするためにも、一度に作る単位を小さくすることが大事だ。コミットする前には、動作確認しようもはやgitのようなバージョン管理ツールを使うのは当然のことだが、バージョン管理に保存するのも、なるべく動く状態にしてからコミットしよう。IDEを使うときなど、新しいプロジェクトを作ったら、まず何のコードも書いてない状態でも実行してみる。それだけで動けば、gitにコミットしてしまうと良い。常に動く状態を残し続けると良いだろう。コミットする際には、必ず差分チェックをして、自分がやろうとしていたことだけが含まれているかどうか確認をしてから行うようにしよう。最初にTODOリストを作ってから、始めよう料理にレシピがあるように、プログラムを作るときにも手順がある。料理と違って、どのプログラムもユニークなので、レシピを流用することは出来ないが、作り始める前に、これから何を、どういう順で作っていくのか考えよう。プログラミングを始める前に、TODOリストを作ると良い。これから自分が手を動かしていくことを順にリストアップする。TODOリストがあれば、今どこをやっているか明確になるし、余計なことを考えずに集中できる。1つのTODOは30分〜1時間で終わる程度にして、その単位でコミットする。TODOリストは仕様書ではない。自分のための手順書だ。最初から完璧なTODOリストでなくても構わない。TODOリストは自分のためのものだから、途中で書き換えても構わない。頭から順に書き始めずに、構造化しようTODOリストを書くには、頭の中でどんな構造のプログラムになるか考えておく必要がある。そのように手を動かす前に、頭で考えておくこと、ロジックを通しておくことが大事になる。プログラムがコンピュータで実行される時は、基本的にはコードを上からシーケンシャルに1行ずつ実行されていく。ソースコードというのは、それがコンピュータで実行される状態を抽象化して構造化されたものになる。1〜10をカウントアップしながら1行ずつ出力表示するようなプログラムを作るにも、丁寧に1行ずつ全部書く必要は無い。繰り返し処理にして、数字部分を抽象化すれば短いコードで済む。非常に単純化して言えば、抽象化とはそういうことだ。頭で理解しきれないなら、絵にしてみようもし、これから作ろうとするプログラムの構造がどんなものになるのか、どういった処理の流れか、頭の中で考えきれない時は、絵を書くことだ。プログラムを書くよりは早く、具象化してイメージすることができるだろう。インスタンスがいつのタイミングで生成されて、どのようにやりとりされるのか、実体を絵にしてみることから始めると良い。インスタンスの動きが見えたら、そこからクラスを抽出して考えることができる。頭で考えていると複雑になってしまうことも、絵にしてみると単純なことだったりする。頭の中でコーディングする際も、頭の中のメモリが足りなくなる時がある。そんな時も紙を使って書き出しておくのも、頭の整理には重要だ。メンテナンスの前に、コードを読み込もう動いているプログラムを修正するときは、しっかりとコードを読み込むことから始めると良い。自分がこれから書くコードのことだけ考える前に、そのプログラムがどういう構造になっているのか知っておこう。コードを読み込んで、時にはリファクタリングまでしてしまうのも良いだろう。リファクタリングできるくらいに読んで理解しておくと、メンテナンスで追加するコードもイメージしやすくなる。実際に追加で書く時間よりも、読んでいる時間の方が長くなるかもしれない。考えると、コードを読みやすい状態にしておくことの大事さもわかるだろう。他の誰が読んでも読みやすいコードを書くことがプロの仕事だ。プロとしての仕事を身につけたい最初の第一歩を始めたいと思ったら以下もどうぞ。私たちソニックガーデンでは、プログラミングスキルを磨きたい方、エンジニアとしてより一層成長したい方向けに、仲間と一緒にゼロからWebアプリを制作する「ソニックガーデンキャンプ」を実施しています。これは講師が手取り足取り教えるスクール形式ではなく、参加者同士がコミュニケーションを密に取り合いながら開発・学習を進めていく形式です。自分だけでは成長に限界を感じていたり、どうすればエンジニアとして働けるかわからず悩んでいる方がいたら、ぜひチャレンジしてみてください。通じた自身の体験と思考をログとして残しています。「こんな経営もあるんだ」と、新たな視点を得てもらえるとうれしいです。ニュースレターブログの更新情報や、ここだけの執筆裏話など、3ヶ月に1度のペースでお届けします。「嫌な未来なら変えればいい」あなたの毎日にも、きっと繋がる。Change!」のノベライズ化第一弾。プログラミング脳の鍛え方2017-02-16応援したくなる人の特徴2021-07-08上司と親方の違い、徒弟制度の再発明でプログラマ育成2024-06-13セルフマネジメントの必須スキル「タスクばらし」そのポイント2016-07-22チームとコミュニティの違い、会社・組織をどう捉えるか2020-08-11最新の記事ソニックガーデンの経営組織論(2024年11月版)2024-11-07ソニックガーデン企業理念のアップデート2024-09-30DXを阻むのは人事の問題か2024-08-05合宿は組織のケアか2024-08-04agendさんに取材を受けました「上司ではなく親方。人材が育つための徒弟制度。株式会社ソニックガーデンページ上部へ。