- オープンソースライブラリのバグを追跡している過程で、デバッガが動作しない問題が発生した
- コードが実行されたにもかかわらず、ブレークポイントが無視される現象が起き、別の方法で問題を探そうとした
- ログ出力を追加するなどの迂回的な診断の試みをしたが、望むような洞察は得られなかった
- 最終的にデバッガの設定ミスを修正すると、プログラムの動作を細かく観察できるようになり、それによってバグを解決した
- 問題解決に没頭するあまり、道具自体の欠陥を見過ごした経験を通じて、開発者はまず道具を直してこそ効率的に問題を解決できることを強調している
バグ診断中に起きた問題
- 保守しているオープンソースライブラリのバグを探す過程で、デバッガがブレークポイントを無視する現象が発生
- コードがその行を実行したことは確実だったが、プログラムは停止せずに完了した
- 問題解決に集中するあまり、デバッガの問題は脇に置いて別のアプローチを試した
- コード修正やログ追加による診断の試みを行ったが、有用な情報は得られなかった
デバッガの修正と問題解決
- デバッガの問題を解決することに決め、1行の設定変更で修正を完了
- 修正後はプログラムの動作を詳しく観察できるようになった
- この情報をもとに、バグの解決に成功した
気づきと教訓
- バグを直そうとする熱意が、かえって道具の問題を見過ごさせていたという逆説的な状況に気づいた
- 道具が正しく動かなければ、問題解決の効率が落ちることを身をもって体験した
- 開発者に必要なのは、問題より先に道具を点検し、直す習慣である
- 「Fix your tools」という言葉で、すべてのプログラマーに道具の重要性を思い出させるメッセージで締めくくられている
1件のコメント
Hacker Newsの意見
経験30年だが、最近は開発ツールがあまりにも壊れている
LinuxでClioを使ってコードを書いているが、ここ数年でバグがどんどんひどくなっている
今ではもう「動かないなら動かないで仕方ない」と流すようになった。人生は短いし、他人のコードまで直す余裕はない
問題を直そうとすると、結局**「yak shaving」**にはまりがちになる
些細な問題を解決しようとすると、細かな作業が次々と連鎖していく
関連動画はこちらで見られる
ときにはツールやライブラリを整えておくことで生産性が爆発的に上がるし、別のときには単にハードコーディングで押し切るほうが速い
AIはツールを整える助けになる一方で、同時に対象範囲を広げてしまい、結局ツール管理に同じだけ時間を使うことになる
結局は**感情的な先延ばし(procrastination)**の問題でもある。全体構造を考えたくなくて小さな修正だけを繰り返したり、逆に全体設計を先延ばしにして細部のツールだけを磨いたりする
実際には必要な摩擦や不便さに向き合う過程でもある
ただし、その不便が本当に必要なのかは常に点検すべきだ
繰り返し作業を自動化したり短縮したりするために10〜15分投資するのは、結局未来の時間を買うことになる
結局技術的負債はいつか返さなければならないので、少しずつ返していく習慣をつけるべきだ
エンジニアリングは結局、斧を研ぐ過程の連続だ
Kent Beckの言うように「まず変化を簡単にできるようにして、それから簡単な変化をしろ」というアプローチが好きだ
単に機能を追加するより、コードを改善するほうがずっと満足感があった
AIは同じコードを何度も繰り返してもおかしいと思わないので、構造化や再利用が進まない
実際には作業の途中で鈍ったときに研ぎ直すほうが現実的だ
「今は忙しくて斧を研ぐ時間がない！」と言いながら、非効率なやり方を続けている
「バグを直したい気持ちが、かえってまずツールを直すべきだという事実を見えなくしていた」という言葉が印象的だった
Kenneth Stanleyの『Why Greatness Cannot Be Planned』でもこの現象が扱われている
素晴らしい助言だ。私も毎日実践しようとしている
だが、「もうツールを直すのはやめて、本当の問題を直せ」という次の助言はなかなか守れない
私もこういう状況をよく経験する
小さな摩擦を直せば後で時間を節約できるが、延々とツールばかりいじってしまう罠がある
本当に難しいのは、「このくらいで十分だ」と判断して先へ進むタイミングだ
ツールは努力を増幅する存在だ
だが、「yak shaving」と不要な手作業のあいだのバランスを取るのは難しい
長期的に同じツールを使うつもりなら、1%の改善でも累積効果が大きいので、思っている以上にyak shaving寄りに傾くべきなのかもしれない
最大の教訓は、オールインワンツールの大半は微妙だということだ
コンテンツパイプラインのためにMake、Airtable、n8nのようなno-codeツールを一通り使ってみたが、ある規模を超えるとどれも破綻した
結局、Pythonスクリプトで直接APIを呼ぶほうがずっと安定していた
本当の解決策は複雑なツールを直すことではなく、シンプルで透明性のあるツールに置き換えることだった
デバッガでコードの流れを直接見ることはとても有用だ
静的解析よりずっと直感的に理解できる
変数やブレークポイントを次々変えていると、問題の本質を見失いやすい
デバッガは仮説を検証するための道具としてだけ使うべきだ。そうでないと「前進している気がするだけ」の錯覚にはまる
こういう文章が好きなら、Emacsは絶対にインストールするなと冗談を言いたい