safe-incremental-coding

安全な段階的コーディング

モデルを選ぶ前に、ブランチを選択します。コーディネーターの作業と決定論的なコマンドは、呼び出し権限の範囲内で進めます。この方法は現在の役割で適用します。ワーカーへのディスパッチは行いません。ワーカーをディスパッチする場合は、shared/references/model-preview.md と、そこで承認されている唯一のルートスナップショットを使用します。ネストされたスキルやランナーはこれを使用し、再選択やワーカーの起動は行いません。

Dave Farley 著 The Software Developers' Guidebook のレガシー変更手法を用いて、依頼された変更に必要な既存の動作を保護します。目的は変更のしやすさです。影響を受けるコードを安全に変更できる状態にします。

リファクタリングの前に、特性テストの網を構築します。作業は依頼された変更に必要な範囲にとどめます。

網を構築する

1. 影響を受ける動作と、それを実行できる観測可能な境界を特定します。
2. 関連する境界値や失敗ケースを含む代表的な入力を使って、現在の出力や副作用を記録します。既知の欠陥を含む場合でも、既存の動作を固定します。意図的な動作変更は別のステップで行います。
3. タイムスタンプ、識別子、シード値などの変動する値を制御または正規化します。ただし、変更に関わる動作を隠さないようにします。
4. 単体テストが現在の内部構造に依存する場合は、受け入れ境界または統合境界でのテストを優先します。
5. 既存の境界では動作を確認できない場合、最初の本番コードの編集は、観測可能にするための最小限の接続点にとどめます。ビジネスロジックは変更せず、それ以降の本番コードの変更前にベースラインを記録します。
6. テストがベースラインに対して成功し、関連する動作の変更を検出できることを確認します。

成功したベースラインが保護するのは、テストで実行されるケースのみです。依頼された変更が未対応のケースに依存する場合は、そのケースのテストを追加します。

テスト容易性の障害を取り除く

網を構築したら、依頼された変更のテストを妨げているものを特定します。その障害を取り除く構造的な手法だけを使用します。

障害	変更案
使用されていないことが確認済みのコードやコメントが、影響を受ける経路を不明瞭にしている	依頼された範囲内で、その部分を削除します。テストカバレッジだけでは、コードが未使用であることの証明にはなりません。
変更に必要な複数の判断を、ひとつのブロックがまとめて扱っている	目的がわかる名前を付けた、一貫性のある処理に切り出します。
制御フローがテスト対象の動作を見えにくくしている	動作を維持しながら、影響を受ける条件分岐やフローを簡素化します。
依存関係によって、入力の制御や出力の観測ができない	範囲を絞った接続点を追加するか、関連する判断を副作用から分離します。
無関係な責務のため、焦点を絞ったテストができない	影響を受ける境界内で、それらの責務を分離します。

周囲のコードと必要なテストに適した構造を選びます。リスクを軽減できる場合は、対応済みのリファクタリングツールを使用します。

構造変更はそれぞれ動作を維持するようにします。一貫した構造変更を行うたびに、次の変更に着手する前に、影響を受ける特性テストを実行します。失敗した場合は、続行する前に原因を調査します。変更や失敗によってより広いリスクが明らかになった場合は、確認範囲を広げます。

完了と引き継ぎ

次の条件を満たした時点で、この準備を終了します。

1. 関連する既存の動作を対象とした特性テストが成功している。
2. 使用可能なテスト境界を通じて、依頼された変更を実行できる。
3. 必要な構造変更が、記録した動作を維持している。

網の構築後にこれらの条件をすでに満たしている場合は、そのまま依頼された作業に進みます。

例：「特性テストが現在の出力を保護し、依存関係の接続点によって、tdd で依頼された変更をテストできます。」

意図的な動作変更には tdd を適用します。より細かいテストが有用になった後も、保護のために特性テストを維持します。置き換え後のテストが同じ動作を確実にカバーしている場合に限り、特性テストをひとつずつ廃止します。

保護した動作、テスト容易性の変更、実行した確認、および残っている証拠の不足を報告します。

境界

1. 意図的な動作変更は、特性の把握やリファクタリングと分けてください。
2. 予期しない動作を安全に固定する前に説明が必要な場合は、diagnose を適用してください。
3. テストで保護されているコードの局所的な整理には clean-code、テストの価値には test-lens、モジュール境界の判断には architecture-lens を適用してください。
4. 書籍の原文を引用したり、再構成したりしないでください。