廃止

『Google のソフトウェアエンジニアリング』第15章を読んで理解した内容を、自分の言葉で書き直したもの。本文の引用ではない。節番号は原典を引き直すときの手がかり。

出発点

コードは資産ではなく債務。 コストの大半は、書いた時点ではなく稼働期間全体の保守で発生する。

だから評価すべきは書いた量ではなく、コード単位あたりでどれだけの機能を提供できているか。同じ機能を保つなら、コードは単純であるほどよい。目指すのは「もっと書いてもっと機能を得る」ことではなく、要らないコードとシステムを取り除くこと。(§15.1)

古いシステムは保守の手間と秘伝の専門知識を要求し続け、周囲のエコシステムから外れていくほど必要な作業が増える。置き換え先と並列させたまま無期限にぎこちなく動かし続けるくらいなら、 停止させる方に労力を使った方がましなことが多い。

旧システムとの互換性を維持し続けることが、新しい側の発展を阻害するという副作用もある。

ただし条件がある。下手に廃止すると、放置するよりコストが高くつくことがある。

停止と撤去がやりやすいように、作っている最中から廃止を設計に織り込む。

問うべきこと。

置き換え先になりうるものへ移行するのは容易か
システムを一部ずつ、段階的に置き換えていけるか

そして原則として、組織が予期される存続期間中サポートすることをコミットしないプロジェクトは、始めない。

警告を出しすぎるとアラート疲労を起こして誰も見なくなる。出す警告は必ず2つの性質を満たす。

性質	意味
行動可能性	ユーザーがその警告に対して関連する行動を実際に取れるか
関連性	ユーザーがその行動を実際に行うタイミングで表示されるか

古いシンボルへの参照が全部消えたかどうかは、グローバルなテストスイートを判定の拠りどころにする。人間の記憶や grep ではなく、テストが通ることを完了の定義にする。