Рефакторинг после чат-прототипа: простой чеклист, как привести имена, папки, состояние и API в порядок и убрать дубли, сохранив скорость.
Чат-прототипы хороши тем, что быстро превращают идею в работающий экран: можно за вечер собрать форму, список и пару интеграций. Но скорость часто покупается за счет аккуратности. Решения принимаются по ходу дела, а код растет как получится.
Обычно страдает то, что заметно не сразу: согласованность имен, границы между слоями, повторяющиеся куски и разный стиль в разных файлах. В итоге вроде бы все работает, но любое новое требование начинает раскачивать проект.
Понять, что пора наводить порядок, помогают простые симптомы:
Поддерживаемый код - это не идеальная архитектура. Это код, который понятен следующему человеку (и вам через месяц), где изменения предсказуемы, а ошибки локализуются. В таком проекте легко найти, где живут запросы к API, где логика домена, где просто отображение, и почему принято именно такое решение.
Момент для уборки лучше выбирать не когда все горит, а когда вы уже подтвердили ценность функции: основные пользовательские сценарии работают, структура данных более-менее устоялась, и стало ясно, что продукт будет развиваться. Практичный ориентир: как только вы дважды правили одно и то же место по похожей причине, выделите небольшой слот (например, 1-2 дня) и зафиксируйте правила.
Если прототип собирали в TakProsto, удобно запланировать отдельный мини-спринт сразу после демо: сохранить рабочее состояние снапшотом, а затем спокойно выровнять имена, файлы и границы API, не останавливая развитие фич.
Быстрый чат-прототип часто работает, но держится на договоренностях в голове. Рефакторинг лучше делать короткими спринтами: цель не переписать все, а привести проект к понятным правилам, чтобы дальше добавлять фичи без сюрпризов.
Сначала зафиксируйте текущее поведение. Выберите 5-7 ключевых сценариев (логин, список, создание, оплата, поиск) и запишите ожидаемый результат простыми фразами. Если есть время, добавьте по одному простому тесту на сценарий, но без фанатизма.
Дальше разрежьте проект по ответственности. Решите, где живет доменная логика, где UI, где работа с сетью, а где хранение состояния. После этого легче увидеть, что можно выкинуть, а что нужно сохранить.
Обычно порядок работ укладывается в 1-2 спринта:
После удаления дублей вернитесь к состоянию. Договоритесь, где именно оно хранится (локально в компоненте, в общем сторе, на сервере) и в каких местах его можно менять. Это снижает количество магических обновлений UI.
Короткий пример: в кабинете на React часто встречается три разных способа показывать загрузку и ошибки. За один вечер можно вынести единый обработчик ошибок в слой API, оставить в компонентах только отображение и договориться, что все запросы идут через один клиент.
В конце добавьте 3-5 правил на будущее в README проекта и придерживайтесь их. Если вы собирали прототип в TakProsto и потом экспортировали код, эти правила особенно помогают не потерять скорость при дальнейшем развитии.
Имена - это навигация по проекту. После быстрого прототипа в чате часто остаются следы: data2, temp, newUser, modalStuff. Начать проще всего именно с них: хорошие имена быстро снижают число ошибок и ускоряют чтение кода.
Плохие имена легко узнать. Они расплывчатые (непонятно, что внутри), противоречат реальности (файл называется user, а хранит настройки) или смешивают уровни (в UI-компоненте лежит бизнес-логика и сетевые запросы).
Несколько правил, которые дают максимум эффекта:
data2, а userProfile, invoiceDraft, authToken.subscriptionPlan, а не pricingBlockData.saveProfile, createInvoice, fetchOrders.loadOrders, чем loadOrdersFromApiV2 (версия и источник - в реализации).OrdersPage рисует, useOrders управляет состоянием, ordersApi ходит в сеть.Для React держите простую схему: компоненты с заглавной буквы (UserCard), страницы с суффиксом Page (SettingsPage), хуки с use (useAuth), утилиты как существительные (formatMoney). Тогда поиск по проекту становится предсказуемым.
Полезный прием - мини-словарь проекта. Это 10-20 ключевых терминов, которые вы фиксируете один раз и дальше используете одинаково. Например, заранее выберите, как называете сущность и не плодите варианты: user или customer, order или purchase, plan или tariff, profile или account.
Когда термины закреплены, пропадает часть дублей: два разработчика уже не создают параллельно clientInfo и customerProfile про одно и то же.
После чат-прототипа папки часто растут как попало: рядом лежат страницы, куски бизнес-логики, запросы к API и случайные helpers. Чтобы наведение порядка не превратилось в бесконечную перекладку файлов, задайте простые правила и держитесь их.
Хороший минимум для фронта (React) выглядит так:
src/
app/ (инициализация, роутинг, провайдеры)
pages/ (сборка экранов из фич)
features/ (фичи: логика + UI для конкретного сценария)
entities/ (доменные сущности: User, Order, Project)
shared/ (общие UI, утилиты, api-клиент, типы)
Ключевое правило: доменная логика живет в features/ и entities/, а не в pages/ и не внутри красивых компонентов. Компонент в идеале только отображает, а решения (валидация, расчеты, преобразования данных) лежат рядом с фичей или сущностью и тестируются отдельно.
Чтобы фронт и бэкенд (Go) меньше спорили, полезно заранее разделить модули: держать backend/ (Go) с понятными слоями (internal/handlers, internal/services, internal/repo, internal/domain), frontend/ (React) по схеме выше и отдельный contracts/ под схемы/DTO и правила версионирования.
Типы и контракты данных лучше хранить в одном месте и импортировать оттуда, а не копировать в каждом модуле. Если тип меняется, меняется один источник, а не пять почти одинаковых интерфейсов.
С папкой utils договоритесь жестко: в shared/ оставляйте только действительно общее (формат даты, работа с money, безопасный storage). Все, что относится к конкретной сущности или сценарию, уезжает в entities/<name>/lib или features/<name>/lib. Иначе utils быстро становится свалкой.
После быстрого прототипа состояние часто превращается в набор случайных переменных. Начните с простого: найдите места, где приложение не может договориться само с собой, и сведите все к понятным правилам.
Плохие сигналы обычно одинаковые: магические флаги вроде isOk, mode2, needReload; длинные цепочки пропсов через 4-5 компонентов; обновления, которые то срабатывают, то нет. Еще один признак: чтобы понять, почему кнопка стала неактивной, нужно открыть три файла и два хука.
Хорошая граница такая: локальным оставляйте то, что живет только внутри одного экрана и не нужно никому еще (открыто ли модальное окно, выбран ли таб, текст поиска до нажатия Enter). Выше, в общий слой, выносите то, что влияет на несколько частей UI или должно переживать переходы: текущий пользователь, выбранная организация, активные фильтры списка, черновики форм.
Выберите источник правды для каждого типа данных. Сами данные, статус загрузки и ошибка должны быть связаны и храниться вместе. Если список заказов живет в одном месте, а isLoading в другом, вы получите гонки и мигание интерфейса.
Логику запросов и кеширования держите вне компонентов, чтобы UI оставался простым: компонент показывает состояние (загрузка, ошибка, данные), а не решает, когда и как дергать API. На практике это часто отдельные хуки или слой data-access.
Мини-правила, которые заметно снижают хаос:
Пример: в кабинете быстро добавили фильтр по статусу, пагинацию и кнопку Обновить. Если фильтр хранится в компоненте таблицы, страница в родителе, а загрузка в третьем месте, таблица будет прыгать. Сведите фильтры и пагинацию в один объект состояния, загрузку привяжите к запросу, а UI оставьте тупым: он только меняет фильтр и отображает результат.
После быстрого прототипа часто кажется, что все уже работает. Но при первом же изменении выясняется: фронт ожидает одно, бэк отдает другое, а правки превращаются в угадайку. Здесь помогают простые границы и договоренности, чтобы дальше менять систему спокойно.
Думайте не про файлы, а про ответственность слоев. Тогда код легче читать и тестировать, а ошибки быстрее находить.
Так вы перестаете таскать запросы и преобразования прямо в компонентах, и спор между фронтом и бэком уменьшается.
Контракт API - это договор: какие поля, типы и статусы вы передаете друг другу, какие ошибки возможны, какие значения считаются валидными. Его можно оформить как краткое описание (или схему) и держать рядом с кодом.
Отдельно держите DTO (то, что приходит и уходит по сети) и внутренние модели. DTO может быть неудобным, но стабильным. Внутренние структуры можно менять под нужды приложения. Между ними нужен явный маппинг, а не прямо используем ответ как есть.
По изменениям правило простое: добавления обычно безопасны (новое поле, новый статус с дефолтом), а ломающие правки требуют версии или миграционного периода. Например, сначала бэк начинает отдавать оба поля (old и new), фронт переезжает, потом старое удаляется.
Чаще всего разрывы возникают из-за дат и времени (строка vs timestamp, часовые пояса), статусов (разные названия, отсутствие значения unknown), ошибок (то 400 с текстом, то 200 с error внутри), пагинации (page/limit vs cursor, разные поля total) и пустых значений (null, пустая строка, отсутствие поля).
Если собираете проект в TakProsto, такие договоренности удобно фиксировать заранее в planning mode: тогда при генерации новых экранов и методов меньше сюрпризов.
После чат-прототипа дубли появляются почти всегда: одну и ту же проверку пишут в трех формах, одинаковый маппинг ответа сервера копируют в разные компоненты, а запросы к API размножаются по экрану. Самое выгодное по времени - найти эти повторы и убрать их так, чтобы код стал проще, а не умнее.
Для быстрого поиска пройдитесь по проекту с вопросом: где я уже видел этот кусок? Часто это видно по одинаковым именам полей, одинаковым сообщениям ошибок и повторяющимся условным блокам.
Обычно дубли встречаются в проверках, маппингах (date/price/status в UI-форматы), запросах (параметры, заголовки, обработка ошибок, повторная авторизация) и вычислениях (суммы, скидки, фильтры, сортировки, сборка payload).
Дальше выберите самый простой из трех способов, и только если он реально уменьшает код.
Хелпер (чистая функция) хорош для форматирования, вычислений и простых преобразований данных. Сервис подходит для работы с API: один клиент, единая обработка ошибок, единые типы/контракты. Общий компонент оправдан, когда повторяется разметка и поведение (например, одинаковый блок пустое состояние или единый виджет загрузки).
Чтобы не получить слишком умный общий код, держите его узким: одна задача, понятное имя, минимум настроек. Если хелпер принимает 8 параметров и флаги типа enableAdvancedMode, скорее всего, вы склеили разные случаи, и дальше будет больно менять.
Правила валидации, форматирования и вычислений лучше держать ближе к домену. Например, проверки полей профиля пусть лежат рядом с модулем профиля, а не в глобальной папке utils.
Снимайте дубли по одному сценарию: сначала перенесите логику, затем подключите ее в одном месте, проверьте, и только потом вычищайте копии.
Пример: в React-кабинете статус заказа форматируется в трех местах. Вынесите форматирование в функцию formatOrderStatus, подключите ее сначала в списке, затем в карточке, затем в письме/уведомлении. Так вы не ломаете все сразу и быстро видите, где логика на самом деле различалась.
Самая частая ошибка - желание переписать с нуля. Звучит красиво, но обычно вы теряете работающие куски, получаете новый набор багов и растягиваете сроки. Лучше идти маленькими шагами: один модуль, одна граница, один вид дублирования за раз.
Вторая ловушка - незаметно поменять поведение вместе с причесыванием кода. Вынесли логику в хук, переименовали поля, заодно немного поправили условия, и вот уже расчеты или доступы работают иначе. Перед изменениями зафиксируйте текущее поведение: хотя бы парой ручных сценариев или минимальными тестами на критичные функции.
Переименование тоже может ломать. Если вы меняете названия сущностей, но не обновляете контракт данных, комментарии у типов, примеры в моках и ошибки в логах, команда продолжает думать старыми терминами. В итоге userId на фронте и client_id на бэке снова начинают спорить.
Еще один популярный провал - слишком глубокая структура папок. Когда файлы прячутся на 6-7 уровней, люди начинают дублировать код, потому что быстрее написать заново, чем найти. Держите структуру плоской, а группировку делайте по смыслу, а не по типу файла.
И аккуратнее с общими утилитами. Если helper тянет половину проекта, любое изменение становится рискованным.
Проверьте себя коротко:
Перед тем как нажать релиз, сделайте быстрый проход по проекту. Это не большой рефакторинг, а страховка от мелких вещей, которые потом превращаются в баги и лишние часы.
Ниже мини-чек для ситуации, когда вы уже навели порядок и хотите убедиться, что код читается и ведет себя предсказуемо.
tmp, final2, newNew. По названию понятно, что делает функция и к какому домену относится компонент.components в разных местах без правила.Возьмите один пользовательский путь, например: вход -> список -> карточка -> сохранить. Пройдите его глазами по коду и в приложении.
Если в одном месте состояние хранится в компоненте, в другом в глобальном сторе, а в третьем в URL, это почти всегда даст расхождения. Лучше выбрать один главный источник и явно синхронизировать остальные.
Короткая эвристика: если вы не можете за 30 секунд найти, где меняется поле формы и где уходит запрос, значит точки входа и границы слоев еще размыты.
Если вы собираете приложение в TakProsto, удобно сделать снимок перед правками и после, чтобы быстро откатиться, если минутный фикс неожиданно сломает поток.
Личный кабинет собрали за 2-3 дня в формате чата: страница профиля, список заказов, настройки. Через неделю добавили оплаты, роли (пользователь, менеджер) и историю операций. Функции росли быстро, а код менялся кусками: сегодня важно показать кнопку, завтра срочно добавить скидку и новый статус.
Первые проблемы обычно не про баги, а про путаницу. Одну и ту же сущность называли по-разному: user, client, account. В API то приходил plan, то tariff. В итоге фронт начинал угадывать, что имелось в виду, а разработчики спорили, где истина. Параллельно логика скидок оказалась сразу в трех местах: на фронте в компоненте оплаты, в утилите расчета суммы и на бэке при создании счета.
Наведение порядка пошло по простому сценарию. Сначала сделали переименования: выбрали один термин на домен (например, тариф и роль) и прошлись по коду поиском. Затем вынесли расчет скидки в одно место и договорились, кто считает финальную сумму: бэкенд. На фронте оставили только отображение и сообщения об ошибках.
Дальше стабилизировали API-ответы: единые поля, предсказуемые статусы, одинаковые ошибки. Если поле устарело, добавили временную совместимость на один релиз, чтобы не ломать экран целиком.
Чтобы убедиться, что ничего не сломали, прогнали короткий набор ручных сценариев:
Итог заметен сразу: новые фичи добавляются быстрее, потому что понятно, где лежит логика, а ошибки проще искать, потому что названия и контракты больше не плавают.
После того как вы прошлись по ключевым местам, важно не вернуться в режим сделали быстро и забыли. Лучший способ сохранить результат - зафиксировать пару простых правил и повторять их в каждом следующем цикле.
Сделайте короткий файл с договоренностями команды (1 страница). Не манифест, а конкретика: как называем компоненты и хуки, как называем папки, где лежат типы данных, как оформляем ошибки API. Добавьте 2-3 примера хороших имен. Это экономит часы споров и переименований.
Следующий цикл планируйте как работу с долгами, но маленькими порциями. Держите один список, а в спринт берите только то, что дает быструю отдачу: удалить дубли и вынести общую функцию/хук, разрезать слишком большой компонент на 2-3 части, привести один модуль API к единому контракту, добавить 2-3 тестовых сценария на самое рискованное, поправить структуру папок в одном домене, а не во всем проекте сразу.
Чтобы не бояться правок, используйте планирование и снапшоты. В TakProsto можно сначала описать изменения планом, а потом вносить их шагами. Снапшот перед серией правок и откат через rollback снимают страх сломать и не вернуть.
Когда проект подрос, полезно экспортировать исходники и разделить работу: один человек доводит фронт (React), другой - бэкенд (Go и PostgreSQL), третий - мобильную часть (Flutter). При этом TakProsto (takprosto.ai) остается удобным местом для быстрых экспериментов и проверки гипотез, а доведение до поддерживаемого состояния идет спокойнее и предсказуемее.