デバッグ術

建物のソフトウェアは、種類の難問です.コンピュータは、我々がそれをすると言う正確に何をする機械です、そして、我々はそれほど多くの問題に直面します.だからここの問題はコンピュータではなく、私たちです.

Act of building software is that of realising the full potential of our intelligence and also our limitations.

我々が通常我々の問題を解決する方法とコンピュータがそれをする方法の間に、インピーダンスがあります.
インピーダンスはなぜ我々がソフトウェアを構築する方法に制約が必要な理由です.
メタロット?😃
ソフトウェアの制約について

Whenever our mental model about how computer operates deviates from how the computer actually operates - we end up with a bug.

バグのソースを知っているので、ソフトウェアのデバッグ方法を見てみましょう.
このようにデバッグにハードと高速なルールのアプローチもないと推測するかもしれません.しかし、時間とともにいくつかのパターンが私のアプローチで現れました、そして、私はこのポストで彼らをcodifyしたかったです.

チャレンジあなたの仮定

我々がそれを仮定するので、我々は問題を見つけるのに苦労しません.しかし、もちろん、それが我々がそうするならば、我々はこのバグに直面していません.
実際には、これは異なる形式をとります.
例:
このようなスタイルでさえ予期しない順序で現れているmodalsの問題に直面しているならば

.modal {
  z-index: 1000000;
}

ここで、仮定は、Zインデックスが高いほど、DOM要素がトップにある結果になるということです.
さて、今、あなたはそれが予想通りに働いていないということを知っています.
我々の仮定は間違っています-それで、我々が上記のケースで行方不明になっていることは何ですか?コンテキストをスタック!
私はそれにあまり深く行きません、しかし、これは多くの人々が彼らがCSSをすることから始めるとき、入るという問題です.ここにはニュアンスが多く、読者にこの資料を探すよう強く求めています.
そして、また、私は事実の後で関係しているスタッキング文脈と他のニュアンスについて学びました.
デバッグの別の副作用は、あなたが取り組んでいることのより深い知識を得ることです.
いくつかのランダムな変更によって修正されて発見されたバグ-試してみて、“なぜ”に深く掘る.それは1つより多くの方法であなたを成長させます.

エラーメッセージを読み込む

これは簡単な右?
しばらくして、我々は当然のことの負荷を取る.何が問題を引き起こしたかについて結論にジャンプしてください.唯一の答えを実現するために時間を無駄に自分自身を見つけるためにあなたの顔を右あなたを見つめていた.

Debugging lot of times an antidote to hubris 😃

例:
一方、反応アプリに取り組んで何も私は期待していたUIを示した.
私はこれらの仮定を貫いた.

私はコンポーネントからJSXを返しませんでした.

は小道具を通過しなかった.

は、白いテキストの上で間違ったCSS -白い背景を適用しました?

.

エラーメッセージを見るだけで、ファイル名をスペルミスしたことがわかりました.

医者を読む

私は正しい知っている?まあ、私はいくつかの分のためのドキュメントを読んで信頼をデバッグの時間を節約することができます.
あなたがGitthubの上で人気のRepoを開くならば、報告される問題の大部分はドキュメンテーションの答えを持ちました.人々は、いくらかのデューデリジェンスをする代わりに問題を報告するために急ぎます.
いくつかのフレームワークとツールは、それらを使用する非常に特定の意味のある方法を持っています.セマンティクスが従わないならば、それは我々を逃す微妙な問題につながることができます.
発行の問題が表示された後でも、我々はおそらく間違って何についての信号を取得します.
ドキュメントが貧しくなることもあります.しかし、それはまだ見ている価値がある価値があります.採掘前に記載されている可能性のある“gotchas”に注意を払う.
例:
私は、私が使用していたフレームワークが互換性がないことを理解するために、asyncアクションのためにライブラリを使用しようとしました.
より微妙なもの
私が初めて反応を使用したとき、いくつかのデータを取得するために、私は無限ループで終わりました.useeffectの背後にある精神的なモデルは、それが見えるほど単純ではありません.
千言葉の価値

例:
私は、私が使用していたフレームワークが互換性がないことを理解するために、asyncアクションのためにライブラリを使用しようとしました.

コンテキスト切り替え

これは私のコードに忍び寄った不吉な方法の1つであることがわかりました.
また、デバッグプロセスにかなり影響を与えました.
ここでのアイデアは、タスクが実行されているときは、そうしながら他の何かに切り替える必要はありません.私は、コストが何か他のものに短いスイッチさえ大規模であるとわかりました.
深い仕事のために、これはあなたの出力を傷つけることができます.
これをしないでください.

例:
私は難しい問題を再現するデバッグ中に流れていた.
私は会合に招集された.会議の後、私は、私が混乱しているために去ったところから出発しました.
これは一般的にほとんどのタスクに当てはまる.
デバッギングは、私が複雑で深い流れの中で最も深い膝であるところです.だから何か他のあなたの注意を要求する場合.息をして、ゼロからスタートして、あなたがそれに戻ることができると仮定しないようにしてください.

抽象化の層を剥離する

上記のアプローチがバグを解決しなかったならば.おそらく、それはあなたをより深く掘る必要がある何かです.
問題に応じて“層”が異なりますが、アドバイスは同じです.
例:
UIの場所は、合計数項目が表示されます-ナンとして表示されます.
層は以下の通りです.

状態管理

を解析している

キャッシング

クエリ

これはフロントエンドとバックエンド( Web devの展望)で起こり得る.
問題が発生した場所を分離するには、次のようになります.

ボトムアップ-問題が発生し、層を上がってから始まる.

下に

トップ-データがどこに問題が起こった場所に入力システムから起動します.

両方の組合せ-中間のどこかの

.

ツールはここでたくさん助けます.ブレークポイントを設定し、コードを通してあなたを歩く-レイヤーを剥離😃.

ペアプログラミング

私たちが何かをデバッグしているという多くの時、それは目の第2のセットが答えを明らかにする可能性があります.これはペアプログラミングが私を大いに助けてくれたところです.
あなたがNarutoを見たならば😃:

一貫してバグを再現する

よく、これは私が共有したすべての私の以前のアドバイスで言われていない仮定でした.そして、それがそうである多くの時間.
バグのこれらの種類は、より低い層よりもアプリケーションレベルで発生します.理由は、低レベルプリミティブは非常に複雑なメッシュで結合/構成する傾向があります.
このための良い比喩はチェスです-各作品は、動きを定義する簡単ですが、それらの組み合わせは複雑です.
定義するのが簡単でマスターするのが難しい言語プリミティブ

ポインター-私は、Phew権利を意味します!

閉鎖-閉鎖-誰でも閉じます?😄

async -まあ、これはすべての最もトリッキーです.これらの問題は再現するのが難しいです、そして、少なくとも言うように、不安定なふるまいに終わります.

CSSカスケードルール-私はポイントの複雑さが高いので、結果を予測することは困難になった後に意味します.

...

そのような性質の問題を再現するためには、いくつかの計装を設定する必要があるでしょう.
時には、ログの負荷を入れて何が起こっているかを確認するように簡単です.そして、それからそれらの条件を作成することによってあなたの環境でそれを再現します.
例:
いくつかのCSSルールが適用されていない場合、分離する最良の方法は次のようになります.

サンプルHTML/CSSを作成します.

は、どちらが問題を引き起こしているかについて1つずつ規則を加えます.

問題が断続的であるならば.テキストをいくつかのように表示されません.

キャッシュをクリアします.

テキストがロードされているロジックを分離します.

可能ならば、その時点でシステム全体を取得します.

任意の非同期ロジックがロジックを分離し、出力を見るために数回実行します.

ゲット/スリープ

あなたが壁を打っているのを発見し続けるならば.それから、それは問題から離れて移動する大きなサインです.
私の一日のより良い部分を取ったバグは、朝に最初に解決されました.だから休憩を取ることによって自分の道から抜け出す.
まあ、それです.私は、これが助けることを望みます!