リグレッション管理
#設計原則
プログラムの一部分を変更したことで、ほかの箇所に不具合が出ていないかの管理
リグレッションテストとかよく言う
「回帰テスト」「退行テスト」とも呼ばれる
プログラムの修正後にこれらのテストをもう一度行って不具合がないかを検証したりする
これやってないと関係のない別の機能が壊れたりする
これをおざなりにすると機能追加や改修が困難になる
想定外のdiffが生じてレビューが難しい
デッドコードが残り続ける
認知負荷が高まる
リファクタリングの足かせとなる
エンジニアの生産性がどんどん下がる
見積もりが難しくなる
チーム全体がうまく回らなくなる
QA Teamがあると、「別工程で品質担保するので」と甘えてしまいがちだが、本来はエンジニア自身で管理できるようになるべき
高凝集、結合度などの普遍的な知識をつけておく
ユースケースとリソースを区別する
モジュールのインタフェースを不必要に広くしない (Deep Module)
分割統治する
→QAは特権であるべきではない
koushisa.iconは設計に迷ったときはどうやったら捨てやすいかという観点でよく考える
犠牲的アーキテクチャ
何かを得る時は同時にどうやって捨てるか考える
意識しておくと自然と影響範囲が閉じた設計となりやすい