Как мы спасли выпрямитель от плена техкарт

Как мы разобрались с переездом данных о программах выпрямителя в SCADA-системе

Работали над проектом scada-coating — системой управления процессом нанесения покрытия. Задача звучала просто: переехать данные о программах выпрямителя из одного места в другое (feature/variant-a-migration). На деле это оказалось историей про то, как один неловкий архитектурный выбор раньше создал целый каскад проблем.

Что было не так

Изначально программы выпрямителя были привязаны к техническим картам (техкартам) — специальным документам, которые описывают процесс. Звучит логично? На самом деле это была ошибка. Техкарта говорит как делать процесс, а программа выпрямителя — это просто параметр, который может использоваться в разных контекстах. Получалось, что если ты хочешь переиспользовать программу в другой техкарте, придётся её дублировать. Типичное нарушение принципа DRY.

Первым делом мы структурировали все замечания пользователей по категориям: навигация, модель данных, UI параметров, валидация. Выяснилось, что люди, которые работают с системой каждый день (технолог и оператор), говорили одно и то же: «Дайте нам программы выпрямителя как отдельную сущность».

Как это решали

Начали с архитектурного рефакторинга. Отвязали программы от техкарт, сделали их независимым ресурсом в API. Это позволило: - Переиспользовать одну программу в разных техкартах без дублирования - Версионировать программы отдельно - Валидировать параметры выпрямителя один раз, а не в контексте техкарты

Параллельно переделали UI: вместо вложенных форм с параметрами в одну строку, сделали столбик параметров — каждый на отдельной строке с подсказкой. Оказалось, что технологи и операторы часто теряют нужный параметр в длинном горизонтальном списке.

Неожиданно выяснилось, что система качества (Quality tab) нужна была не просто для просмотра, а с полнотекстовым поиском и графиками по кнопке. Мы сделали это потому, что иначе оператор вынужден вручную рыть в таблице — а это критично для отладки проблем в производстве.

Интересный момент

Обычно разработчики боятся менять архитектуру, потому что это выглядит опасно. Но в этом случае мы поступили наоборот: составили подробный план с оценкой каждой задачи (от 5 минут до 3 часов), разбили по приоритетам (P0, P1, P2, P3) и заставили три группы экспертов (UX-дизайнер, UI-дизайнер, технолог) дать фидбек на план.

Технолог неожиданно сказал: «Не удаляйте прогноз толщины покрытия — это критичный параметр для расчёта коэффициента выхода». Мы почти выбросили эту фичу, потому что думали, что она устаревшая. Такой момент очень хорошо показывает, почему code review нужно делать с людьми, которые знают доменные требования.

Что получилось

Документ на 20 страниц с полной структуризацией замечаний, приоритизацией работ (6–8 дней разработки), 5 уточняющими вопросами и выводами экспертов. Теперь у команды есть чёткая дорога к миграции, а главное — все согласны с тем, почему это нужно делать.

Следующий этап: утверждение плана, детализация задач, реализация по спринтам. Архитектурный рефакторинг — это не про героев, которые один раз переделают всё; это про планомерный разбор, согласование и пошаговую реализацию.

—

😄 Отвязать данные от техкарты — как развод: больно, но потом работаешь в два раза эффективнее.