principle-build-the-lever

レバーを作る

作業が単純でない場合は、手作業で進めるのではなく、それを実行するツールを作ります。

codemod、ジェネレーター、スクリプトを使えば、毎回同じ方法で作業でき、無料で再実行できます。ツールは、レビュアーが読んで再実行し、作業を確認できる成果物です。手作業による変更を再確認するには、同じ作業をやり直すしかありません。決定論的なスクリプトを使えば、「信じてください」を「これを実行してください」に変えられます。

まずはレバーを作ることを基本とします。作業が単純で、ひと目でわかる明らかな編集が数か所あるだけの場合に限り、省略します。

• 最初の1単位は手作業で行って手順を把握し、その後ツールを作ります。その1単位にツールを再実行し、手作業で行った結果との差分を確認して、ツールの有効性を証明します。安全に再実行できるレバーにしてください。
• 比較ツールでは、比較対象とする各出力に既知の不正な変更を1つずつ仕込み、ツールが不一致を報告することを確認します。たとえば、合計を変更し、その後で合計は維持したまま項目の割り当てを入れ替えます。必要な入力が不足している場合、ツールは一致と判定せず、処理を拒否するか、結果が確定できないと報告しなければなりません。これらの検証用データは実験と一緒に保管し、結果を信頼する前に再実行してください。
• 編集にはcodemodまたはスクリプト、反復的なファイルにはジェネレーター、分析にはダンプデータをSQLiteに取り込んでクエリする手法、検証には再実行可能なチェックを使います。
• 決定論的なレバーは、作業の分散よりも優れています。ツールで全単位を一度に処理できるなら、自分で実行してください。スクリプトでできることを手作業で適用するために、作業を委任しないでください。
• サブエージェントに作業を分担するときは、全員が読むスキルとしてレバーを記述します。手順、検証の契約、変更禁止の範囲を1つの成果物にまとめてください。委任先が契約をひそかに編集できないよう、その成果物は委任先の書き込み範囲外に置きます。
• この原則を適用すると、ファイルが作られます。それを引用したにもかかわらず、差分にcodemod、スクリプト、ジェネレーター、または委任用スキルがなければ、原則を適用したことにはなりません。
• 作業がセッション終了後も続く場合は、レバーをコミットします。

基準となるのは、反復性ではなく、作業が単純かどうかです。1回限りの作業でも、確認可能にするためのレバーなら作る価値があります。Laziness Protocolに従い、フレームワークではなく、作業を実行または証明する最小限のスクリプトを作ってください。

Encode Lessons in Structureとは異なり、そちらは繰り返し使う指示を永続的なガードレールにするものです。こちらは、目の前の作業の処理速度とレビューのしやすさを重視します。検証自体をスクリプト化する方法については、Prove It Worksを参照してください。