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