IwamotoBlog

俺に付いて来い

プログラミング初心者に贈る処方箋

こんにちは!プログラミング一年生の皆さん。プログラミング二年生の岩本です。

ここ一年、結構初心者の方々にプログラミングを教える機会に恵まれました。
難しいですよね、プログラミング。やってみよう!と思う人こそ多けれど、やってみると「思うように書けない…」だったり、「どうすればいいのか全然わからない…」という症状に陥ってしまい、あえなく撃沈。そのままプログラミングを辞めてしまう…といった方を幾人も見掛けてきました。

でも実は、初めたての頃に陥りがちなこれらの症状って、良い習慣や心構えを持つ事で、ある時スッと抜け出せるようになります。
今回はその初心者が陥りがちな症状に効く「こうした事に気をつけてご覧」といった事や、「こうすると良いよ」という処方箋のようなものを、ここに記してみようかと思います。

結構な長文です。時間をしっかり作って読むか、目次を設けたので、気になった章だけつまみ食いするというのも良いでしょう。
勿論、全部読んで頂けると嬉しいですが!頑張って書いたので!

それではどうぞ。

コーディング

とにかく実行、出力する

最初の頃は教わったもの、調べたものをとりあえず書いてハイ終了。そういう人が結構います。
しかし、そういう人はif文やfor文などを使い始めた頃に大体詰まります。何故か?
答えは「その時何が起きているかを理解していないから」です。
ただ書くだけで済ませてしまう人は、変数の中身がどう変わっていくか、という挙動。そもそも代入とは?変数宣言とは?という所を理解せずに進んでいってしまいがちです。

それらの理解は「適宜コードを実行してエラーを吐かないか」、そして「とにかく出力して何が起きるのか?」という事によって為されます。

とにかく出力しましょう。まずはおなじみ"Hello World!!"。これを馬鹿にしてはいけません。「出力」という事が出来るんだ、という事を理解出来るとても良い機会です。

初めて変数を作ったら実行しましょう。そして中身を出力しましょう。案外に変数宣言は難しいです。スペルミス、文法。そういった失敗要素を大いに孕んでいます。
このミスは実行する事によってしか発見出来ません。必ず実行する習慣を身につけましょう。そして、中身を出力する事で、「値が変数に格納される」という事を体感しましょう。

変数に別の値を代入した?実行しましょう。ここで文法を誤る人(ただ代入するだけなのにvarを頭に付けてしまったり、変数名の大文字小文字を誤っていたり…)が結構な割合で居ます。
そして出力しましょう。ちゃんと値が書き換わっているかどうかの確認は大事です。値が書き換わるという事もここで理解しましょう。

最初の内はスペルミス、文法ミスなんてザラです。そしてそのミスは実行するまで発見出来ないことが殆どです。初めのうちは何か新しいことを書き加えたらとにかく実行する習慣を身につけましょう。ここをいい加減にすると後で痛い目を見ることになります。
そして新しい事をしたら、いや、新しい事でなくても出力できるものはこまめに出力するようにしましょう。出力する事によって理解が深まったり、新しい発見があったりします。こまめな出力でしっかりとした知識を身につけましょう。

疑問に思った事はすぐに試してみる

コードを書いている時に、ふと疑問を抱いた事は無いですか?
例えば。「同じ変数名で宣言はし直せるのだろうか?」「"10"という文字列を数字の10に変換出来ないのだろうか?」「if文の中にif文は書けるのだろうか?」「数字と文字列の足し算は出来るのだろうか?」「for文のここを書き換えたらどうなるのだろうか?」エトセトラエトセトラ…

それ、凄くいいチャンスです。是非、納得がいくまで試して調べてみてください。それらを試すことで理解が深まります。知識が増えます。
必要じゃない知識なんてほぼありません。その時に試して得た知識はいつか必ず活きる時が来ます。面倒くさそう…なんて思わずに、是非疑問を解消してください。
実行と出力を忘れずに!

複雑な処理はまず日本語で書いてみる

「0~10までループで出力し、それらを順に配列に格納しなさい。」
頭の中でスッと「ああ、こういう処理を書けばいいんだな」と分かった方は、そのままスラスラ書き始めましょう。そうでない方は、ちょっとストップ。
分からないまま書き始めて、コードがぐちゃぐちゃになり「結局何しようとしてるんだっけ」となる…よくあることです。

そういった「どう書けば良い処理か分からない」というものはまず、日本語で書いてみましょう。
日本語って、もう書かれてるじゃん。と思われた事でしょう。もっと詳細に書きます。「上の処理を日本語で細かく説明して下さい」

プログラミングって言語なんですよ。パソコンとのコミュニケーションツールなんです。
プログラミングって、言っちゃえば「僕達がやろうとしている事をプログラミング言語に翻訳している」って事なんです。この「翻訳」ってのが肝で、まあつまりやろうとしている事をしっかり理解していないと、説明できないと翻訳もへったくれもないよねって事なんです。
理解しきれていないから、書けなくなる。書こうとしている事が分からなくなる。

だからまず、僕達が使い慣れている日本語で処理を詳しく説明し直してみる。詳細であればあるほど好ましい。そして、段々にコードっぽく日本語化していく。

上を例にとって実際の例をお見せしましょう。

まず
0~10までループで出力し、それらを順に配列に格納しなさい。
こういう問題文がある。

0~10までループで出力し
ここはさして難しくない、言葉の通りです。とりあえず放置しましょう。

それらを順に配列に格納しなさい。
ここはちょっと怪しいですね。あまり文章が明確じゃないです。ここを明確にしてみましょう。

要するに0~10ループで出る中で順に配列に格納する、という事です。この処理によって最終的に配列の中身は[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]となります。
ここらへんを上手く説明したいですね。こうしてみましょう。

0~10という数字が毎ループごとに出力されていく中でその都度数字を配列に格納し、最終的に[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]という配列を作る。

ここまで書くと大分分かりやすいですね。書くべきものが見えてきました。

どうもまず、0~10まで出力するループが必要そうですね。
次に、それらを格納する配列が必要そうです。
そして、毎ループごとにループで出た値を配列に格納する、という処理が必要そうです。

ここまで来ればもう安心です。が、コードを書いている時に迷走しないよう、コメントで記しておいてそれを道標にしましょう。

以下のようにしてみました。

// 値を格納する配列を作る.

// ループで0~10まで出力する.

// 毎ループごとにループで出た値を配列に格納する.

このようにコメントで残しておいて、そのコメントの下にそれぞれの処理を書いていくと、迷うことはないと思います。かつ、どこまで書いたかという事も分かるので大変良いです。
難しい処理に出会った際は、この「まず日本語で説明してみる」という方法を是非試してみてください。

入り組んだ処理は、まず大きい枠組みからコツコツ作っていく

printHello(10);とすると、10回helloが出力される関数を作って下さい。ですが、4回に一度、helloではなく、hollowと出力されるようにして下さい。」
こんな問題が出たとしましょう。そこの貴方、一気に全部組み上げようとしましたね。

勿論、慣れているなら構いません。しかし初めたての人がこれを一気に組み上げると、まあ恐らくエラーを吐く結末を迎えるでしょう。
しかもその際によくあるのが、どこが間違っているのかが分からなくなる。という事です。

これを防ぐ手段として有効なのは、「大きい枠組みからコツコツ作っていく」というものです。
「大きい枠組みから」「コツコツ」相反する言葉が並んでいて少しややこしいですね。上の例題を基に説明していきます。

上の例題をプロセスで分けると「printHelloという関数を呼び出す」「10という引数を与える」「引数の数だけhelloとプリントされるループを回す」「その中で、4回に一度、hollowになる条件分岐を作る」と、このようにザックリ分けられます。
このプロセスを、一気に作るのではなく、一つ一つ順に組み上げていくと、どこまで正しく組めているかを把握しやすくなり「どこが原因でエラーを吐いてるんだ…?」という事態に陥り辛くなります。

実際にコードで説明していきましょう。言語はJavaScriptです。
一プロセス書き進むごとに、実行して確認するようにして下さい。

1. まずprintHelloという関数を作り、呼び出されるとhelloとでも出力されるようにする。

var printHello = function () {
    console.log("hello");
};

そもそも関数が呼び出せているかどうか、ここで確認しておきましょう。

2. 次に10という引数を与える。

var printHello = function (times) {
    console.log(times);
};

printHello(10);

引数がちゃんと与えられているかどうか、しっかり確認しましょう。

3. 関数の中でループを回す。

var printHello = function (times) {
    console.log (times);

    for (var i = 0; i < 10; i++) {
        console.log(i);
    }
};

printHello(10);

先程は「引数の数だけhelloとプリントされるループを回す」と、このプロセスを分けていました。が、ループの構文は少しややこしいので、ここで一度引数が絡まない単純なループを書いてテストしてみることをお勧めします。
ここを飛ばしていきなり引数が絡んだループを書くと、エラーを吐いた時にループの構文を間違えたのか、引数が悪いのかという判断がつきづらくなります。なるべく単純に、細かく進めていくようにしましょう。

4. 引数で与えた数だけループを回す。

var printHello = function (times) {
    console.log ("times: " + times);

    for (var i = 0; i < times; i++) {
        console.log(i + "回目");
        console.log("hello");
    }
};

printHello(10);

ここで初めてループに引数を組み込んでみます。しっかり"""引数分だけ"""ループが回っているかという事を確認できるような仕組みを作りましょう。
上ではまずconsole.log ("times: " + times);として、今まで通り引数をしっかり渡せているかという確認をします。ここで確認しておく事で、下のループでエラーが発生した際、「そもそも適切な引数が渡されていないのでは?」という可能性を検証する手間を省けます。

ループが引数分だけ回せているかという確認はループカウンタであるiを出力する事で行いましょう。helloを出力する処理はさして難しいものでもないので、もうこの段階で組み込んでも問題無いでしょう。

実は出力にも気を使っています。ただconsole.log (times);console.log (i);とすると、どちらも数字なので「この数字はどっちの変数を出力したものだ…?」という事態に陥りかねません。
それを防ぐ為に、出力する際は、分かりやすく変数名とセットで出力するような記述にする事をお勧めします。
ただ1と出力されるより、times: 1と出力された方が分かりやすいですよね。

また、i: 1と出力されるようにしていても構いませんが、ループカウンタはiなどの無味乾燥な変数名が用いられることが多いです。そういう時は上のように1回目と出力されるようにした方がループの役割にそぐわう出力になるので、こちらの方が良いと思われます。

このように、場合によって出力内容を変えてみると、よりデバッグが行いやすくなります。
ただ特に決まり事のようなものは無いので、あまり「こういう時はどうすれば正しいのだろう?」と思い詰め過ぎないで下さい。大事なのは「見て、それが分かりやすいかどうか」という事です。

5. 4回に一度、helloではなくhollowと出力されるようなif文を書く。

var printHello = function (times) {
    console.log ("times: " + times);

    for (var i = 0; i < times; i++) {
        console.log(i + "回目");
        if (i % 4 == 0) {
            console.log("hollow");
        } else {
            console.log("hello");
        }
    }
};

printHello(10);

いよいよ最後のステップですね。console.log(i + "回目");を残しておくことで、本当に4回に一度だけhollowになっているかどうかという確認が出来ます。
しっかりif文の条件式、そもそもの書いてあることが正しいかどうかという確認をしましょう。

6. 完成!

var printHello = function (times) {
    for (var i = 0; i < times; i++) {
        if (i % 4 == 0) {
            console.log("hollow");
        } else {
            console.log("hello");
        }
    }
};

printHello(10);

デバッグ用のconsole.logを消して完成です!残しておくことにあまり意味は無い上に、無駄に処理と行数が増えるので、しっかり消しておきましょう。

長かったですがいかがでしょう?このように段階を踏んで書いていく事で、着実にコーディングを進めていくことが出来ます。複雑な処理に慣れるまではこのように進めていくことをお勧めします。

検索する時は記事を書いた人の気持ちになってみる

「検索しても欲しい情報が思うように見付からない…」よく聞く話です。
何が悪いのかと言われれば、まあ検索キーワードが悪いのですが、どう悪いのか、逆に何が良いのかというのが分からないと改善のしようがないですよね。

そこで僕は提案します。「記事を書いた人の気持ちになってみて、検索してみよう」と。
見つけようとしている情報は、何らかの記事となって纏められているものが大半です。そして大体の記事は読んでもらう事を目的としているため、検索に引っかかりやすいようなキーワードを記事タイトル、もしくは本文で用いています。
ここでいう引っかかりやすいようなキーワードというのは「汎用的な単語」です。極端な話、JSのアニメーションを調べようとしているならば、「Web アニメーション」より、「JS アニメーション」の方が求めている情報が得られやすいよね、ということです。

つまり「汎用的な単語」を用いれば、引っかかる確率が上がるということです。

しかし、引っかかりすぎるのも問題ですよね。雑な検索を掛けると、沢山の記事が引っ掛かり本当に求めている情報に中々辿りつけない…というのも良くある事です。
そこで、検索をする時はキーワードをなるべく詳細に指定しましょう。「JS アニメーション」よりかは「JS 複数 同時 アニメーション」の方が求めている情報を早く見付けられそうですよね。

そして、検索する時は明確な単語を選びましょう。これも上と同様、より正確な情報に素早く巡り合うためです。
フェードインアニメーションについて調べたいならば「JS アニメーション」より、「JS フェードイン」の方が、確実に求めているものに近づけます。
また、ここで「JS フェードイン アニメーション」とするのはあまり好ましくありません。フェードインとアニメーション位なら大丈夫そうですが、異なる同義語を重ねて使うというのは、文章を書く上であまり考えられません。
「JS」も「フェードイン」も「アニメーション」も入っているような記事が見つかればいいですが、必ずしも見つかるとは限りません。
細かくしすぎるのが良いという事ではありません。本当にそのキーワードで正確な情報が沢山得られるかどうか。記事を書いた人の気持ちになって下さい。

また、検索する時に使う動詞は変に活用したりせずに、言い切りのものを使うことをお勧めします。
「要素 消し方が分からない」などと検索しても、全ての文章において「消し方が分からない」という書き方を採用しているとは限りませんよね。「消せない方も多いと思われます」とか「消し方をお教えしましょう」とか。文章のアプローチは様々です。
ここではなるべく多くの書き方に対応できるよう、言い切りの単語を検索に使うと良いでしょう。「消し方が分からない」よりも「消せない」の方が、記事が引っかかる確率は格段に上がります。

纏めると
* 「汎用的な単語」を用いる。 * キーワードをなるべく詳細に指定する。 * 明確な単語を選ぶ。 * 同義語は重ねない。 * 動詞は言い切りのものを使う。

こういった点に気を付ければ、欲しい情報に素早くたどり着けるようになるでしょう。
勿論、これが絶対に正しいという事はありません。検索の引っかかり具合を見て、適宜単語を変えてみたり、時には同義語を重ねてみたりして、思うように情報を手に入れられる様、努力してみましょう。

綺麗なコードを目指してみる

ある程度慣れてくると、難しい処理も段々に書けるようになって来ます。
その時に一度自分のコードを見返してみてください。そして、ちょっと考えてみてください。「そのコードは読みやすいかどうか」もっと言えば「そのコードを他人に読ませた時、簡単に理解してもらえるかどうか」

読みやすいかどうかの基準は2つあります。「簡潔かどうか」「分かりやすいかどうか」です。

簡潔かどうか、というのは単純で、即ち「処理が煩雑でないかどうか」という事です。
難しい処理、複雑な処理というのは、案外ゴリ押せば書けちゃう事もあるんですよね。簡単な所で言えば、「1~10まで出力する」という処理だって、別に手打ちでconsole.log(1); cosole.log(2);と書いていっても実装出来ます。

が、それは綺麗ですか?読みやすいですか?今はまだ1~10まで出力するというもので済んでいますが、より複雑な処理となると、理解するまでにかかる時間は増える一方です。そして、書いてあるコードが煩雑だと、書いているこちらも混乱してくることが多いです。

手打ちでも「1~10まで出力する」という処理は書けます。ですが、ループ文で書いたほうが書くのも楽ですし、読むのも楽ですよね。
また、簡潔であればあるほど、コードの向う側にある「本当にやろうとしている事」というのも見え易くなってきます。

for (var i = 0; i < 10; i++) {
     console.log(i);
}

どうですか?手打ちでやると10行も稼がなければ「1~10まで出力したい」という意図が見えませんでした。
ですが、上の書き方だと、たったの3行でその意図を汲み取らせることが出来ます。

また、簡潔に書こうとする意識を持つと、それを達成する為に一つの処理に対して様々な書き方を覚えるという事に繋がり、知識も増えます。
そうして増えた知識はいつか必ず役に立つ時が来ます。先程も述べましたが、必要じゃない知識なんてほぼありません。

コードを読みやすくする為、そして自分の知識を増やす為にも、簡潔に書こうとする意識を常に持つよう心懸けましょう。

続いて、分かりやすいかどうかですが、先程の話にも繋がる所があります。「やろうとしている事が容易に汲み取れるかどうか」という事です。
ところでコードが綺麗で嬉しいタイミングってどこですかね?処理が早くなる、という点でも嬉しいですが、それ以上に「他人に読ませる時」、そして「後で自分で読む時」ではないでしょうか。

自分で読むタイミングなんて来るのか、なんて思う人も居るでしょうが、これが案外あるもので「あの時の処理を使い回したい!」といった時や、何らかの事情でコードを修正しなければならないタイミングというものがやってきたりします。
そんな時にどうでしょう、煩雑で汚いコードがズラリと並んでいると「これを読むのか…」なんて気が滅入りそうになりますよね。
そういった事を防ぐためにも、コードは常に綺麗にしておきましょう。

では、コードを読む時、どういった手順が踏まれるのでしょうか。
これは大半の人がそうだと思いますが「まず、これが何のためのコードなのかを知る」そしてその後に「じゃあ具体的にどのような処理が行われているのかを知る」という手順を踏んでいると思われます。
先に「何のためのものか」を知るとコードに関連性を見いだせ、読みやすくなる為です。

であれば、それを踏まえた書く側の意識として持つべきものは「何のためのコードか」というのを容易く理解してもらえる様にする、というものであるべきですよね。
ここに気を配っておけば、他人にコードを読ませる時でも自分が読む時でも、少ない労力で読むことが出来そうです。

では、具体的にどう読みやすくするのか、というお話をしましょう。

まず、変数名は役割が明確なものにする事。
ユーザーの年齢を格納するのに、iなんて変数名が用いられていたら、ましてやそれがコードの各所に出て来たら混乱する事、間違いないです。
では、ここで変数名をageにしてみましょう。少し明確になりましたね。もっと明確に出来ます。usersAgeこんな具合です。
こうすると変数名を見ただけで「ああ、これはユーザーの年齢が入っているんだろうな」という事が容易に察せます。

このように、変数に気を配るだけでコードは随分見やすくなることでしょう。勿論、変数だけではなく、関数、クラス、そしてファイル名にまで気を配るようにしましょう。コードが汚くなる原因として名前が分かりにくいから、という場合が大いにあります。気をつけて書くことでコードの読みやすさは格段に上がります。
最初のうちはどんな名前がいいかな?と立ち止まる事が多いでしょう。が、それは繰り返す内に慣れてきます。諦めずに挑戦してみて下さい。

次に、上の話しに戻りますが、簡潔に書こうとすることも大事です。簡潔な処理は、目的が明確に見えるからです。これもまた、心懸けましょう。

そして、コメントを書きましょう。なんだかんだ言ってもややこしい処理は、頑張って書いてみてもややこしいです。ここは素直に「ちょっとややこしい処理になったな」と思ったら迷わずコメントを書く習慣を付けましょう。
ややこしい部分だけでなく、ここに書いてあれば嬉しいかも、という所や、ここはどうだろう?という所にもコメントは書いておくといいでしょう。

コードはパソコンの為の言語です。それだけでは分からないものは絶対にあります。なので、コメントとして人間の為に分かりやすいメモを残しておいてあげましょう。

綺麗なコードを書こうという意識は、自分のためにも他人の為にもなります。是非心懸けるようにしてみて下さい。

ここら辺の話が気になった方は「リーダブルコード」という本を読む事をお勧めします。ここで紹介したような事や、それ以上にコードを綺麗に書く上で役に立つ知識が沢山書かれています。プログラマーを目指す方は是非一度読んでみて下さい。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

心構え

勉強するなら、何か作るものを一つ決めてみる

何か一つ、言語を勉強する時にドットインストールを使ったり、本を読んで知識を得ようとするのは、勿論良い事です。
が、そればかりしていては結局浅い知識しか得られず、また「これ、結局何に使えばいいんだ…」という気持ちになり、モチベーションが下ってしまう事もあります。

なので、勉強する際は出来る事なら何か一つ作るものを決めてみる、という事をしてみるといいでしょう。
本やWebサービスの学習も取っ掛かりにはいいですが、やはり実際に何かモノを作ろうとした時に得られるものは、前者とは段違いに多いです。
拙い知識でも、検索やありあわせの技術で、無理やり組み上げようとして努力したその経験は後に凄く活きる事になります。

また、努力した成果が明確という点もいいですね。
目に見える成果物が完成して、それが動いているというのは感動もひとしおですよね。
前者も、本を読み終える、学習プログラムを一通り終えるというとりあえずのゴールはありますが、やはり何か物足りない気がします。

そして、そんな小難しいことを差し置いて「何かが作れた!」っていうのは楽しいですよね。勉強に於いてモチベーションというものは凄く大事なものです。
それを保ってあげる為という意味でも、何か勉強しよう!と思った時には、是非何か一つ作るものを決めてから始めることをオススメします。

小さな成功体験を積み上げていく

前項と繋がる話ですが、何かを成し遂げた!完成させた!という体験は、その後の自分に凄く大きな自信を与えてくれます。
難しい実装を頼まれた際に、「こんなの自分に出来るだろうか…」と思い込んでしまいがちですが、成功してきた体験があると「でも、あの時も拙いながらになんとか成し遂げられた、今回もなんとか出来るさ!」という自信を生んでくれます。
その自信が、諦めない心に繋がり、きっと難しい実装をも実現へと導いてくれることでしょう。

では、小さい成功体験はどうやって積んで行くのか、という話をしましょう。
先ほど、勉強するなら、何か作るものを一つ決めてみよう!という話をしましたね。
この「何か一つ作るもの」の難易度をあまり高く設定し過ぎない事、そしてあまり時間がかかりすぎるものにしない事によって、短時間、低コストで達成感を沢山得よう!という思想です。

勿論、あまりにも簡単すぎると「成し遂げた感」が得られないので、程よく難しいけれど自分でも手が届きそうなもの、という設定にしてみるといいと思われます。
こんな事が自信に繋がるのか…?と思われる方もいるでしょうが、これが案外自信に繋がります。是非一度試してみてください。

また、出来ることなら人に成果物を見せて褒めて貰いましょう。誰かに褒められるというのは、それだけで自信に繋がります。
褒めて貰えそうな人を見つけて、成果物を見せつけ、バンバン褒めて貰いましょう!

知らない単語はすぐに調べる

プログラミングと関わっていると、聞き慣れない単語に巡り会う機会が多いですよね。
オブジェクト指向インスタンスクロージャ?コルーチン?単語からは、それが何であるかサッパリ想像出来ません。

そこで、「何だ、難しそうな単語だな…自分にはまだ早そうだ…」と考えるのではなく、「どういう意味だ?」と、積極的に意味を理解しようとしてみて下さい。
新しい知識を得るまたとないチャンスです。

新しい知識は、普段の開発からでも身に付きます。が、こういった知らない単語を調べる事で、自分のレベルより少し高いステージにある知識を得ることが出来たり、また、普段の開発のヒントとなるような情報を得られるきっかけとなったりします。

また、自分の周辺とは少し遠いところにある知識だったりすることもあります。自分がよく開発に使っている言語とは違う言語の知識だったりです。
そういった知識は自分のフィールドを広げる事にもなり、大変良い刺激になるはずです。

このように、知らない単語は自分を知らない世界へ導いてくれる、良いきっかけとなります。見つけたら積極的に検索するような習慣を付けましょう。

なんでもしっかり理解するように努力する

難しい話を読んだり聞いたりした時に、理解する事を諦めて、とりあえず聞いた通りにやるだけやってみたり。また、半端にしか飲み込めていないのに、理解した気になったり…なんて経験はありませんか?
絶対に悪い事とは言い切れません。悔しいですがやはり理解出来ないものというものもあります。それを理解しようと時間を割く事が必ずしも良い事とは言えないからです。

ですが、出来る事なら理解しようと頑張ってみて下さい。
その時は大丈夫でも、またいつか理解しなければならないタイミングがやってきたりする事もあります。また、理解しようと努力して頭を使う事で、考える力は養われます。そうして養われた力は後の開発できっと活きる事でしょう。

すぐに人に聞かないようにしてみる

少し上と繋がる話かもしれません。
人に聞くと楽ですよね。考えるのって面倒くさいですし、どうしても放棄してしまいがちです。僕も割と頻繁に全部投げ出したくなります。

ですが、そういう楽を繰り返すと、自分の為になりません。やはり自分の力で調べたり試したりしたものは、人づてに聞いた知識よりも根強く自分の中に定着します。
考える頭というのも、自分の力でしか養うことは出来ません。
時間は有限です。自分を育てる時間というのは多ければ多い程良いです。なるべく人に頼らず、自分の力だけで努力するようにしましょう。そうすることでしか、自分を強くする術はありません。

が、どうしても人に聞かないと分からないものも勿論あります。そういうものも、最初は自分の力で何とかしようとしてみて下さい。
その上で、どうしても行き詰まった!となったら、人に聞くようにしてみて下さい。

この手順を踏むと踏まないとでは、得られるものが大違いです。
自分の頭で悩みきった上で、正解を聞くと大きな気付きをして刺激を受けます。そうした刺激は、自分の中に新しい考え方を生むきっかけとなります。
また、なるほど!という刺激を受けながら得た知識は、やはり定着も良いです。

自分の頭で考えるのはしんどい作業です。が、そこは自分の為。踏ん張ってなるべく自分の力で考えるようにしてみて下さい。

これはどうやって出来ているのだろう?と考えてみる

普段何気なく触っているアプリなどの挙動を見て、「これ、どうやって実装されているんだろう?」と考えてみた事はありますか。
もし考えたことがないなら、ちょっと意識してアプリなどを触ってみると大変良い刺激になります。

スッと「これはこうしたら作れそう!」と思えたなら、「自分、なかなかやるじゃん」と心の中でガッツポーズでもしておきましょう。
実装方法を知るという事は、自分の技を増やすようなものです。後の開発で、この時知った技が活きる時があります。

「ん?これはどうやって実装するんだ…?」となったら、じっくり考えてみてください。検索をしたり、なんならエディタを立ち上げて再現しようとしてみたり。
新しい知識に巡り合うチャンスです。また、良い脳のトレーニングにもなります。実装方法が分かると、凄くスッキリしますよ!技として蓄えておきましょう。

実装方法は幾らでも知っておいて損はないです。普段使ってるものの実装方法などを考えてみて、自分の中にストックしておきましょう。きっと役立ちますよ!

環境

ツールに気を配ってみる

ツールには気を配りましょう。良いツールは開発のスピードを向上させます。また、新しいもの、カッコいいものを使ってる瞬間ってなんだかワクワクしませんか?
良いツールに変える事で、そうしたワクワク感が得られ、開発のモチベーション向上に繋がる働きもします。
是非良いツールを導入して、快適で楽しい開発ライフを送って下さい!

また、良いツールを導入したら、そのツールについて調べ尽くしてやりましょう。
ショートカットキー、拡張機能…それらを調べ、使う事で、変な話ですが「デキる人」っぽさが自分に出ます。勿論、快適な開発にも繋がります。

自分が使っているツールは色々調べてみると、様々な発見があって楽しいですよ!少し時間がある時に色々と調べ、普段の開発に導入してみて下さい。

最新の技術記事が流れてくる環境を作る

プログラマー、エンジニアたるもの、新しい知識には常に触れておくようにしましょう。普段の開発に活かせたり、興味をそそるものがあれば、学習のきっかけになったりしますしね。知識は幾らあっても無駄にはなりません。

便利なツールなどの情報が流れてきたり、実装方法の記事が流れてきたりと見てるだけでも楽しいですしね!
自分には関係ないかも…と思う記事でも、読むだけ読んでみると良いと思いますよ。案外為になった!となれば儲けものですし、やはり関係無かったら忘れればいいですしね。

損はありません。是非、色んな情報に触れられる様な環境を作ってみて下さい。自分の知識を増やすためにも、興味の幅を広げるためにも。

助けてくれる人を見つける

ここまで散々、「自分の力で」「自分の力で」と言っておいてなんですが、それでもやっぱり、助けてもらえるような人は見つけておいた方が良いでしょう。

どうしても詰まる時は詰まります。そういった時に助けてくれる人が居ないとそのまま挫折するだけになってしまいますよね。
そういった心の拠り所を作るという意味でも助けてくれる人は見つけておきましょう。

また、そういう人から得られる情報、知識は大変参考になるものが多いです。
やはり人に教わるというのは、記事で読むだけとはまた得られるものが違います。自分に問に対して、的確な答えが帰ってくるというのは素晴らしい事です。
自分に役立ちそうな情報を、ピンポイントで授けてくれる事もあります。

ネットから得られる情報も沢山あります。が、人から得られる情報、知識はより自分に寄り添ったものです。そういったものを授けてくれる人を見つけておくと、自分の成長に良い働きをしてくれます。
是非、助けてくれる人を見つけてみて下さい。

おわりに

実践的な知識から精神論的なものまで色々ありましたが、いかがでしたか?

ここに挙げたものって、初心者でないエンジニアが普段から考えなしにやってるような事なんだと僕は思ってます。
それを経験の中で、肌で覚えろというのでは無く、理論として纏められないだろうか?と思って書いたのが今回の記事です。
なので、ホントかよ?と思うものもあったかもしれませんが、試してみて損は無い筈です。

初心者プログラマーの皆さん、是非この記事を役立てて下さい!