principle-build-the-lever

レバーを作る

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

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

まずはレバーを作ることを基本としましょう。タスクが単純で、一目でわかる明白な編集が2、3か所だけの場合に限り、省略します。

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

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

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