こんにちは。大藏(大蔵)陽平と申します。
フリーランスとして10年システム開発に携わるなかで
バグ調査ほど「やり方次第で時間が大きく変わる作業」はないと
感じています。
闇雲にコードを追いかけていた時期と比べると、今は同じ調査を
半分以下の時間で終えられることが増えました。
その違いは、優先順位のつけ方にあります。
①まず「再現条件」を徹底的に絞り込む
バグの調査を始める前に、「どんな操作をしたときに、何が起きるか」を
可能な限り具体的に整理します。再現条件が曖昧なまま調査を始めると
関係のない場所を延々と掘ることになる。
「特定のユーザーだけ起きる」「特定の時間帯だけ起きる」といった条件が
絞れると、調査範囲が一気に狭まります。
②「最後に変更した場所」から疑う
バグは突然発生しているように見えて、多くの場合は直前の変更が引き金に
なっています。デプロイ履歴、コミット履歴、設定変更のログ。
「何かが変わったタイミング」を最初に確認することで
無関係な場所を調べる時間を大幅に省けます。
③ログを読む順番を決めておく
エラーログ、アクセスログ、アプリケーションログ。
闇雲に全部読もうとするのではなく、「このバグならまずここ」
という自分なりの順番を持っておくことが重要です。
経験を積むほど、この判断が速くなります。
デバッグは感覚ではなく、再現性のある手順で進めるもの。
その考え方が定着してから、調査時間が安定して短くなりました。
ご相談はお気軽にどうぞ。
