この記事ではプログラミング初心者、現場未経験の自分が個人開発でのプログラミングをしたときに躓いたところの改善点を洗い出しています。
デバッグ時に一日、本気で液晶に向き合っているのに、棒巨人漫画よろしく「なんの成果もえられませんでした」ってなるのが一番疲弊します
それどころか大抵、別の正常な部分をいじったり、どこかをいじると、依存関係が破綻するのでバグが増えていきます。
で、この問題はいくら調べても解決しないし、周りの人に聞けないときもあります。
そうなったら一旦視点を変えないと解決できません。
改善点は洗い出して改善していかないと成長できないので、デバッグ大全のようにここにまとめていきます。
文章がおかしいところもありますが自分向けで言語化したものをメモのようにまとめているのでご了承ください。
環境、ライブラリ、設計、コーティング これらはすべて連動していて、これらのどれか一つでもおかしいと、全てが破綻し、どこがおかしいかを探し出すことは困難になってしまいます。
デバッグで引っかかるなら、まずコードがおかしいこと、そもそも設計がおかしいこと、そもそも環境（外部ライブラリやモジュールなどの前提）がおかしいことがあります。
その場合、いくらしらべて解決方法を探してすべての修正方法を試しても、エラー箇所の行だけ直しても治るはずがないです。
重要なのは、殆どの場合、デバッグでエラーを読み、解決方法を調べてすべて試したのに解決しないから詰んでいるのではなく、どこかが破綻しているから成り立っていないと考えましょう。それがエラーメッセージを読み取って改善する能力に繋がってくると思います。
また、完全に理解できないライブラリ、関数はなるべく組み込まないほうがいいです（ユニットテストのようにとりあえず単体で書いて動作を見て、組み込めるかを考えたり理解して使えるようにすることは重要。しかしライブラリを使わないと実現できないことが殆どで、すべてのライブラリを理解、知っている人なんていない）
この問題は例えるなら、数学の文章問題は答えをみても公式や考え方がわかっていないととけません。また、考え方を理解せずに暗記して答えを書いてその時は得点になっても、応用で２つの公式や概念を組み合わせる問題は解けません。
その応用問題が試験に出て解けないという壁にぶつかったとき、改善するべきことは基本の２つの概念の理解と考え方をまず理解することです。決してその問題単体を解けるようにすることではありません。
これを放置したまま学年が上がってしまうとどんどんついていけなくなります
プログラミングの場合、理解できないコードが例えば２つ混ざっているとエラーを治す際に、その２つの理解できないコードが原因となったとき、複合的概念による問題がエラーとしてでているので、問題の認識、改善方法がわからないため、治すことができません
で、一番ベストなのは分かる人に聞くことだと思います。失敗の原因を探すときに、問題の焦点がちがった場合、それを自分自身で認識することは困難です。そのためにも人に聞けるようにコードを書きましょう
①コード
・打ち間違いや定義した変数名、関数名と違うケース（neura→neiraなど）
→コピペ、copirot、ideのプラグインでの予測などで正確さを保証、随時見直し
→デバッグ時のエラーメッセージから予測
→コメントで必ず関数ごとに説明を入れる 他の人、中学生でもわかるように（聞ける状態、誰かに見せたときにその人が理解できるようにしておく）
・文法上のミス、型が違う、nullなど、使い方を間違えているケース
→随時見直し、参照先の可視化と確認、ジェネリクス、アノテーション、コメントを入れてどのような役割をしているかわかるように
→デバッグ時のエラーメッセージで判断可能な状態にするためにコメントなどで説明を絶対に入れる。
②環境
・環境構築でフォルダのディレクトリの配置がおかしい
→なるべくチュートリアルやデフォルトのパスにインストールしておく
→ディレクトリの管理ツールを使う、どこに何をインストールしたかまとめる
③外部ライブラリ
・最新バーションに未対応のライブラリを使ってしまっている
→ダウンロードする際にバージョンの対応状況の確認、注意書きを読む
・ライブラリ自体が新しく、様々な用途を想定されていないライブラリ
→ダウンロードする際にバージョンの対応状況の確認、注意書きを読む
→なるべく使用率が高い外部ライブラリのみを使う
→そもそも外部ライブラリは標準ではなく、バグはあることを肝に銘じて使う
④設計
・依存関係が複雑でバグが増える。多すぎて原因がわからない
→親クラスをいじると当然子クラスは破綻するし、関数を呼び出して使っているなら呼び出し元の関数をいじると連鎖的に破綻する。モジュールやライブラリも同様。
依存関係は極力、個人開発の場合は減らすこと。
→チームでやる場合、部分ごとに責任を振り分けることで動作保証が高くなるはず。
その場合でも全てを連結して動作をさせるときは一発で動作することはないと考える。
・無理な設計
→自分の知識の範囲内で使う。内部処理を完全に理解していないクラス、関数をなるべく使わない（関数が動いているからといって組み込んでも、あとでエラーが出た際の問題の発生原因、問題の発生箇所がこの部分だとわからなくなるため）
→構造化プログラミングのような設計を考える
→勉強しても完全に理解できていないクラス、関数を使わない（例えばラムダ式などの難しい概念の内部処理を理解できていないのに使用することなど）
・依存関係を記載しているファイルやライブラリの配置などがおかしい
importや依存関係を記載しているファイルがおかしい可能性
→エラー時にvscode上で該当のファイルが自動で開かれるのでそこから逆算
★まとめ
依存関係をすくなく
ライブラリは説明をよむ、バージョンを確認
よくわからないコードは書かない
他人が読めるように意識
人に聞く
使用する技術をデバッグしやすいか？をまず第一に考えて設計する
