debugging-strategies
体系的なデバッグ戦略を適用する
複雑なソフトウェアの問題のデバッグは、しばしばランダムでフラストレーションを感じるものです。このスキルは、体系的なデバッグ技術、プロファイリングツール、および根本原因分析法を提供し、トラブルシューティングを体系的なプロセスに変換します。
スキルZIPをダウンロード
Claudeでアップロード
設定 → 機能 → スキル → スキルをアップロードへ移動
オンにして利用開始
テストする
「debugging-strategies」を使用しています。 My Node.js API returns 500 errors intermittently. The error says 'Cannot read property of undefined' but I cannot find where this happens.
期待される結果:
この undefined プロパティの問題を見つけるために体系的なデバッグを適用します。
## ステップ1: 再現して観察する
- エラーはいつ発生しますか？常にですか？ランダムですか？
- どの API エンドポイントがそれをトリガーしますか？
- どのようなリクエストパラメータが送信されますか？
## ステップ2: 情報を収集する
1. クラッシュしそうな場所の前に戦略的なロギングを追加します:
```javascript
console.log('Order data:', JSON.stringify(order, null, 2));
```
2. どのプロパティが undefined になる可能性があるか確認します:
```javascript
console.log('Items:', order?.items);
console.log('User:', order?.user?.name);
```
## ステップ3: 仮説
仮説: エラーは次の場合に発生する可能性があります:
- 特定のリクエストタイプに対して order.items が undefined の場合
- ゲストユーザーの場合 order.user が null の場合
## ステップ4: テストして確認する
null チェックを追加し、サンプルリクエストで確認します:
```javascript
const items = order?.items ?? [];
const userName = order?.user?.name ?? 'Guest';
```
この修正を実装するのを手伝いましょうか？
「debugging-strategies」を使用しています。 Help me debug a memory leak in my React application.
期待される結果:
React のメモリリークを体系的にデバッグする手順を案内します。
## 再現フェーズ
1. Chrome DevTools > Memory タブを開く
2. ヒープスナップショットを撮る（の前に）
3. 疑わしいリーク操作を 10-20 回実行する
4. 別のスナップショットを撮る（の後）
5. 保持されているオブジェクトを特定するためにスナップショットを比較する
## 一般的な React メモリリークパターン
1. 登録解除されていないイベントリスナー
2. useEffect クリーンアップでクリアされていないタイマー（setInterval）
3. コンポーネントスコープへの参照を保持しているクロージャ
4. 無制限に成長するグローバルキャッシュ
## クイックデバッグ手順
```javascript
useEffect(() => {
const timer = setInterval(() => {
// ...
}, 1000);
// クリーンアップ関数 - リークを防ぐために重要
return () => {
clearInterval(timer);
// サブスクリプションを削除する
};
}, []);
```
どのような症状が見られますか？DevTools でメモリ使用量が高いですか、それとも実際のクラッシュですか？
セキュリティ監査
安全Static analysis detected 54 potential issues, all confirmed as false positives. The 'scripts' patterns are Go import statements in code examples. 'External_commands' are markdown backticks used for code formatting. 'Weak cryptographic algorithm' flags are triggered by Go standard library package names (crypto/pprof). 'Network' URLs are GitHub source URLs and localhost debugging endpoints. All findings are legitimate documentation content with no security concerns.
品質スコア
作れるもの
elusive な本番バグを修正する
ロogging、スタックトレース分析、差分デバッグを使用して、本番環境での再現が困難な問題を追跡するために体系的なデバッグ技術を適用します。
遅いアプリケーションのパフォーマンスを最適化する
プロファイリングツールと技術を使用して、JavaScript、Python、Goアプリケーション全体のボトルネック、メモリリーク、非効率なコードパターンを特定します。
構造化されたデバッグアプローチを学習する
デバッグのための科学的方法、ラバーダックデバッグ、体系的な問題isolateをマスターして、あらゆるコードの問題のトラブルシューティングをより効果的に行えるようになります。
これらのプロンプトを試す
アプリケーションで以下のエラーが発生しています: [insert error message and stack trace]。根本原因を特定するために体系的なデバッグ技術を適用してください。科学的方法を段階的に説明します: 観察、仮説、実験、分析。
私の [application type] アプリケーションが遅いです。ボトルネックを特定するためにプロファイリングツールを使用するのを手伝ってください。時間がどこに使われているかを見つけるために [Chrome DevTools / cProfile / pprof] を使用する段階的な手順を含めてください。
間欠的なバグがあり、ときどき発生し、非同期操作に関連しているようです。トレースロギングとタイミング分析を使用した競合条件のデバッグについて案内してください。
バグは動作するバージョン [version A] と現在のバージョン [version B] の間に発生しました。 regres sion を導入した正確なコミットを見つけるために git bisect を使用する手順を案内してください。
ベストプラクティス
- 修正を試みる前に、バグを一貫して再現します。一貫した再現なしでは、ソリューションを確認できません。
- 関連のないコードを削除して問題を分離します。問題を実証する最小限の再現ケースを作成します。
- デバッガーを使用し、console.log 文だけではありません。ブレークポイントを使用すると、任意の時点でプログラムの状態を検査できます。
回避
- 一度に複数の変更を加える、実際に何を修正しているかを理解するために、一度に1つのことだけを変更します。
- エラーメッセージを無視したり、スタックトレース全体を読んだりしない、エラーメッセージとスタックトレースには貴重な手がかりが含まれています。
- バグが他の人のコードにあると想定する、ほとんどのバグは、サードパーティのライブラリではなく、自分の最近の変更にあります。