エントロピーの縮小のためのリファクタリング
>Shrink
from ビヨンド ソフトウェア アーキテクチャ p15より引用
> コードベースに入り込んでしまった経緯はどうあれ、その妥協を取り除かない限りコードベースの品質は低下するだろう。プロダクトを出荷したあとで、ソースコードを改善するため十分な時間を割かなければならない。私はこれを「エントロピーの縮小」と呼んでいる。
本開発フェーズでも、スケジュールに追われて妥協するケースはいくらでもある。その妥協を技術的負債と呼び、放っておくとエントロピーが拡大するように負債も広がっていく
リリースタイミングや、フェーズの切り替わりのタイミングなどでリファクタリングを行ってエントロピーの縮小をしたほうが、中長期的に見て良い効果を得られる（短期的なプロジェクトだとやらなくてもいいけど）
アドレナリンジャンキーなチームだと、目先のスケジュールや見せかけの成果物が重要視され、エントロピーの増大しまくって最終フェーズに近づくほど辛い目にある