Skills

どの層も作り込む前に、全層を貫いて動く細い経路を一本作ること——一度も実行されていない統合は推測にすぎません。

実装の後に書かれた基準は、その実装を記述しているだけです。まず失敗するチェックを書き、それが失敗するのを確認してから作ってください。

保存には成功するのに再起動まで何も変わらない設定は、失敗する設定より悪いものです。いつ効くのかを明示し、それを読み取り箇所から導いてください。

実際のウィンドウより低く設定した予算に対して消費し、毎ステップ再送信するツールスキーマを数に入れてください——それは圧縮では到達できない下限です。

フィードバック用の変数を上書きするリトライループは、3回目の試行に2回目の失敗しか見せません——だから1回目がすでに試したパッチを導き直してしまいます。

シグネチャは記憶からではなく、インストール済みのバージョンから取ること——もっともらしい API は、実行するまで本物と見分けがつきません。

他のファイルから手で写したものは、ちょうど一度だけ正しいものです。生成できるなら生成し、写しが古くなったらビルドを失敗させてください。

クラッシュするジェネレーターは失敗したと教えてくれますが、もっともらしい出力を返すものは何も教えてくれません。実行されたことではなく、何を見つけたかをテストしてください。

失敗するところを一度も見ていないリグレッションテストは、推測にすぎません。commit する前にコードを壊し直し、赤くなるのを確認してください。

診断とは、自分が動かしていないマシンについての主張です。まず短いコマンド一つで失敗を再現してください——とりわけ、その診断が他人から届いたものである場合には。

プロジェクトの検証コマンドは、そのまま実行すること——同じ範囲、同じフラグで。その場で組み立てたほぼ同じ変種は、両方向に嘘をつきます。

テストの中で手組みしたクラスは、そのクラスが動くことを証明するだけで、そこに何かが到達することは証明しません——本番が実際に通る経路をカバーしてください。

チェックが誤った対象で発火したとき、その修正はチェックを弱めます。同じコミットで誤検知をテストとして固定してください。さもないとルールは静かに擦り減ります。

タスクを完了と報告する前に、完了していなければ失敗するはずの検査を実行してください。説明は修正ではありません。

分母とその内訳を欠いた比率は、どの桁も真実のまま誤解を招きます——n を示し、分子のうちどれだけが既知のノイズなのかを述べてください。

システムの一部から作られたランキングは、システム全体のランキングとして読まれます——調査範囲と除外対象は、結果の後ではなく隣に書いてください。

自分の測定結果ふたつが、どんな仕組みでも生じえない幅で食い違うなら、欠陥は測定器の側にあります。その上に理論を組み立てる前に、ハーネスを監査してください。

数値とその但し書きは、ひとつの成果物でなければなりません。段落がふたつあれば離れていきますが、コンポーネントひとつなら離れようがありません。

失敗した実験も公表し、置き換えられた結果は手を加えずに残し、有意性を求めて振り直さないでください。バイアスは数値ではなく、選択にあります。

守る対象より後から追加したチェックは、リリースのために誰かが切るチェックです。まだ止めるものが何もないうちに閉じておいてください。

チェック対象を列挙するゲートはフェイルオープンします——誰も追加し忘れたサイトこそが壊れるのです。代わりに免除対象を、一つずつ理由を書き添えて列挙すれば、デフォルトはフェイルになります。

空の画面・タブ・カテゴリは、製品が守っていない約束です。中身が入るまで隠すか、まだ作らないでください。

対象となる操作の後に置かれた注意書きは、読み手がすでに決めた後に届きます。上に置き、重要な場面では消せないようにしてください。