ソフトウェアエンジニアリングは、コードが使われ続ける間、チームで手を入れ続けられるようにすること。プログラミングとは時間・スケール・トレードオフの3つで分かれる。
目次
変化に反応できる状態を保つ
価値のある変更が来たときに反応できる状態を保つのが本題
- 寿命は書く時点で分からず、変更は外から迫られる
- 最初の大きな更新で懲りて止めると、書き直すか据え置くかしか残らない
- Hyrum の法則：約束していない挙動にも誰かが依存する
繰り返す作業を人数に比例させない
ビルドや移行の手間が組織より速く伸びるなら、持続可能でない
- 移行は利用者に配らず、提供側がまとめてやる（バージョン管理）
- CI に載っていない使われ方は守らない（Beyonce ルール）
- 頻繁にやって1回を小さくし、問題は左へ寄せて早く見つける
決定をコストと根拠で説明する
決定は、次のコストを比べた結果として説明できなければならない
| コスト | 例 |
|---|---|
| 金銭 | お金 |
| 資源 | CPU 時間 |
| 人 | エンジニアの労力 |
| 処理 | 行動したときにかかるもの |
| 機会 | 行動しなかったときに失うもの |
| 社会 | 社会全体への影響 |
- 創造的な仕事で効くのはたいてい人のコスト
- 理由は「必須だから」か「いまの根拠で最良だから」。権威は理由にならない
- データ構造やプロトコルのように長く生きるものはフォークしない
決定は見直せるようにしておく
新しいデータで前提が崩れれば、当時正しかった決定も誤りになる
- 解決策も新しいコストを生む（分散ビルドで消費が膨らんだ）
- 方針を変えるには、決めた人が誤りを認められること
関連
- バージョン管理 — 長く生きるブランチを持たない、単一バージョン
- 廃止 — コードは資産ではなく負債。変化への対応の最後の段階
- スケールするリーダー — トレードオフを見つけて決め、見直す