Всем привет!

Наткнулась на любопытный совет в статье — устанавливать "встроенный срок годности кода":

Представьте, что каждый метод или endpoint в API живёт ограниченное время: например, 6 месяцев. Если он не используется реальными пользователями или не продлевается вручную через конфигурацию — он автоматически вычищается системой.

По моему опыту (и, думаю, по народной мудрости) — нет ничего более постоянного, чем временное. А лучший код — это код, который не написан. Но если уж костыль появился (а происходит это, когда не смогли дойти до консенсуса, не договорились об идеальном решении, создали временное и т.д.), то остальная логика может на него завязаться.

Если удаление неиспользуемых зависимостей выглядит ок (при том условии, что вы их не тащите при сборке каждый раз из интернета), то шатать так бизнес-логику кажется опасным (например, если мониторинг сбойнет, а код самоочистится из-за отсутствия необходимых данных).

Мне кажется, реализация должна быть более тонкой и со сложным анализатором.

Например, в одной запрещённой организации есть целый фрейморк по данной теме:

В фреймворке Systematic Code and Asset Removal Framework (SCARF) есть подсистема выявления и удаления мёртвого кода.

SCARF использует статический и динамический анализ программ для выявления кода, мёртвого с точки зрения как бизнеса, так и языков программирования. Этот фреймворк автоматически создаёт запросы изменений, удаляющие мёртвый код, выявленный при помощи анализа программ, таким образом, минимизируя трудозатраты разработчиков

Поэтому слепо доверять одному только "сроку годности" кода не стоит (особенно в бизнес-логике).