principle-build-the-lever

レバーを作る

作業が単純でないときは、手作業で済ませるのではなく、それを実行するツールを作りましょう。

理由： 2つのメリットがあります。処理速度：codemod、ジェネレーター、スクリプトを使えば、毎回同じ方法で作業でき、無料で何度でも実行できます。信頼性：ツールは、レビュアーが読んで再実行し、作業を確認できる成果物です。手作業で行った変更を再検証するには、同じ作業をもう一度やり直すしかありません。決定論的なスクリプトがあれば、「信じてください」を「これを実行してください」に変えられます。

パターン： まずレバーを作ることを選びましょう。作業が単純で、ひと目で確認できる明白な編集が2、3か所だけの場合に限り、省略します。

• まず最初の1単位を手作業で行って手順を把握し、それからツールを作ります。その単位にツールを再実行し、手作業で行った結果との差分を取って、正しさを証明します。安全に再実行できるレバーにしましょう。
• 編集にはcodemodまたはスクリプト、繰り返し使うファイルにはジェネレーター、分析にはダンプからSQLiteへのクエリ、検証には再実行可能なチェックを使います。
• 決定論的なレバーは、作業を分散するより優れています。ツールで全単位を一度に処理できるなら、自分で実行しましょう。スクリプトでできることを手作業で行わせるために、作業を委任しないでください。
• サブエージェントに作業を分担させる場合は、全員が参照するスキルとしてレバーを記述します。手順、検証の要件、変更禁止の範囲を1つの成果物にまとめます。委任先の書き込み範囲外に置き、検証の要件を勝手に編集できないようにします。
• この原則を適用すると、ファイルが作られます。そのファイルに言及しているのに、差分にcodemod、スクリプト、ジェネレーター、委任先向けのスキルがないなら、原則を適用していません。
• 作業がセッション終了後も続く場合は、レバーをコミットしましょう。

バランス： 判断基準は繰り返しの有無ではなく、作業の単純さです。1回限りの作業でも、検証可能にするためのレバーなら作る価値があります。Laziness Protocolに従い、作業を実行または証明する最小のスクリプトを作り、フレームワークは作らないでください。

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