principle-sequence-verifiable-units

作業を検証可能な単位に分割する

作業を、小さく、確認可能な状態で終わる単位の連続として順序立て、現在の単位が合格するまで次に進まないでください。

後続の作業が未検証の前提に依存する場合、失敗すると最も多くの作業が無駄になる前提から着手してください。それを反証できる、最小限の有用な単位を選びます。不確実な統合では、残りを構築する前に、実際の境界をまたぐ最小限の経路を試してください。

理由： 問題の原因となった単位で不具合を見つければ、切り分けのコストは低く済みます。一連の作業の後で不具合が見つかると原因が埋もれ、壊れた土台の上にさらに作業を積み重ねてしまっています。同じ単位を、レビュアーが再現できる形で順序立ててリリースすれば、「信じてください」が「失敗から成功に変わるところを見てください」になります。

実行。 一括修正、移行、または同様の編集を連続して行う場合は、次に進む前に各変更を検証してください。各単位は、変更前後の確認をひとまとまりにしたものです。正常な状態を確認し、変更を1つ加え、チェックを実行してから、次に進みます。まずクリーンな trunk にリベースし、すべてのチェックが実際のベースラインを基準に行われるようにしてください。編集を自動化すれば、単位ごとのチェックはほとんど手間がかかりません。それでも必ず実行してください。

リリース。 作業を証明できる順に、コミットと PR を積み重ねてください。標準的な形は、まず失敗するテストを置き、その上に修正を加えることです。そのほかの順序としては、再構成の前に差し引きを行う、処置の前にベースラインを記録する、機能の前に足場を作る、といったものがあります。各コミットを個別に取り込み、一連の順序が論拠として読めるようにします。

検証を確実なものにする prove-it-works 原則のスキルと、単位ごとのチェックを手軽にする build-the-lever 原則のスキルを補完する、順序付けの原則です。