必ずしも知らなくてもいづれ知ることにはなるので知らないと何もできないってことにはならないとは思う。

が、まぁ今は当たり前だけど当時はどうなのか気になっていたいくらかの項目があって、正直書くの恥ずかしいけど残しときます。

ただただ思うことをまとめてるので他の人の場合は違うかもしれないのでご注意を。

プログラミング入門者、初心者のちょっとした情報になれば幸い。

1.プログラムを丸暗記する必要はない

初めのときはプログラムを覚えているんだろうかと思っていた。たまに知恵袋でもこの質問をしている人がいるのも見るあたり、やはり疑問に思うものなんだと思う。

正直言って丸暗記するのは無理です。膨大なコードを書いていくことになるので全く覚えてられない。なんかものすごくコードに書くのに苦労した部分、デバッグに苦労した部分ぐらいしか覚えていない。あとはこんなの実装したなぁ程度の記憶で止まっている。良いコードもそのまんま覚えることはなく、あくまでこんな設計なのかってことを抑えれば終わり。自分で書いたコードも1週間も経てば忘れるようになるので、気負わないことです。

2.ライブラリはググりながら見つけてく

ライブラリをみんなどうやって引っ張ってくるのか気になっていたも覚えている。本で読むのか誰かに聞くのか。いやググるのだ。私の場合はだいたい英語でぐぐる。英語でよく質問してくれている人がいるから、どんなライブラリがあるか探しやすい。もちろん自分でも質問をしても良いと思う。

「プログラミング言語名  ライブラリキーワード」で検索。Githubとかで★の多いライブラリとかよく質問されているライブラリを探している。

複数のライブラリを比べたいときは「ライブラリA VS ライブラリB」とかやるとだいたいそんな質問をしている人がいますね。。。 tensorflow vs kerasとか調べられますね。

3.新しい言語を覚えてくるのは途中からどんどん楽になる

最初の言語は少し大変かもしれないけど、途中から言語ごとにここが違うのかとかこういう設計思想で用意された言語なんだとか要領よく違いと特徴を抑えられるようになる。そうなってくると後半はかなり楽。

そもそも言語を覚えるって言ってもこれも丸暗記ではない。なんとなく覚えていて、あとはググりながら作業。何回か使ったことある言語は少しググるだけで、簡単にしたいことが見つかる。

ただググるときは抽象的な機能の単語を知っておいた方がやはり得。どの言語でも絶対用意されている関数とか仕組みは他の言語でもあるかをググることが多いので。

例えば、「enum プログラミング言語」とか「floor プログラミング言語」、「ソート　プログラミング言語」とかよく調べる。

4.どんな言語をやるときもデバッグの仕方を知ることから

デバッグとはプログラミングの問題点を修正する一連の作業のことをさす。実行の仕方とか文法とかも確かに大事だけど、何よりもどうやって修正することができるかを先に調べておいた方がいい。絶対に必要になる上に一度コードを書き始めると(人によっては)調べるのが億劫になると思う。使いやすいデバッガはあるのか、とりあえずログを吐き出すには?、使うライブラリのエラーはどこに吐き出されるのか?など調べたらそのあとの作業がぐっっとあがると思う。プログラマには常識だとは思いますが。。。

5.ライブラリはドキュメントを読みながらサンプルを探しながら

ライブラリを見つけてもどうやって使えばいいのかわからないってことはよくあるかと思います。でも画期的な方法はありません。地道にはなりますが、ライブラリを提供する人はほぼかならずREADMEファイルやドキュメント、How to use it等を備えていると思うのでそれを読みながらやりたいことができるかを調べる。ドキュメント内を検索しながらしたいことができる関数があるかを調べるのが普通の作業。

ドキュメントよりも簡単なのはサンプルから引っ張ってくること。多くのライブラリではこれもまた初めからサンプルがついてきていると思います。基本的にはこれを使えばよいかと思いますが、関数によってはサンプルに入っていないかもしれません。ドキュメントが不十分なときは私はいつもGithubの検索で関数名を入れてプログラミング言語で絞ったりして使い方を調査したりします。

6.基本自分のコードが間違ってる。プログラミング言語がおかしいことはまずない

まずないです。CがバグったとかJavaのバグ?とか言わない方が恥を書かないかと思います。初心者がつまづくところ周辺ではまずありません。

7.エラーが出たらまずエラーの単語でぐぐる

エラーが出たらエラーのもっとも上の文章でGoogle検索するのが初めの一手。ぴったしの質問をしている人がいればいいが、いないことも多い。その時は似たような質問から関係していないか、問題の箇所はどういったことに関係している話なのかを調べながら学んでいきます。

ポイントは

• 一番初めのエラー
• 上記エラー文章の全文
• 自分の予想を入れずに黙って検索

をしながら調査することだと思う。エラーの後半は前半のエラーによって引き起こされているかもしれないので、初めのもの。エラーの文章の意味がわからないところでもとりあえず入れてみるのが大切で、案外エラー全体で質問をインターネットで投げている人の文章にひっかかる可能性もでてくる。もし自分の環境に依存する単語やパス、数字があったら消した方がいい。

8.一発で動くものをかける人はまずいない.テストとデバッグは必須作業

上級なプログラマでも一発で数千行を書いてデバッグ、テストなしにコードを動かせる人はまず絶対にいない。設計の時点でなんらかの制約や使いやすさを考慮していないからだ。だから何も恥ずべきことではない。

9.ある言語を完全に理解する状態にはならない

なりません。言語仕様をかなり抑えているひとでも完全に理解することはないです。(そもそも完全に理解とは?)理解できた人は「c++ 完全に理解した」Tシャツでもきて寝ましょう。起きたら理解してないことを理解できるはずです。

10.ライブラリの選択は初めは人の多いものにしておくと無難

ライブラリの選択基準はいろいろある。まず目的に沿ったもので自分のやりたいことができそうなライブラリであること。これは大前提で揺るぎない。

次にその候補が複数あるときが問題。そのときはどんな指標で選ぶか。

もし初心者ならライブラリはライブラリの人気で決めた方がいいです。ライブラリの人気があるとサンプルを書く人やブログに自分のやったことを書く人が多くなり、参考にしやすいです。また人が多ければそのライブラリの質問に答えられる人も増えます。そうすると人が多いライブラリの方が安全目になります。

11.デバッグで万策つきそうなとき

私の場合は以下のことをしている。

• よく言われるけど他人に話してみる。
• 似たようなプログラムで簡潔な絶対に動くことがわかっているコードを書いて、それと比較して改変していって違いを調べてエラーの原因やバグの原因を探る。
• 上記と似ているが、一旦ほとんどコメントアウトしてプログラムの実行に影響のない範囲でコメントアウトを外して行って、問題の箇所をあぶり出す。

結構焦っていると忘れてしまうことが多い上記3点。熱中してデバッグをしているとどうしても視野が狭くなって気づけない。。。

おわりに

もしかしたら間違ってるかもしれないので、あまり鵜呑みにしすぎないように気をつけてください。