principle-sequence-verifiable-units

検証可能な単位に分けて作業を順序立てる

作業は小さな単位の連続として順序立て、各単位の最後に確認できる状態にし、現在の単位が合格するまで次に進まないようにします。同じ規律は、実行と納品という二つの段階で機能します。

理由： 問題の原因となった単位で不具合を見つければ、特定にかかるコストは低く済みます。まとめて作業した後に見つかった不具合は埋もれてしまい、壊れた土台の上にさらに作り込んでしまっています。同じ単位を、レビュー担当者が再現できる納品物に順序立てることで、「信じてください」が「実際に失敗してから成功するところをご覧ください」に変わります。

実行。 一括変更、移行、その他の類似した編集を繰り返す作業では、次に進む前に変更ごとに検証します。編集をまとめて行い、最後に一度だけ検証するのは避けてください。各単位は、正常な状態を確認し、一つ変更し、チェックを実行してから次に進む、変更前後の一組です。まずクリーンな trunk にリベースし、すべてのチェックが実際のベースラインを基準に測定されるようにします。編集を行う仕組みがある場合、単位ごとのチェックはほとんど手間がかかりません。それでも必ず実行してください。

納品。 作業の妥当性を示す順にコミットや PR を積み重ねます。標準的な形は、まず失敗するテストを置き、その上に修正を重ねることです。最初の単位でバグが実在することを示し（赤）、次の単位で解決したことを示すため（緑）、レビュー担当者は問題とその証明の両方を確認できます。ほかの順序の例としては、変更前の削除、その後に再構成する形や、処置の前にベースラインを記録する形、機能の前に土台を用意する形があります。各コミットはそれぞれ単独で成立し、全体の流れが論拠として読めるようにします。

パターン：

• チェックを終えられる最小の単位を選びます。編集とそれに対するテスト、または単独で成立するコミットなどです。
• 次に進む前に検証します。単位ごとに赤から緑へ進め、最後の一括検証に先送りしないでください。
• 実行中の自分にとっても、コミットの積み重ねを読むレビュー担当者にとっても、順序そのものが信頼につながるよう、単位を並べます。

これは、各チェックが実際に機能する状態を保つ 動作を証明する 原則のスキルと、単位ごとのチェックを手軽にする 仕組みを作る 原則のスキルを、順序立ての面から補完するものです。