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