ハクソク

世界を動かす技術を、日本語で。

道具を修理しよう

92日前原文(ochagavia.nl)

概要

  • オープンソースライブラリのバグ診断中に デバッガの問題 が発生
  • ブレークポイント が無視され、他の方法で原因追及を試みるも失敗
  • 問題解決のために ツール自体の修正 が必要と気付く
  • デバッガの設定ミスを修正し、バグの根本原因を特定
  • ツールの整備 が効率的な問題解決に不可欠であることを実感

バグ診断とデバッガの罠

  • オープンソースライブラリ のバグ診断作業
  • ブレークポイント を設定し、デバッガ起動
  • 期待通りに プログラムが停止せず、ブレークポイントが無視される現象
  • 該当コードが確実に実行されていることを 二重確認
  • デバッガの不調を無視し、 ログ出力 によるトラブルシュートを試行
  • ログから有用な情報が得られず、 フラストレーション が増大

問題解決の転換点

  • さらなる トラブルシュートコード の追加を検討
  • 突然、「 まずはデバッガを直すべきだ」と気付く
  • デバッガの 設定ミス （たった一行の変更）を修正
  • プログラムの挙動を 詳細に観察 できるようになり、バグの原因を特定
  • 問題解決のカギは ツールの整備 にあると実感

教訓: ツールの重要性

  • バグ修正 への焦りが、ツールの不備を見落とす原因となる
  • 効率的な問題解決には、 まずツールを最適化 する姿勢が重要
  • ツールの整備 によって、作業効率と精度が大幅に向上
  • バグハンター全員への リマインダー として、「まずツールを直せ！」

Hackerたちの意見

注意点は、ヤクを剃る羽目になるかもしれないってこと。小さな問題を直そうとしてるうちに、いつの間にか3つか4つのタスクに手を出してることが多いんだよね。

└

クリックする前からどの動画か分かってた。やっぱり面白い！

└

笑った！誰かが剃らなきゃいけないからね！

└

関連するXKCD:

└

変だな。ちょうど「マルコム in the Middle」を見てるのに、「マルコム in the Middle」のリンクを見つけた。

└

これに関しては一般的なレシピはないよ。時々、小さなツールやライブラリを整理すると、すごく生産的になって、振り返るとそれが実際に物事を進める鍵だったりする。他の時は、汚いモードで定数をハードコーディングしたり、時間に追われてコードファイルをコピーしたりするけど、振り返ると、クリーンなアプローチで同じ結果を得るのに何ヶ月もかかっただろうし、後のタスクに対するメリットは不明確だったりする。AIの話に疲れた人もいると思うけど、AIはツールを磨くのに役立つと思う。でも、同時に自分の範囲が広がって、ツールに対処するのに同じくらいの時間がかかるようになって、ツールには「念のため」に多くの機能があったり、あまり必要ないプラットフォームやユースケースをサポートしてたりする。簡単にできそうに感じるけど、結局は時間がかかるんだよね。これって、ほとんどが感情的な先延ばしの問題だと思う。どちらにでも転ぶことがあるけど。時には、全体のアーキテクチャを考えるのが面倒で、雑な編集をすることを選んだり、時には、全体の目標が漠然として広がっているから、もっと狭い範囲の neatなツールに取り組むことを選んだりする。

└

これは、ツールがあまりにも放置されて、すべてが壊れてしまったときにだけ起こる。まだその借金を返す時間を取るべきだし、その過程で、将来的には小分けにして返す教訓を学ぶべきだよ。どうせ返さなきゃいけないんだから、「もし」じゃなくて「いつ」ってことだよ。

└

「ヤクシェービング」が無駄なことの同義語になっちゃったのは好きじゃないな。ヤクシェービングの説明の中には、複雑な形の先延ばしと必要な面倒（摩擦）や障害に分けるものもある。ツールを磨くことは後者に入ることが多いけど、その「必要な面倒」が本当に必要かどうかを問い直すのはいつも役立つよね。今すぐその面倒を解決する必要があるわけじゃないってことだし。でも、キャンプサイトルールや3の法則が関わる場面でもある。面倒でエラーが起こりやすい人間の作業をコードで置き換えるのが仕事の人間としては、「これが今の私の人生だ」って考え始めたら、自分を問い直さないといけない。だって、誰が「ノー」と言えるかって言ったら、私たちなんだから。繰り返しやらなきゃいけないタスクを10分から5分、あるいはゼロに減らすために、タスクをやるたびに12〜15分を使う価値は常にあるよ。タスクを後回しにせず、もっと完全に取り組むことで、いつかはそのタスクを全くやらなくて済む日が来るかもしれない（完全に自動化したり、委任できるくらい簡単にしたり）。ハルの例は面白いよね、彼は同時にA列とB列のものを全部すくい上げてるから。みんな笑っちゃう。実際にやらなきゃいけないタスクもいくつかあったし、買い物リストに入れても良かったかも。

エンジニアリングは、斧を研ぐことの連続的なレッスンだよね（木を切るのに6時間かかるなら、最初の4時間は斧を研ぐことに使えってこと）。ケント・ベックの好きな言葉: 「まずは変化を簡単にし、その後で簡単な変化を実現する。」

└

最近、見たこともないコードを改善するように指示されたんだ。そのコードがひどくて、完全に理解して複数の場所を変更しないと改善できなかった。どうせやるなら、まずはもっと良い状態にリファクタリングしようと思った。単に追加の機能を持たせるだけじゃなくて、物事を良くするのってすごく気持ちいいよね。

└

ほとんどの同僚は、パイプで木を50時間も切り刻むことに満足してるみたい。ちゃんと動くようにする時間なんてないんだ！この木は明日までに終わらせなきゃ！この森を切り終えたら、少しは余裕ができて、物事を整える時間ができるかもね。

└

このアプローチは、エージェントコーディングでもまだ足りないと思ってる。AIがコードを作り出すとき、「同じことを5回打ったな。これ、間違ってるかも。」って考えることがないから、変更が簡単だと思ってるんだよね…でも、構造や再利用がないと、次の変更がほぼ不可能になっちゃう。

└

友達、最初の4時間を全部使うとは思わないよ。経験上、プロセスの後半で鋭い斧が欲しくなるから、鈍くなったらね。これが比喩を台無しにするかはわからないけど。

└

ここには複雑な気持ちがあるんだ。プログラミングのときは「斧」の方が好きなんだけど（vimに必要な拡張とオプションだけ）。でも木を切るには…チェーンソーの方がずっと楽だよね。切り倒したら、木を割るためにレンタルするのもありかも。

└

ケント・ベックがクライスラーの包括的報酬制度の惨事のXPブレイントラストの一員だったってことを、定期的に思い出しておくべきだね。https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compens...

└

それがいつも、うーん、はっきりしないんだよね…時には斧を研ぐことが、WinXPでまだ木を切ろうとしている人にとっては完全に壊すことを意味するけど、自分でそのテストをできないから分からないし、古いログを漁っても2017年以降誰もやってないから、たぶん大したことじゃないんだろうね。時には、実際に切る刃がどれなのかもはっきりしなくて、別のものを長い時間研いじゃったりすることもあるよ。（本当に運が悪いと、ハンドルを研いでることもあるし。）

これには完全に同意！先月、開発環境にずっと苦しんでたけど、やっとちゃんと設定したら、すごく楽になった。ツールを修正することで得られるROIはすごいよね。週に2時間ヤクを剃るのに使ってたのが、今はゼロになった。難しいのは、その最初の時間が価値があるって自分に納得させること。ビルドスクリプトやエディタの設定を直すよりも「本当の仕事」の方が緊急に感じることが多いから。

└

https://xkcd.com/1205/

バグを直そうとする欲望が、まずツールを直さなきゃいけないことに気づくのを妨げて、バグ探しの効果を下げてしまった。ケネス・スタンリーの本「偉大さは計画できない：目的の神話」は、この現象に捧げられている。

ここで学んだ一番の教訓は、ワークフロー全体を処理すると約束するオールインワンツールは、目的に特化したものを組み合わせるよりもほぼ常に劣るってこと。コンテンツパイプラインを作るために、ノーコードの自動化プラットフォーム（Make、Airtable、n8n）を全部試したけど、実際に1日に2回以上動かす必要があると、すぐに壊れちゃうんだよね。変なレート制限、静かな失敗、状態管理の悪夢。結局、APIを直接呼び出すPythonスクリプトを書くことになった。あまり「エレガント」じゃないけど、デバッグは無限にしやすい。自分のツールを直す瞬間は、ツール自体が問題だって気づいたときだった。時には、直すことがよりシンプルで透明なものに置き換えることを意味するんだよね。

└

n8nや似たようなツールは試したことないけど、あんまり良くないんじゃないかってずっと疑ってた。n8nみたいなツールがPythonやAPI呼び出しよりも良いシナリオってあると思う？

└

だからこそ、Airflowが大好きなんだよね。

素晴らしいアドバイスだね。日々の仕事でそれを心がけてるけど、まあまあ成功してるかな。さらに良いアドバイス：今はツールを直すのをやめて、実際の問題を解決しに行こう。これも日々の仕事で心がけてるけど、成功度はかなり低いかな。

良い教訓だね！問題が将来また起こるかもしれないから、上の方の問題を直したくなるのは分かる。でも、どれだけの時間や注意、手順が必要かによるよね。時には、回避策を取ることで前に進めるけど、面白い（珍しい？）学びを逃しちゃうこともある。

だからこのコースがすごく重要なんだよね： https://missing.csail.mit.edu

ツールはエネルギーや労力を倍増させるために存在するから、その倍増を増やせばもっと多くのことができるようになるのは直感的だよね。でも実際には、ヤクシェービングと不必要な手作業を積み重ねるバランスを見つけるのが難しい。今使ってるツールを長く使うつもりなら、1%の改善が時間とともに大きな効果をもたらすから、そのバランスは多くの人が思っているよりもヤクシェービングに近いかもしれない。

これ、よくあるよね。ツールの小さな摩擦点を修正することで後で何時間も節約できることがあるけど、実際の作業を終わらせる代わりに無限に調整しちゃうのが簡単なんだよね。難しいのは、そのツールが「十分良い」状態になったときに次に進むことだよ。