無料マンガ・ラノベなど、豊富なラインナップで200万冊以上配信中！
無料マンガ・ラノベなど、豊富なラインナップで200万冊以上配信中！
エラーでつまずいたらどう対処する？
プログラミングで「詰まない」ための必読書！
プログラミングをしている人であれば、誰しもこんな場面を経験したことはないでしょうか？
「コードがエラーで動かない！」
「エラーの原因がどこにあるのかわからない！」
「何をどうやっても不具合が解決できない！」
どんなにキャリアを積んだプログラマーでも、プログラムのエラーや不具合を完璧に防ぐのは難しいものです。そのため「エラーや不具合の原因をすばやく見つける技術」は、プログラミングをする上で欠かせないスキルの1つです。
本書は、そんな「コードが動かない！」という状況でどのように対処したらよいのか、エラーや不具合との上手な付き合いかたを、新人プログラマー向けにやさしく解説する入門書です。
・エラーメッセージの読みかた
・不具合の原因を見つけるデバッグのやりかた
・そもそも不具合を起こしにくいコードの書きかた
など、プログラミングをする上でおさえておきたい知識と技術を、具体的なコードを例にわかりやすく解説しています。
開発現場の新人はもちろん、デバッグをきちんと学んだことがない中堅の人、さらには「エラーが怖くてプログラミングが楽しくない……」という初心者まで、動かないコードと日々格闘しているあらゆるプログラマーにおすすめの一冊です。
【目次】
●第1章 エラーはどうして怖いのか？
・エラーを読んでみよう
・エラーを読まなくなってしまう理由
・エラーに向き合う心構え
●第2章 エラーの上手な読みかた
・エラーの構成要素を知ろう
・エラーの種類を知ろう
●第3章 不具合の原因を効率的に見つけるには？
・デバッグとは？
・プリントデバッグをやってみよう
・二分探索で効率的に探そう ほか
●第4章 ツールを活用してデバッグを楽にしよう
・デバッガは強力なツール
・ブレークポイントを使ってみよう
・いろいろなステップ実行 ほか
●第5章 どうしても解決できないときは？
・プログラマーのための情報収集テクニック
・エラーが見つからないときは？
・不具合が再現できないときは？ ほか
●第6章 デバッグしやすいコードを書こう
・再代入は控えよう
・スコープは可能な限り狭めよう
・単一責任の原則を知ろう ほか
※本電子書籍は同名出版物を底本として作成しました。記載内容は印刷出版当時のものです。
※印刷出版再現のため電子書籍としては不要な情報を含んでいる場合があります。
※印刷出版とは異なる表記・表現の場合があります。予めご了承ください。
※プレビューにてお手持ちの電子端末での表示状態をご確認の上、商品をお買い求めください。
※アプリの閲覧環境は最新バージョンのものです。
Posted by ブクログ
デバッグの解説されている技術者です
デビューした人向けの入門書っぽい感じでした
DBpressのようなコード羅列ではなく、イラストが盛り込まれ、余白も設けられており読みやすかったです
例に挙げられているのはJavaScriptを始めたとしたフロントエンド言語でした
エラーで表示されているコードは見たことがあり、解説されて読み方が分かりました
今まではスタックトレースも知らずにプログラミングを触っていたので、かなり参考になりました
これらを頭に入れずにどうするというレベルだったので、読んでよかったです
デバッグ操作のステップ云々も分かりやすかったです
デバッガーという便利なモノを知らなかったです
挿入されているコラムに、アヒルの人形を見立てて、コードの説明をするラバーダック法なるものがありました
人に説明する代わりにして、エラーを探すそうです
口に出すことで新発見するのは分かりますが、アヒル人形は？？？でした
この業界はあざといノリがあるのでついていけません
ワガママを言うならば、読んで済ませてしまうため手を動かすことがなかったことくらいでしょうか
目で読んで理解できたら苦労しない分野なので、第６章はついていけませんでした
みんなどこで、こういったデバッグの知識を入れるんだろうと謎に思っていたら
あとがきによると、デバッグ技術は現場の口頭口伝が多いとありました
それは末端には伝わってこないなと呆れました
本書のように体系的にまとめってくださり、初学者は大助かりでした
Posted by ブクログ
プリントデバッグで二分探索
コメントアウト
最小限のコードでデバッグしてみる（いらない部分を削除もしくは肉付けしていく）
bisect（バイセクト）
履歴が時系列で並んでいる特性を活かして、過去のどの時点で不具合が発生したかを効率的に調査できるや
思いつくままに原因と思えそうなことを箇条書きにする
箇条書きの中身をなるべく具体的にシンプルにする
その過程で重複するものは削除、複数の要因があれば分割する
最後に重要そうな順序に並び替える
簡単なコードは助けやすい
テディベア効果
ブレークポイント
変数の中身の確認、任意のコードの実行
バグの原因を特定したり、プログラムの動作を確認できる
デバッガでブレークポイントを作る
処理を中断した状態でコンソールに変数を入力すると不具合を特定しやすい
コード上でも、debuggerで作れる
ステップインはコードを1行ずつ確認できる
ステップオーバーは関数の処理を飛ばして全体を確認できる
ステップアウトはコードの外に出れる
条件付きブレークポイント
XHRフェッチブレークポイント
DOMブレークポイント
イベントリスナーブレークポイント
変数を監視すると、変数の値を代入できる
グローバル変数しか確認ができないので、ローカル変数を確認する場合は一度グローバル変数で定義し直すことが必要
情報収集テクニック
Googleはダブルクォーテーションで囲むと完全一致検索ができる
具体的なファイル名はいれない。たまし
ライブラリは逆に名前を入れる
英語で検索する（〇〇 not working）
（〇〇 doesnt work)
how to useやhow to implementなども良い
Github code searchを使う
/正規表現/げ完全一致検索
path: tailwind.config.jsなど
一次情報と二次情報
一次情報は公式の情報で精度が高い
意外な機能や仕様を知れる
二次情報は古い情報や書き間違いがある
正しい情報を選別する必要がある
エラーメッセージのuncaught errorはtry catchで処理されなかったエラー。エラーを握りつぶす
クラスや関数などのコードが持つ責務は一つにするべき
純粋関数である関数が読みやすい理由
引数が同じであれば同じ戻り値になる
副作用がない
純関数はそうでない関数と比較して読みやすい、デバッグがしやすいという特徴がある
副作用があると、関数の外に影響が出るので保守しづらい
Posted by ブクログ
対象は，新人向けかもしれないが，シッタカを解消できる本．
情報収集としてのGoogle検索とGitHub検索，デバッグしやすいコードに関する話は，言語に関係なく通じる話！
※組み込みの仕事をしているのでJavaScriptはよくわからなかったけれど
・寝るとバグが直る？
→思い詰めたときは思い切って寝ることで記憶の整理をするのも手
・検索テキストをダブルコーテーションで括る
→単純なスペース区切りの場合，部分一致検索結果も表示されるので，目的の内容にたどり着けないことも？
・GitHub code searchを使う
→ライブラリーなど他の人の使い方を検索することができる（なるほど，と思った）
・変数の再代入は控える
→どこでその変数が変わったのか読みづらい
・単一責任の原則
→関数に複数の役割を持たせないようにする
※アプリの閲覧環境は最新バージョンのものです。
ビジネス・実用
