Привет, я Андрей! Ну где ты был, ну открывай статью скорей :-)
За технической инфой я обращался к команде разработчиков, в том числе к backend-разработчику Сергею Колеватову. Он пояснил мне за все технические штуки, а я уже поведаю вам подробнее.
В этот раз расскажу об опыте создания внутренней системы для госкомпании. Загвоздка, как всегда, была в сроках и ресурсах. А продукт нужен сразу порядочный. Готовый шаблон, Symfony Forms и «грязный» код. Выбор пал на скорость вместо качества — продукт запущен за 2 месяца, ноооо… мы получили «технический долг». Как к этому пришли и как решили проблему, расскажу прямо сейчас.
Что за система-то вообще?
Реестр Госэкспертизы — это внутренняя система организации, которая принимает и проверяет заявления на строительство объектов. Клиенту нужен был инструмент для хранения данных, комфортной работы с информацией, формирования и выгрузки отчетов.
По сути, это личный кабинет с:
таблицей заявок;
страницей с детальным заполнением данных;
калькулятором, который автоматически подсчитывает сроки (например, дату завершения проверки) и статистику;
графиками и дашбордами;
календарем ключевых дат по заявкам;
возможностью выгрузки отчетов в Excel.
Система упростила внутренние процессы:
Заявитель подает документы и видит статус заявки онлайн.
Сотрудники обрабатывают заявки: вносят данные, пишут замечания, отправляют письма. И все это без бумажной волокиты.
Руководитель Госэкспертизы видит статистику (например, сколько времени заявка провела на каждом этапе).
Этапы заявки:
Формиров��ние заявки: Заявитель подает заявку на строительство с набором полей — номер, дата, проектная документация, адрес, технические требования, а также прикрепляет чертежи и документы.
Заявка на строительство Работа с замечаниями: В процессе исправления ошибок заявитель выполняет доработки. После каждого этапа создаются новые замечания, что может продолжаться долго, пока все проблемы не будут устранены.
Дашборд 1 
Дашборд 2 
Дашборд 3 
Дашборд 4 Редактирование и проверка: Отделы проводят экспертизу, инженерные изыскания, проверяют документы, выявляют замечания и создают первичные или вторичные замечания, отправляют письма, ждут ответов.
Регламент времени: В системе есть регламентированные сроки обработки, чтобы заявки не задерживались более установленного времени.
Регламент времени 
Автоматический расчет сроков проверки Агрегация данных, архив: Все эти заявки, замечания, сроки и стадии объединяются, сохраняются в базе, и в итоге формируют итоговые отчеты и архив.
Как разрабатывали: от спешки к порядку
Акт первый — быстрый запуск
Создать функциональный «космолет» в короткие сроки и ограниченные ресурсы — задача проекта.
Мы решили выбрать Symfony, потому что:
не тянет с собой тяжелую админ-панель, в отличие от готовых cms
позволяет сфокусироваться на бизнес-логике
предоставляет удобный шаблонизатор
имеет механизм работы с формами;
мы обладаем соответствующей экспертизой
В первую очередь необходимо понять: а где мы можем срезать углы?
Фронтенд
Одним из таких углов оказался фронтенд. Для начала было решено использовать готовый шаблон админки, чтобы не заниматься излишним дизайном и версткой.
Далее под нож пошли все мысли о модных подходах на фронте. Вместо них мы использовали связку Symfony Forms и ux-live-component,чтобы:
снизить зависимость от фронтенд‑разработчиков;
за счёт backend‑команды пр��писывать логику элементов интерфейса.
Для примера: мы получили возможность сразу обновлять поля формы без перезагрузки страницы.
По итогу решение оказалось верным и такая связка позволила реализовать все поставленные задачи без привлечения фронта.
Over and over много строк кода
Ещё одним углом, который пришлось срезать, оказалось качество кода.
К сожалению, требования к системе не всегда можно определить заранее, особенно в рамках ограниченного бюджета. Поэтому часть из требований могут формироваться прямо во время написания проекта и ими приходится жонглировать на ходу. А вам это знакомо?
В таких условиях было принято решение не заниматься архитектурой кода, а писать «как есть». Это осознанное решение, которое позволяет получить больше времени сейчас, взяв его взаймы у себя будущего.
Система заработала быстро, но код получился «грязным»:
длинные файлов где количество строк стремится к ∞;
тесно связанные блоки кода (изменение в одном месте ломало другое)
отсутствие четкой структуры кода
дублирование
Короче говоря, возник «технический долг».
Хотел показать вам пример «грязного» кода, но у нас такого уже нет. Шутка:) Немного еще осталось
Собираем рюкзак для релиза: что берем, а что оставляем дома
Что вы собираете рюкзак в поход? Нужно взять самое необходимое, а не все подряд.
В нашем случае:
Обязательно: механизм расчета сроков по отделам.
Можно отложить: дашборд с данными в реальном времени (удобно, но не критично).
Мы «упаковали» в релиз только самое важное, а остальное положили в «бэклог‑рюкзак» — доберемся, когда будет время и ресурсы. Так, например, пока отложили функцию наследуемых заявок.
Акт второй — борьба с «техническим долгом»
Почему вообще нужно бороться? Клиент сильно ограничил ресурсы и сроки, поэтому команда выбрала скорость вместо качества. Это создало технический долг — будущие затраты на исправление ошибок и доработку.
Разумеется, очень важно писать код аккуратно. Однако писать «идеальный» код сразу дорого и занимает много времени. Быстрое решение иногда кажется более привлекательным, но в долгосрочной перспективе – это увеличивает трудозатраты. А все большие трудозатраты будет оплачивать клиент.
Чем опасен «грязный код»:
разрастается и превращается в огромный неконтролируемый блок, с которым сложно работать;
его трудно читать, понимать, где что исправлять, и быстро вносить изменения;
может достигать тысяч строк, обрастать зависимостями — поддерживать его становится настоящей головной болью;
сложнее тестировать, поэтому вероятность ошибок растёт;
исправление одной проблемы может «ломать» что‑то в другом месте.
Знаете вот эту ситуацию, когда ты исправишь одну проблему — неожиданно что-то «отваливается» в другом месте?
В Реестре мы столкнулись со всеми этими проблемами:
работать с проектом становилось все больнее;
оценка на реализацию даже простых фич росла.
Писать «грязно» можно, но осторожно. Мы пошли на это осознанно — как на вынужденную меру. Сначала был сделан минимально рабочий продукт, и это было важнее.
Акт третий — доработки
Система работает и развивается. Это позволяет нам по ходу создания новых фич закладывать часы на рефакторинг старого кода, понемногу разгребая завалы. А с внесением крупных обновлений, мы и вовсе можем переписывать целые модули.
Кроме того, что мы наводим порядки в коде, мы сделали интеграцию с Telegram.
Теперь есть еще один инструмент, реестр выходит за рамки личного кабинета — чат-бот и автоматические уведомления для заявителей о статусе их заявок.
Совсем недавно появился календарь заявок. «Пропущенные сроки» теперь не про отделы Госэкспертизы:
визуализация ключевых дат;
привязка к отделам;
предупреждение о приближающихся дедлайнах.
Клиент попросил сделать так, чтобы была полная картина активности: узнавать, кто и что делал в системе.
Эта фича превращает систему в прозрачную и контролируемую площадку. Теперь можно:
Видеть историю действий: все операции — кто и когда что сделал — отображаются в едином журнале.
Фильтровать по отделам: узнать активность конкретного отдела или группы сотрудников.
Упорядочить и анализировать: сортировать записи по времени, пользователю, типу действия или отделу.
Удобный и понятный интерфейс: все данные наглядные, структурированные и легко доступны.
Жизненные уроки от проекта
Как и от любого проекта, у меня в этот раз есть несколько инсайтов. Делюсь тем, что я точно буду учитывать в следующих проектах подобного плана.
Скорость vs качество. Быстрая реализация экономит деньги сейчас, но создает долги на будущее.
Рефакторинг — необходимость. Даже если код работает, его нужно периодически «прибирать», чтобы не утонуть в ошибках.
Коммуникация с клиентом. Важно объяснять, почему «быстро» не всегда значит «хорошо», и договариваться о балансе между сроками и качеством.
Мы же тут про технологии для людей и любой клиент — это в первую очередь — человек, которому, мы можем помочь разработкой.
«Госэкспертиза Реестр» — пример того, как можно создать эффективный инструмент даже с ограниченными ресурсами.
Сейчас система обрабатывает заявки ежемесячно, экономит часы рабочего времени и помогает держать процессы под контролем. Это пример того, как даже в условиях ограниченных ресурсов можно двигаться от хаоса к порядку — если не забывать про долгосрочную перспективу.
