ub-mode

ub-mode

変更を求められたときは、毎回次の手順に従います。

• まず動くようにします。
• 次に正しくします。
• Practice に従います。

まず動くようにする

怠惰プロトコル

• 1つの判断は1か所に置きます。
• 問題を解決する最小限の編集を行います。

基礎から考える

• ロジックを書く前に、データの形を正しくします。
• 後続のすべてのフェーズに役立つことから先に行います。
• 同時に書き込む処理が問題になる場合は、状態を共有しません。

TDD

• コードを変更する前に、失敗するテストを書きます。
• 期待した理由で失敗することを確認します。
• テストを通す最小限の変更を行います。
• 正直なテストを書くのが現実的でない場合は、質の悪いテストを書きません。

第一原理から再設計する

• 新しい要件を古い設計に継ぎ足しません。
• 最初からその要件があったとしたら何を作っていたかを問い、よく考えたうえで、分割して提供します。

前提を問い直す

• 同じ前提を共有する2つの修正が同じゲートで失敗した場合、その前提を1文で書き、どの担当者が不均衡を抱えているかを数えます。
• 割り当てを取り除きます。
• それが済むまで、別の修正に着手しません。

追加する前に削る

• 何かを追加する前に、複雑さを取り除きます。

成果を重視した実行

• 確認できる最終状態を目指します。
• 途中で中断しても、計画されていて元に戻せるなら問題ありません。

レバーを作る

• 作業内容が一目で明らかでない場合は、それを実行するツールを作ります。
• まず1単位を手作業で行い、その単位に合うようにツールを作ります。

アーキテクチャ

ドメインをモデル化する

• 不正な状態を表現できない構造で、ドメインを表します。
• ドメイン用語の用語集を維持します。
• コードがすでに明確で局所的なら、そのままにします。

境界の規律

• データが入ってくる場所で検証します。
• 内部では、データを信頼します。
• ビジネスロジックは純粋関数に保ちます。

型システムの規律

• 不正な値を書き込めないようにします。
• 外部データは、入ってくる場所で一度だけパースします。
• コンパイラーを黙らせません。

操作を冪等にする

• 2回実行した場合も、途中でクラッシュした後に実行した場合も、同じ状態に収束します。

共有状態をシリアライズする前に分離する

• 同じ可変オブジェクトを必要としないなら、それぞれに個別のものを与えます。
• 必要とするなら、書き込みは1つだけにし、構造によってそれを強制します。

次に正しくする

根本原因を修正する

• 再現します。
• 原因を修正します。
• クラッシュを隠すだけのガードは修正ではありません。

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

• 小さな単位を1つ完了させ、確認します。
• それから次に取りかかります。

実装ではなく振る舞いをテストする

• テストでは、ユーザーと同じ方法でコードを呼び出し、そのユーザーに見える結果を確認します。
• すべての関数が何も返さなくても通るテストなら、破棄します。

Crapper

• crapper ツールを使います。
• 各関数の CRAP を 10 未満にするため、分割、テスト、またはその両方を行います。
• case 文を減らす価値があるか検討します。

Dryer

• dryer ツールを使い、ランクが 0.8 以上の重複をなくします。

Mutator

• mutator ツールを使います。
• カバーされていない部分をカバーします。
• 生き残ったものを倒します。
• デッドコードを削除します。

リファクタリング

• コードの振る舞いを固定します。
• 構造を変更します。
• 振る舞いが変わっていないことを証明します。

Practice

ログを残す

• 実行したすべての操作と、その理由を記録します。
• 完了時にそのログを報告します。

コンテキストウィンドウを守る

• メインスレッドを小さく保ちます。
• 大部分は別の場所に送り、要約を手元に残します。

Worktree のクリーンアップ

• 安全に削除できるものを見つけ、使用中のものが必要としていないことを確認してから、ディスク領域を回収します。
• 未コミットの作業は、判断が下るまでそのままにします。

コミットとプッシュ

• 順序立てて小さく、頻繁にコミットします。
• 各コミットに、理由、変更内容、検証方法を記します。
• 最後にメインラインへプッシュします。