Comments 23
чет мне подсказывает, что это хорошо спроектированная индейская национальная изба
Есть ендпоинт, который выдает админские права пользователю. Если админ не менялся год, то ендпоинт может год не использоваться.
Ну, не обязательно буквально удалять. Можно начать кидать варнинги, а там пусть разбираются - нужно оно ещё и надо дату передвинуть или ну его на фиг.
Кидать варнинги когда? При вызове кода? Но если его вызвали, значит он нужный, и его удалять не надо?
Зависит от потребностей. Если выполняется регулярная перезагрузка - можно в декораторе. Если нет - можно систему heartbeat реализовать и warning будет при не приходе сигнала.
Собственно в указанном примере с эндпоинтом выдачи админских прав. Там ведь и обратный пример возможен. Представим, что в нём нашлась архитектурная уязвимость (т.е. проблемы именно с параметрами вызова и исправить без нарушение совместимости) и ему сделали замену. А старый оставили на какое-то время, пока клиенты не исправят. Если про него забыть это будет буквально дыра в заборе, рядом с которой надёжная сейфовая дверь.
В статье попробую показать, что это не миф, а вполне реальная практика, основанная на архитектурных паттернах, «самоочищающихся» механизмов и немного наглой инженерной фантазии.
Фантазию показали. Реальную практику не показали.
# TODO: delete me after 01.01.2026
Главное, чтобы не получилось, что на CI всё хорошо, а через час в проде падения.
Выглядит как нечто такое, что можно начинать делать после того как есть реальные пользователи системы и их трекинг конкретный. Ну программисты не пользователи, а тесты покрывшие все тоже старые могут быть.
Но там и чистка поумнее должна быть, после результатов трекинга. Она должна часть выкинуть, а часть переписать-скомбинировать с ещё нужным. Так как юзеры скорее в целом покажут, что есть старое на целую область, а не на какую-то функцию. Либо наоборот это не мусор и надо подымать в топ, если это фича. Типа старый чайник нашли, он хороший, просто забыли, начинаем пользоваться, а не выкидываем. Или это новое, просто ещё никто не в курсах, вот и не пользуется. Короче чистка настоящего мусора это куда-то в анализ результатов трекинга реальных пользователей системы.
Мне кажется, что идея интересная, но на практике применить ее будет сложнее. Так как разные технологические стеки требуют разных скриптов для выпиливания. Более практический смысл можно было бы описать именно реализацию, как изолировать сервис/функцию так, чтобы можно было ее руками удалить за пару минут и не сломать код. Как вести мониторинг того, что API не используется и т.д.
Ну и любая автоматизация кода требует огромного количества тестов разного уровня, которые тоже надо как-то выпиливать, но так, чтобы они проверили работоспособность.
Раньше за временные бомбы могли и срок дать.
Удалять код - радикально, но вот отмечать что он старый и выводить это в логах можно. Правда не понятно как именно реализовать. Пока что из идей это просматривать stackTrace или логи вызовов
В $mol такая система давно используется, в бандл попадает только используемый код
Уже вижу как expires_on бесконечно продлевают каждые 90 дней лишь бы не трогать
Если смотреть по аналогии с родительскими и дочерними процессами в системе, где, например нельзя остановить один процесс, пока не остановлены его дочерние, было бы здорово визуализировать зависимости методов в коде в виде графа. +обогащать узлы такого графа информацией о том как часто это используется. Уже потом принимать решение об отказе от какой-то ветки
Пометить код устаревшим это прикольно, но это не архитектура, это просто пометка на конкретном коде, выполненная при наличии информации об этом.
Проблема устаревания кода не в том что у вещей есть срок годности, а в том что вещи меняются так сильно, что надо менять не отдельные функции, а то как устроено приложение из-за сильного изменения разноцровневой логики. А так же в том, что изменения произошли не там, где мы ожидали.
Приходит бухгалтер в январе сформировать годовой отчёт, а отчёта нет - ведь никто его год не запускал, его и вычистили со всеми зависимостями умные агенты
Есть менее радикальный, но более действенный вариант - линтеры! Включаем для неиспользуемых функций выкидывать ошибку, добавляем в CI прогон линтера. Готово - билд не пройдет, если разраб оставил за собой ненужный код. Ещё можно в прекомит хук на запуск линтеров добавить - тогда он даже закоммитить не сможет
Следующим шагом должна стать авто-давалка по шапке (за отвалившуюся функциональность)
Ни одна команда в здравом уме не будет брать риск поломки рандомного функционала в скоуп своей задачи.
А риск тут есть, т.к. описанные методы НЕ ДАЮТ ГАРАНТИЙ, а только подсказывают: не бывает 100% покрытия тестами логики, не бывает 100% надежной трассировки. Т.е. тут всегда нужен доп.анализ человеком, что это не FP. А это доп.нагрузка, причем непредсказуемая.
Я буквально лет 7 назад делал следующее: написал плагин к сонаркубу, который на чеке минорами помечал ручки, которых не было в трассировке за последние 3 месяца(не всегда точно из-за path param, но достаточно, чтобы задуматься).
Следуя этой практике, было удалено 0 ручек. Зато через пару лет был успешно удален плагин
Все ручки, какие удаляются - удаляются только на выделенных задачах по рефакторингу, когда фокус задачи и внимания именно на связанный с ручкой функционал - анализ кода, зависимостей, трассы вызовов, тестов и потом мониторинг релиза
Поэтому имхо описанные в статье метрики максимум можно использовать для обоснования включения в скоуп планирования каких-то задач по работе с техдолгом а ля "в вашем сервисе уже N ручек отмечены как неиспользуемые - пора разобраться что там происходит, пока это не стало проблемой". Но для такой постановки скрипты удаления не нужны - только анализ трасс
Код без мусора: как проектировать архитектуру, которая сама себя убирает