書籍「Tidy First?」を読みました。 印象に残った章についてメモを残しておきます。
21章 先に整頓、あとに整頓、改めて整頓、整頓しない
- 整頓しない
- このコードを二度と変更しない
- 設計の改善から学ぶことはない
- 改めて整頓する
- すぐに見返りがない大きなかたまりの整頓を抱えている
- 整頓を完了することで最終的には見返りがある
- 小出しに整頓できる
- あとに整頓する
- 将来の整頓まで待つとかえって高くつく
- 後に整頓しないとやり切った感が得られない
- 先に整頓する
- すずに見返りがある。例えば、理解が向上したり、振る舞いを安く変更できる
- 何をどのように整頓すれば良いか分かっている
22章 要素を役立つように関係づける
- ソフトウェア設計とは、「要素を役立つように関係づけること」
- ソフトウェア設計者が行うことは、
- 要素の作成と削除
- 関係性の作成と削除
- 関係性が生み出す利益の増加
- 設計する際の観点として活用ができそう
24章 経済性：時間価値とオプショナリティ
- ソフトウェア設計は「すぐに使う/あとで使う」と「モノではなくオプションを作る」という要求を調和させなければいけない
25章 明日の1ドルより今日の1ドル
- 先に実装を完了させてしまってから、整頓をする方がいい
- お金を生む実装を先に入れることでより早く資金が手に入る。資金はより早く手に入る方が価値が高い
- スプリントレビューに間に合わせられるように、一旦マージすることがあるが、この理論に近い認識
26章 オプション
- 良い設計で、良いオプションとは
- 振る舞いの変更の価値が変動する可能性が高ければ高いほど良い
- 開発を長く続けられる程よい
- 将来もっと安く開発できるに越したことはないが、価値に占める割合は少ない
- オプションを作るために行う設計は少なければ少ないほど良い
27章 オプション vs キャッシュフロー
cost(now: 整頓) + cost(future: 機能開発) < cost(future: 整頓) + cost(now: 機能開発)- → 整頓を先にする
cost(now: 整頓) + cost(future: 機能開発) > cost(future: 整頓) + cost(now: 機能開発)- → 機能開発を先にして目先の利益を確保する。近日中に整頓する
cost(now:整頓) + cost(future:機能開発) >>> cost(now:機能開発)- → 機能開発を先にして目先の利益を確保する。整頓はしなくていい。
- チームで技術的負債をどう扱うのか判断基準にできそう
28章 可逆的な構造変更
- 不可逆な構造変更がある場合は、可逆的な構造変更になるように整頓してから取り組むこと
29章 結合
- 変更コストを考慮する上で結合がどうなっているのか注意深く確認する必要がある
- １対N
- カスケーディング
- 上記の結合状態においては、変更コストが膨れ上がりやすいいので覚えておくと良い
30章 コンスタンチンの等価性
- ソフトウェア開発コストの70%はメンテナンスに費やされている
- メンテナンスコストを高くしているのは、つまるところ「結合」である
33章 結論
- まとめると「先に整頓するべきか？」という問いに対する判断軸はいかになる
- コスト
- 整頓によってコストが小さくなったり、コストが発生する時間が遅くなったり、コストが発生する可能性が低くなったりするか？
- 収益
- 整頓によって収益が大きくなったり、収益を手にする時期が早くなったり、収益を産む可能性が高くなったりするか？
- 結合
- 整頓によってより少ない要素の変更になるか？
- 凝集
- 整頓によって変更が必要な要素が、より小さく、もっと集中した範囲になるか？
- コスト