msulab.ru — платформа на legacy-коде
Онлайн‑платформа МГУЛАБ, msulab.ru, досталась нам целиком на legacy‑коде: без документации, с чужой архитектурой и частично неработающим функционалом. Через этот сайт проходит почти все: оформление заявок клиентами, регистрация и отбор проб, внесение результатов лаборантами, генерация протоколов и отчетов, обмен данными с Битрикс24 и подрядными лабораториями.
Заказчик, МГУЛАБ, — аккредитованный испытательный центр, выполняющий анализы воды, почвы и воздуха. Работает с промышленными клиентами и агросектором, участвует в тендерах, опирается на научную школу МГУ.
Вместо переписывания системы с нуля мы выбрали путь аккуратного развития чужого кода. Починили и отладили интеграцию с Битрикс24, добавили очереди импорта и экспорта данных и расширили функциональность под новые сценарии работы лаборатории. За 3093 часа программирования реализовали 251 задачу — от крупных модулей до точечных правок — при этом платформа все время оставалась рабочим инструментом МГУЛАБ.
К нам в «Хороший дизайн» ребята перешли от другого подрядчика. Сайт был реализован на 1С‑Битрикс с личным кабинетом и интеграцией с Битрикс24, но часть функционала не работала или не соответствовала процессам лаборатории. Нужно было разобраться в чужом коде без документации, починить сломанное и недоделанное и развивать дальше — всё без остановки работы лаборатории.
Сайт МГУЛАБ выполняет две роли: внутри лаборатории это ЛИМС (LIMS, Laboratory Information Management System), где ведется вся работа с пробами и результатами, а для клиентов — витрина с возможностью заказать анализы.
Создание заявки
Заказ может быть создан по-разному: клиент самостоятельно оформляет заявку на сайте, менеджер делает это вместе с клиентом на сайте, или менеджер создает сделку в Битрикс24, которая потом приходит на сайт и уже там оформляется. На сайте происходит заполнение всех данных клиента, адреса взятия пробы, объекта исследования, типа источника, шаблона заключения, условий отбора пробы, необходимой тары. Там же выбирается способ оплаты, добавляются дополнительные показатели или новые пробы. В момент оформления генерируется заявка на отбор проб — это документ заказа, который фиксирует все условия.
Регистрация пробы
После оформления заказа регистрируется проба. Это означает, что система создает задания по всем показателям, которые нужно измерить, и отправляет заказ в Битрикс24.
Отбор проб
Проба может быть отобрана по-разному: заказчик сам привозит пробу, курьер МГУЛАБ забирает ее, или инженер по отбору выезжает на место. Для курьера на сайте есть отдельный шаблон оформления заказа.
Этикетки
После отбора на пробу клеят этикетку. Этикетки генерируются и печатаются с сайта и содержат штрихкод или QR-коду для идентификации пробы.
Исследования
Сами исследования проводят лаборанты МГУЛАБ. Часть показателей может выполняться субподрядчиками — сторонними лабораториями. Результаты своих исследований лаборанты вносят на сайт — вручную или загружая CSV-файл с лабораторного оборудования.
Закрытие пробы
После внесения всех данных ответственный сотрудник проверяет показатели и закрывает пробу. При закрытии в очередь добавляется генерация протоколов и заключения и отправка этих файлов в Битрикс24 и в личный кабинет клиента на сайте.
Битрикс24
В CRM происходит фиксация общения с клиентом, запись звонков, выставление счетов, смена статусов сделки. Из Битрикс24 же идет отправка клиенту готовых протоколов и заключения.
Роли
Одна и та же проба выглядит по‑разному для разных пользователей: клиента, менеджера, курьера, лаборанта. Интерфейсы личного кабинета написаны на Vue.js — они достались нам вместе с остальным кодом, и мы вносили в них правки.
Права доступа для разных ролей настраивает администратор
Очередь
Как мы вошли в проект
Клиент обратился к нам, потому что по его сайту требовалось выполнить много работ, которые не получалось закрыть силами их тогдашнего подрядчика. Нам дали тестовую задачу: настроить автоматическую передачу PDF‑документов с результатами испытаний в список «Пробы» Битрикс24. Когда мы сдали задачу, клиент полностью доверил проект нам.
Одной из первых больших работ стало обновление с PHP 7 на 8, которое мы выполнили без остановки работы сайта.
Клиент активно использует Битрикс24, у него настроены сценарии для автоматизации работы со сделками. Чтобы это адекватно работало, требовалась стабильная двусторонняя синхронизация между сайтом и CRM. Заявка с сайта создает сделку в Битрикс24, сгенерированные документы возвращаются в CRM, изменения в CRM отражаются на сайте.
На практике при синхронизации пользователей возникала проблема: пользователь не находился в CRM, или заказ дублировался. То же самое происходило с пробами — они попадали не в тот заказ или дублировались.
Кроме того, обмен сбоил на уровне отправки данных. Битрикс24 мог не ответить — и тогда данные просто терялись. Система работала напрямую: сгенерировался файл — сразу отправился. Если в этот момент случался сбой, файл не доходил, и никто об этом не узнавал.
Были проблемы и с синхронизацией товаров. Например, клиент пробовал создавать товары в CRM через раздел «Магазин», но такие товары вели себя на сайте нестабильно.
Мы восстановили импорт, починили выгрузку протоколов, решили много конкретных проблем с синхронизацией. Архитектуру обмена полностью переделали. Сделали очередь на cron. Каждая операция — загрузить файл, импортировать пробу, отправить документ — попадает в таблицу. Фоновый процесс по расписанию обрабатывает ее последовательно.
Очередь
Если Битрикс24 не ответил, запись не теряется, а остается в очереди до следующей попытки. Добавили защиту от дублей: по одному документу может быть только одна активная попытка отправки.
У МГУЛАБ есть субподрядчики — сторонние лаборатории, которые выполняют анализы по части показателей.
При формировании протоколов и заключений система не умела группировать показатели по организациям-исполнителям. Если по одной пробе работали и своя лаборатория, и субподрядчик, то непонятно было, какие результаты уже готовы, а какие еще нет.
Мы добавили группирующее свойство для показателей. Оно позволяет связать одинаковые показатели, которые выполняются разными организациями. В интерфейсе контроля работ появился отдельный прогресс по каждой организации: сколько показателей загружено, сколько осталось.
При формировании протоколов система анализирует список заданий по пробе и создает количество протоколов, соответствующее количеству организаций-исполнителей.
Прогресс по каждой организации-исполнителю
Мы работаем с тремя типами генерации документов, у каждого своя история.
Протоколы испытаний генерируются из DOC-шаблона. Данные о заказчике, список показателей и результаты подставляются в шаблон, после чего документ конвертируется в PDF.
Мы дорабатывали шапки и реквизиты, добавляли QR‑код. Реализовали генерацию протокола сразу на группу проб — раньше это было возможно только для одной пробы.
Выдержка из протокола испытаний
Выдержка из протокола испытаний
Заявка на отбор проб (документ заказа) и акты отбора генерируются не через шаблон, а построчно сразу в DOC. Причина — жестко регламентированная структура этих документов. Клиенты распечатывают эти отчеты, и они должны стабильно выводиться четко, вне зависимости от объема и содержания заказа.
Конвертация из HTML в PDF стандартными библиотеками не обеспечивает идеального попадания: могут не подключиться шрифты, не отобразиться SVG, нет возможности использовать колонтитулы.
Поэтому использовали низкоуровневую программную генерацию doc-документа по строчкам. Она дает полный контроль над версткой. Это самая крупная задача по документам, она заняла 206 часов.
Расширенные отчеты генерируются через HTML с последующим экспортом в PDF. Структура отчета зависит от данных: в зависимости от результатов появляются или исчезают целые разделы, меняется количество строк в таблицах. Здесь требования не такие высокие, поэтому подходит генерация HTML.
Выдержка из отчета об агрохимическом исследовании
Выдержка из протокола испытаний
Мы не просто настроили вывод отчетов — мы постоянно вносили в них изменения и доработки под новые требования лаборатории. Вот один из примеров.
В отчет по агрохимическому обследованию почвы добавили новые расчетные блоки. Для одних показателей настроили вывод графиков (например, шкала pH с семью категориями), для других — таблицы с расчетами (степень засоления, нуждаемость в гипсовании, доза мелиоранта). Сделали два режима работы: расширенный отчет для детального анализа единичной пробы и базовый для группы проб. Оба типа доступны для генерации как для одной пробы, так и для группы.
Выдержка из отчета об агрохимическом исследовании
Добавили идентификацию проб в шаблоне для группы. Раньше каждая проба начиналась с нового листа — при большом количестве проб это давало полупустые страницы. Теперь, если блоков становится больше, правило с новым листом отменяется. Если по какому-то показателю нет данных, соответствующий блок полностью скрывается.
Отдельная большая задача — выбор ответственного сотрудника. Раньше в протоколе был закреплен один человек, и его данные подставлялись всегда, даже если он в отпуске или уже уволился. Мы добавили в интерфейс возможность выбора сотрудника для каждой из ролей: лицо, утверждающее протокол, лицо, составляющее протокол, лицо, утверждающее заключение, лицо, составляющее заключение. У сотрудника хранятся ФИО, должность и изображение подписи. В момент закрытия пробы эти значения фиксируются в карточке пробы, и при последующей перегенерации документов подставляются уже сохраненные данные. Если нужно изменить — можно отредактировать в карточке пробы, и новая генерация подхватит новые значения. Все логируется.
Выбор ответственного сотрудника для каждой роли в протоколе
На каждую отобранную пробу (или пробу, полученную от заказчика) сразу клеится этикетка. По штрихкоду или QR-коду на этикетке система идентифицирует пробу при сканировании — можно получить все данные о ней.
Мы обновляли макет этикеток несколько раз. Перешли со штрихкода на QR‑код — клиент попросил, потому что QR-коды удобнее для считывания. Синхронизировали состав полей с текущей логикой заявок. Добавили кнопку «Распечатать» для курьера — раньше курьер не мог распечатать этикетку сам.
Была и более сложная доработка: этикетки нужно было распределять по двум типам файлов — для отбора силами самой лаборатории и для отбора, когда пробы привозит заказчик. В зависимости от способа отбора и наличия определенных показателей генерируются дополнительные этикетки с разными шаблонами и количеством экземпляров.
Макет этикетки на тару с QR-кодом
Технические специалисты лаборатории ставят задачи нашим разработчикам через Битрикс24. Там же переписываемся и ведем задачу до закрытия. Принимает задачу сам клиент, без менеджеров.
Пример: выдержка из ТЗ на доработку отчета по почве
Пример: выдержка из ТЗ на доработку отчета по почве
Никаких готовых спецификаций — только описание нужного результата на языке химиков и агрономов. Мы глубоко погружены в предметную область, поэтому даже с чужим кодом и отсутствием документации можем разобраться, что от нас требуется. Одна задача может собирать 80–170 комментариев — это нормальный процесс уточнения.
Мы все задачи фиксируем в своей CRM вместе с перепиской с клиентом, уточнениями, промежуточными версиями. Команда лаборатории обычно сама не знает, откуда тянется то или иное поле. Приходится восстанавливать логику, искать по коду, помнить контекст, все фиксировать.
Примеры задач с почасовкой
Интеграция с Битрикс24:
- Настройка двустороннего обмена между сайтом и CRM — 42 часа.
- Экспорт документов в список «Пробы» — 51 час.
- Ускорение передачи протоколов через очередь на cron — 25 часов.
- Добавление оплаты по ссылке из Битрикс — 24 часа.
Документы:
- Приведение заявки к актуальному виду (низкоуровневая генерация DOC) — 206 часов.
- Замена ответственного сотрудника в протоколах — 92 часа.
- Разделение протоколов по организациям-исполнителям — 80 часов.
- Генерация протокола на группу проб — 68 часов.
Отчеты:
- Отчет по агрохимическому обследованию с нуля — 149 часов.
- Доработка отчета по почве: засоление и адаптация под группу проб — 67 часов.
- Новая форма отчета — 46 часов.
Монитор и интерфейсы:
- Оптимизация отображения проб в мониторе — 174 часа.
- Подготовка системы к аккредитации — 53 часа.
- Группировка показателей по организациям-исполнителям — 57 часов.
Этикетки:
- Генерация этикеток на тару — 48 часов.
- Изменение макета этикеток — 21 час.
За шесть лет мы закрыли 251 задачу клиента. Общее время — 3093 часа.
Мы полностью взяли на себя поддержку и развитие чужой платформы. Починили двусторонний обмен с Битрикс24, добавили новые функции, типы документов и отчетов. Научили систему работать с субподрядчиками, многое оптимизировали и внедрили. МГУЛАБ работает на этой платформе каждый день и остаётся нашим клиентом.
Legacy — это не приговор. Мы получили огромный чужой проект без документации. Мы не стали его переписывать с нуля и не делали рефакторинг ради рефакторинга. Мы разобрались в коде, сохранили всё, что работало, и аккуратно доработали то, что требовалось клиенту. Система продолжает работать каждый день, а мы продолжаем её развивать.
МГУЛАБ остаётся нашим постоянным клиентом.
Комментарий агентства
Чтобы разбираться с проектами на устаревшем или чужом коде, нужны терпение и взрослый вдумчивый подход. Благодаря этим качествам команда «Хорошего дизайна» успешно делает работу, за которую другие боятся браться, или бросают в процессе.
Денис Кулиш — генеральный директор (CEO)
