こういうタイプの質問、マジで多いので書いておきます。
※ 今回はJavaですが発想自体は他の言語(PHP, Perl, C言語, C++, C# ...) でも同じです。
まず、プログラミングは「こう書けばいい」……ではないです。
『プログラムは魔法でもなんでもなく、人間が現実世界でやっていることを逐一指示されながら処理しているだけの代物である』です。
元々は軍事利用でした。
弾道計算や暗号解読とかです。
一応、人間が手作業で暗号解読とかをやることは可能ですが、非効率であり、現実的じゃないです。
暗号方式や時代によっては、たかだか『Hello』の5文字ですら、
1カ月やそこらかかります。
(厳密にはそこまでかからなくても、労力のわりには……)
そこで「んー、じゃあ機械に任せればよくね?」ってことでコンピュータの登場です。
ですがこのコンピュータは 0と1からなる機械語(machine language) しか認識できません。
イメージ的には、
10111101010111010101010101101110000110110101000...
のようなものです。
人間にはきついので、アセンブラとかの言語が出来ました。
ですが問題があったため、C言語とかのような構造化プログラミングができました。
ですがまだ問題があったのでC++やJavaと言ったオブジェクト指向が出来ました。
ですがまだ問題があったので……
というような感じです。
(厳密には違いますが、大雑把な流れはこんな感じ。後はご自分で調べてください)
言い換えると、「私達人間がやっている手順を独自の書き方で書き下し、機械に命令する事」です。
たとえば、テーブルの上にリンゴが一つあるとしましょうか。
Aさんにとって来てもらいます。
さて、どのように命令しますか?
「Aさん、そこのリンゴ、取って来てくれない?」とかその辺でしょう。
(言い回しは変えてもいいけど)
ですがコンピュータにこういう命令をしても認識できません。
コンピュータには、
(下記はあくまでイメージ)
1. 速度◇、10cm前進しろ
2. 右腕を90°、速度◇で挙げろ
3. 右腕を35°、速度◇で下げろ
4. 右腕の人差し指第一関節を速度◇、35°下ろせ
5. 右腕の人差し指第二関節を速度◇、34°下ろせ
6. 右腕の中指第一関節を速度◇、32°下ろせ
...
というような感じで逐一指示しないといけません。
ですが、ここにロジック違反があるとします。
たとえば 出発地点からテーブルまでの距離が8cmしかなかったとします。
普通にぶつかりますね。
速度によってはテーブル自体を倒してしまいます。
このロジック違反を修正したりするのがデバッグ。
つまり、プログラミングっていうのは、
『人間が手作業でやっている処理を細かく指示し、(ロジック等の)違反があれば修正したりすること』です。
よって、プログラミングは「書いて終わり」ではなく、デバッグやテスト(検証)まで含みます。
では入門書等( ProgateとかUdemyとかも含む ) にあることは無駄なのでしょうか。
いいえ、違います。
料理をするときに、すぐに料理に取り掛かりますか?
道具(包丁, 鍋, フライパン等) や材料(ジャガイモ, 牛肉, ニンジン等)がそろっているか調べますよね。
そのうえ、包丁の使い方がわかっていないと簡単に自分の指を切ってしまいます。
(いわゆる「猫の手」っていうやつにしないと……)
そういう『道具の使い方』や『材料がそろっているかの調べ』が基礎に相当します。
では、基礎だけできればいいのか。
いいえ、違います。
プログラミングというのは『機械に命令する事』でした。
(上記を参照)
ではどうすればいいか。
そう、『実際に何かを作る』です。
ただし、「○○作りたいんで、ソースコードください」じゃなくて、
『自分で設計し、自分でコーディングし、自分でデバッグまでする』です。
(できればテストまでできればいいが、趣味でやっていると手が回らないことが多い……)
これは当たり前のレベルです。
「俺はDIYが趣味なんだ」と言う人が、
「椅子を作りたいんだけど、設計図書いて」とか、
「椅子を作ったんだけど、高さが合わないから誰か調整して?」とか言いませんよね。
それは「本当にDIYが趣味なの?」と思いますよね。
なので、自分で設計からデバッグまではできるようにすること。
設計フェーズではできればちゃんとした仕様書(設計図のようなもの)やテスト仕様書・定義書等が作れれば望ましいですが、
個人で特に趣味でやっている人だとそこまでは出来ない事が多いです。
(情報があまりにも少ない上に、そもそも書き方が会社とかによって違うらしいので……)
ですが、「どういう処理が必要か」とかの情報をまとめる事ぐらいはできますよね。
なので設計フェーズでは少なくとも情報をまとめる程度ぐらいはやりましょう。
そしてコーディングし、デバッグまでする。
これが基本です。
以下は私の場合の実装方法です。
Step1. 情報をまとめる
課題や競技プログラミングなんかであれば「問題文」、
実務では「仕様書や定義書」、
自分用のソフト等であれば「情報をまとめる」ですね。
これらを読んで、情報をまとめる。
何が求められているのか、条件(範囲とか)はなんなのかとか。
Step2. 『現実世界でならどうするか』を考える
プログラミングは「現実世界での手順のシミュレーション」なので。
Step2.1. 『ユーザ目線』で考える
課題とかではあまり意識しませんが、それ以外(実務や自分用)では意識します。
たとえばAm*zonのようなECサイトを作るなら、
メインページを開く
→ 検索窓に『Java 入門 本』とかを入れて検索する
→ 該当する商品の一覧が表示される
→ 商品の画像をクリックすると
→ 詳細情報がかかれたページが表示される
→ 詳細ページの『買い物かごへ』的なボタンを押すと
→ 買い物かごにセットされる
→ 『レジへ』のボタンを押すと
→ レジページが表示される
→ レジページの『決済へ』ボタンを押すと
...
のような感じになりますよね。
(微妙に言い回しとかが違っていたりするけど)
この時点で『メインページ』『一覧ページ』『詳細ページ』『レジページ』『決済ページ』がそれぞれ必要であることがわかりますね。
他にも『ボタン』とかも必要だし。
Am*zonのような、購入者だけじゃなくて販売者も関わる場合は、販売者目線も同じように考える。
Step2.2. 『プログラム目線』で考える
次はStep2.1 で考えたものを『裏方』として考えてみる。
一括処理程度のプログラムなら『手作業でやるならどうするか』とかです。
Am*zonとかのようなECサイトなら『裏方作業』と考えてみるとかです。
Step3. 必要なものをリストアップ
たとえば『詳細ページ』とかのやつもそうだし、『データを保存する事』とかもですね。
データ保存はWeb系の場合はMySQL等のようなDB(データベース)を使いますね。
それぞれをリストアップ。
Step4. 必要なものを調べる
入門書とかにあるもの( for文とか )なら入門書とかで調べ、
クラスやメソッド、言語によっては関数とかのようなものは『公式ドキュメント』や『公式リファレンス』なんかで調べる。
(C言語の場合は公式リファレンスなんてのは見たことない気が…… 私が知らないだけか?)
Step5. 実装する
今までのものを実装する。
Step6. デバッグする
これも当たり前。
Step7. テスト(検証)する
これは実務では当たり前だと思いますが、趣味&個人でやっているならそこまで手が回らない事もあるので……
教材については『わかりません』ですね。
私は適当に『Java 入門』とかで検索してヒットしたサイトを使っていますから。
後はその都度調べていけばいいだけなので。
[その他の身に着けるべき技術等]
後は
■ 検索力
■ 考える力
■ 質問方法を工夫すること
■ 『データ構造とアルゴリズム』をやる
■ 『デザインパターン』をやる
■ 『計算量』を意識する
■ オブジェクト指向について学ぶ
■ 『基本情報技術者試験』に出るような内容の理解
■ 数学的思考を身に着ける
でしょうか。
検索力…… これはGoogleとかで検索したり公式リファレンス等を使って調べたりする技術です。
プロでも調べながらやっています。
考える力…… 当たり前ですね。
質問方法を工夫すること…… 回答者は質問者と同じ環境にある…わけじゃないです。
なので質問方法を工夫しましょう。
『データ構造とアルゴリズム』や『デザインパターン』は先人たちの知恵です。
丸暗記は必要なく、単にアルゴリズム(ロジック)を理解するだけです。
(あと発想法も)
計算量……私はそこまで上手くありませんが、場合によっては相当やばいことになります。
実例: 軽い気持ちでLinkedListを使ったら休出する羽目になった話
競技プログラミングなんかではほぼ必須のようです。
基本情報技術者試験…… 上記のいくつかを含んではいますが、この界隈での一般教養に相当します。
(厳密には違うだろうけど、趣味でも意外と使うものがぎっしりと詰まっているので)
数学的思考…… これも必須ですね。
っていうか、プログラミングが出来る人ってこの思考が本能レベル(?)で出来ていることが多いです。
参考: 【数学塾直伝】数学的思考力とはなにか。それは7つの力の複合体である。
まあ、頑張ってください。(^_^)
[追記1]
競技プログラミングをやるのなら
いわゆる蟻本が良いようですよ。
(私はまだちゃんと読んでいませんが、一応挑戦する予定…)
後は調べながらですね。
あ、競技プログラミングで使われるbit全探索についてはここがいいかな?
(私は数学が苦手だったので。まぁ、今も苦手ですが...)
[追記2]
あ、そうそう、一番重要なこと忘れていました。
エラーメッセージはちゃんと読みましょう。
エラーメッセージは怒声でも罵声でも罵倒でもハラスメントでもなく、
コンパイラやインタプリタ等からのメッセージです。
メッセージを読まない人は『相手の話を聞かずに逆ギレしている人』です。
そんな人がコミュニケーションなんて取れませんよね。
例えばC言語やJavaのような型が厳格な言語(静的型付け)
で『変数a未定義』とあれば、
『変数が宣言されていないことが原因』なのだから、
『変数を宣言すれば良い』ということです。
『変数a重複定義』なら『重複しているため、コンパイラがどっちを呼べばいいかわからない』のが
原因なので、
『区別できるように、それぞれ違う変数名にする』とか。
またエラーメッセージには『行数』とかも提示されています。
エラーメッセージとは厳密には違いますが、
『例外』メッセージも同様。
エラーメッセージはちゃんと読むようにしましょう。
[追記3]
コードを読むコツは『一行レベルで、この行がなにをしているかを考えながら読む』です。
例えば(ソースコードのバックアップを取っておいて)
コメントにするとかです。
そして、その処理を現実世界でやってみる。
脳内でもいいです。
とにかく試してみる。
変数とかがあれば、『データの状態』も考えながらやる。
i=0のとき〜、i=1のとき〜、i=2のとき〜
とかみたいに。
具体的な値を入れて考えてみるとかです。