Когда вы начинаете сносно разбираться в области бд, кода и архитектуры, то вы уже не аналитик. 🤷‍♀️😄
Вы - junior solution architect как минимум.

Обычному аналитику в рефакторинге делать нечего. Только собрать бизнес-требования, фт от экспертов, нфт от экспертов, структурировать и забыть.

В этом случае вообще пофиг, делаете вы новое приложение или рефакторите старое.

Я в свое время успешно поработала в разработке небольшого проекта, и отрефакторила проект под себя. Вывела в пром эксплуатацию. Но! Хватило одного раза)))) после этого понимаю, почему разработка бежит от рефакторинга как от огня - обычно проще новый модуль написать и спланировать переход на него.

А мне нравится, но это уже больше похоже на Стокгольмский синдром.

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

Что? Поясните, пожалуйста, как поняли мое сообщение и при чем тут стокгольмский синдром)

Вполне можно.  
Ас ис:
Изучаешь вводные требования.
Изучаешь апи.
Изучаешь бд.
Формируешь карту архитектуры с кодом как серым ящиком.

Ту би:
Определяешь места рефакторинга(затыки) по вводным.
Определяешь замусоренные и ненормализованные объекты.
Получаешь на вход тех стек и архитектуру.
Прописываешь интерфейс если надо.
Прописываешь запросы к сервису и запросы к бд.
Просишь разработчика определить несостыковки.
Достыковываешь нужные данные.
Гоняешь периодически демо и ходишь по процессу со стейкхолдерами.
Пускаешь в тестовой среде и тестируешь.
Канарейки на прод.
Потом полная выкладка.

Вот и все.

0 минут в коде. Только сиквел обычно. И то не обязательно.

Когда тебя постоянно просят рефакторить приложения и бд, то со временем это становится простым делом и уже не кажется плохим.
Но это не так, ты просто перестал ощущать, что рефакторинг - это боль, боль стала смыслом твоей жизни. Лол.

😱😱 рефакторинг,как правило,не только объектной модели касается, но также и всех неоптимально организованных вызовов (не только ф Аpi  но также внутренностей фронта и Бека иногда)+ ошибок при архитектурном проектировании - например, неграмотном применении инструментов. Знаменитый спагетти-код ,например, не поправишь описанными выше способами

Спасибо за пояснение, я приняла на свой счёт. Мне моего одного раза хватило для понимания, что это инфернальное зло 👹

Он просто требовательный к опыту и времени, не более.

Да всё там легко если опыт есть.

Ты при проектировании и бизнес-ошибки ведь прописываешь, как же без них.
Разработчика можно попросить сделать отчёт по всем легаси ошибкам, которые есть в коде - это не сложно.

Перемещение между фронтом и беком - это просто интеграция между серыми коробками с API.
Между разными приложениями - та же песня: две серые коробки, апишка между.

Про спагетти-код. Аналитик никогда не рефакторит код так-то.

Его задача загнать непосредственно код в рамки таким образом, чтобы КАКОЙ-БЫ-ТАМ код ни был написан, его было бы легко заменить.
Сперва надо выделить единицы рефакторинга, для этого хорошо подходят юз-кейсы или стори.
Надо сделать их независимыми от остального кода.
Постепенно можно научиться выделять функции в отдельных юзкейсах, которые переиспользуются в разных местах в отдельную функцию со своей страничкой в вики и своим серым ящиком кода в приложении.

Можно переделывать сразу всё, либо потихоньку выделять понятные вещи и рефакторить.
Рефакторинг может быть частичный, где у тебя 90% остаётся в спагетти, а 10% ты выделяешь рефакторишь.
Если рефакторится объектная модель бд, то тут единица будет больше и будет включать в себя несколько единиц (юз-кейсов). Тут лучше менять методы на беке для единой точки доступа к данным.
Если рефакторится архитектура, то это самый большой кусок, где нужно будет делить, зачастую, по единицам домена.

Важно сделать грамотно БД + сервис предоставления данных. И бить по рукам всем, кто в БД полезет не через существующий метод или его обновление, чтобы всегда можно было управлять данными и архитектурой за API в сторону БД, без необходимости оглядываться на возможных других пользователей объектов базы данных.

Так, мне кажется, что пора за эту информацию брать деньги. 🙃😂👺👿

Единица кода не равна юзкейсу, как правило. Хотелось бы, но нет. Как правило, это либо программный модуль либо сервис предоставляющий функции для нескольких кейсов, объединенных схожей бизнес логикой. На всякий случай -, говоря про рефакторинг, я имею в виду именно рефакторинг программного кода.

Вы спагетти начали с самого начала делать. Не надо так.
Один юзкейс - один источник изменений, один пользователь (дратути SOLID).
Хотите предоставлять функции разным потребителям - делайте разный апи (версии, названия), добавляйте наследование в код в общих местах.

Это всё происходит потому, что есть бизнес-требования, потом "магия", а потом бд (бд тоже может быть "магией"). И нет понимания принципов проектирования.
Стоит почитать "Чистую архитектуру" первые 104 страницы.

Потом меньше грабель собирать будете.

Речь то не обо мне и моем проекте 😱.