デバッグ：自分で見つける

初心者の多くは、バグを壁のように扱います。ぶつかって、立ち止まって、誰か他の人に乗り越えてもらうよう頼む。実際にスキルを磨く習慣は異なります。バグを答えが見つかる質問として扱うことを学び、聞きに行く前に答えを見つけに行くのです。

エラーメッセージをノイズではなく証拠として読む

スタックトレースは怖そうに見えるため、常にスキップされます。しかし、通常は何がどこで壊れたのかを正確に教えています。PythonでTypeError: 'NoneType' object is not subscriptableが出ている場合、それはランダムな意味不明な言葉ではなく、リストまたは辞書を保持すると思っていた変数が実際にはNoneであることを意味しています。行番号は場所を教えてくれます。あなたの仕事は、その行から逆に辿って、値が設定されるべきだったのに設定されなかった場所を見つけることです。

オンラインで何か検索する前にこれをしてください。トレースバックの最後の行をまず読んでから、上に向かって進みます。最後の行は通常、実際の例外を示しています。その上の行は、そこにたどり着いた呼び出しチェーンを示しています。

意図的に再現する

バグがときどきしか表示されない場合、あなたはまだそれを理解していません。コードに触れる前に、それを確実に起こるようにしてみてください。一度に1つの入力を変更します。空のリストで失敗するが、満杯のリストでは失敗しないのですか？関数の最初の呼び出しではなく、2番目の呼び出しでのみ失敗するのですか？コマンドで確実に再現できるバグは、80%解決されたバグです。修正が実際に機能したかどうかを推測する代わりにテストできるようになったからです。

問題を半分に分割してから、また半分に分割する

バイナリサーチはソート済み配列のためだけではなく、長い関数またはパイプラインで壊れたコードを見つける最速の方法です。ロジックの後半をコメントアウトするか迂回して、前半がまだバグを生成しているかどうかを確認します。はいの場合、問題は前半にあります。いいえの場合、それは後半にあります。繰り返します。これは200行のスクリプトでも、print()またはdf.head()で各段階の出力を確認する多段階データパイプラインでも同じように機能します。

これはプレッシャーの下でほとんどの人がやること、行をランダムに変更して再実行することを上回ります。これは、それを保存するよりもはるかに多くの時間を無駄にします。

print()が機能しなくなったときはデバッガを使用する

print()文は単純なケースでは問題ありませんが、複数の関数呼び出しにわたる状態を追いかけ始めたら、実際のデバッガは実際の時間を節約します。Pythonでは、疑わしい行のすぐ前にimport pdb; pdb.set_trace()をドロップして、スクリプトを実行すると、nでステップを実行でき、sで関数呼び出しにステップインできるライブプロンプトが表示されます。VS Codeの組み込みデバッガは、入力する代わりにクリックするブレークポイントで同じことを行います。どちらの場合でも、目標は同じです。推測する代わりにプログラムの実際の状態を監視することです。

プロジェクトの残りから分離する

バグが大規模なコードベース内で発生する場合、大規模なコードベース内でデバッグしないでください。関連する関数を、同じ失敗をトリガーする偽の最小入力を含む新しいファイルにコピーします。バグが消える場合、周囲の何かのコンテキスト — グローバル変数、インポート、古い状態 — が本当の原因であり、重要なことを学んだばかりです。バグが分離で続く場合、小さく、共有可能で、テスト可能なケースができ、実際の修正に非常に近づきました。

記憶ではなく現実に対して仮定をチェックする

デバッグ時間の大きな部分は疑いのない仮定に費やされます：