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

Когда архитектура душит удобство: спасение выпрямителя от дублирования

Проект scada-coating — система управления покрытиями в производстве. На первый взгляд звучит рутинно: регулируешь параметры выпрямителя, запускаешь процесс. Но за этой простотой скрывалась архитектурная беда, которая заставляла технологов переписывать одну и ту же программу выпрямителя десятки раз для разных техкарт.

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

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

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

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

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

На выходе получился документ на 20 страниц с полной структуризацией замечаний, приоритизацией (P0–P3), оценками от 5 минут до 3 часов для каждой задачи, и согласованием с экспертами. Теперь команда знает точную дорогу к миграции: 6–8 дней разработки, все понимают почему это нужно, и готовы к пошаговой реализации по спринтам.

Архитектурный рефакторинг — это не про героев, которые переделают всё за раз. Это про планомерный разбор, согласование с доменами, приоритизацию. И результат того стоит.

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