Подходы к рефакторингу платформеннозависимого кода

В предыдущих статьях, подготовленных по докладу Александра Кириллова, руководителя группы разработки компании «ИТ-Экспертиза», с которым он выступил на конференции INFOSTART TECH EVENT 2024, мы рассмотрели особенности работы информационных систем 1С под управлением Linux и анализ конфигурации 1С на наличие платформеннозависимого кода. В этом материале поговорим о рефакторинге такого кода и его подходах.

Итак, мы завершили наш аудит, проставили рекомендации и сформировали отчет; теперь можно приступать к рефакторингу платформеннозависимого кода и для этого есть три подхода: 

1. Всю исходную функциональность, реализованную под Windows, оставляем, а реализацию под Linux делаем в отдельном блоке условия. Такой подход удобен при поэтапной миграции с Windows на Linux, когда нужно сохранить ранее работающую функциональность. Также это позволяет сократить время на тестирование определенной части, реализованной под Linux.
2. Реализация универсального кроссплатформенного решения. Этот вариант можно считать оптимальным и компактным, однако такой подход требует тщательного тестирования еще до миграции, так как исходная реализация изменяется и необходимо убедиться, что первоначальная функциональность не нарушена.
3. Смешанный подход, при котором основные возможности адаптируются универсально, а сложная или незамещаемая функциональность разделяется на ветки.

Отдельно нужно сказать о сложных для замещения механизмах, в частности, самом популярном – COM, который в ОС Windows позволяет широко использовать возможности сторонних приложений, что очень ценят разработчики.

Из-за большой популярности механизма COM им нередко злоупотребляют, и поэтому обращения к COM-объектам составляют значительное число мест обнаружений при аудите. Но с учетом того, что платформа «1С:Предприятие» (далее платформа 1С) постоянно развивается, то с каждой новой версией появляется все больше действий, которые можно выполнять без использования внешних компонентов.

На рисунке выше изображен алгоритм замещения вызовов COM-объектов. В первую очередь, важно убедиться, что функциональность действительно используется и ее требуется заместить.

Если ответ положительный, нужно проверить возможность реализации средствами платформы, например, чтение документа MS Excel можно реализовать через ТабличныйДокумент. Если платформенные средства подходят, стараемся использовать их; а если нет, пытаемся найти готовое решение под ОС Linux, имеющее API или возможность работы через командную строку, и используем ее. Если никаких других вариантов не остается, реализуем собственные компоненты по технологии NativeAPI.

Что касается особенностей разработки внешних компонентов под ОС Linux, на сайте 1С:ИТС есть содержательная статья с рекомендациями, поэтому затронем только основные моменты: 

• разработчик должен предусмотреть варианты для всех платформ, включая ARM и Эльбрус
• компонент должен поддерживать работу на всех операционных системах из списка поддерживаемых «1С:Предприятием» и иметь кроссплатформенную реализацию
• разработчик должен корректно выполнять преобразование символьных данных типа WCHAR_T
• используемые дополнительные модули нужно указывать в документации, а несистемные run-time библиотеки должны быть статически включены в компонент
• при возникновении исключительных ситуаций, они должны быть перехвачены, обработаны в компоненте и переданы в 1С с помощью метода AddError. 

Работа с офисными документами 

Еще одна популярная задача при разработке на 1С – это работа с документами. Это может быть как загрузка данных из табличного документа, так и формирование различных выходных форм. Так как в ОС Linux используются только открытые форматы офисных документов, чтобы иметь возможность их редактирования, то часть задач может быть выполнена средствами платформы. Например, чтение и запись табличных документов простой структуры. 

Для формирования выходных форм текстовых документов (например, формата .docx) можно использовать модули БСП. Однако встречается функциональность, которую не получится реализовать средствами платформы. В этом случае используется следующий подход:

• нужно сформировать шаблон документа (средствами платформы или подготовить и сохранить в макете)
• редактировать как документ в формате OOXML, то есть, вносить изменения в нужные XML-документы внутри архива. 

Для разбора и внесения изменений в документы в формате OOXML мы реализовали общие модули, позволяющие выполнять действия, которые невозможно осуществить средствами платформы и которые отсутствуют в БСП. Например:

• изменение стилей ячеек табличного документа
• работа с формулами
• защита документов 

Чтобы минимизировать проходы по XML-файлам мы выбрали подход, аналогичный используемому для редактирования строк табличной части в БСП, а именно – собирается структура действий с параметрами, выполняется один проход документа и данные действия применяются последовательно.

Подключаемое оборудование 

Подключаемое оборудование является важной частью процессов многих компаний. Но при переходе на ОС Linux можно столкнуться с проблемами при его использовании; например, не окажется драйверов давно привычного и хорошо знакомого оборудования. Но даже если все драйвера в наличии, взаимодействие с оборудованием в Linux может происходить иначе. Например, для сканирования в Linux используется протокол SANE, существенно отличающийся от используемого на Windows TWAIN. 

Как правило, такие проблемы можно решить при наличии средств и ресурсов; например, подобрать новое оборудование и настроить взаимодействие с устройством по новым механизмам. В нашей практике была реализация подсистемы для работы с SANE, и нам удалось повторить все исходные бизнес-процессы по потоковому сканированию документов. 

Какие могут возникнуть проблемы? 

В завершении поговорим о проблемных моментах, которые нужно иметь в виду. Например, конфигурация может содержать функциональность, которую невозможно заместить (с разумными трудозатратами). Содержательно это можно разделить на три группы: 

1. Приложения и компоненты, не имеющие реализацию под Linux или эксклюзивные разработки под заказчика, не поддерживающие кроссплатформенность
2. Оборудование, не имеющее драйверов под Linux
3. Использование возможностей Windows, не имеющих аналогов, например:

• извлечение текста – Windows позволяет извлекать тексты из любых файлов (в т.ч. офисных документов) средствами системы, на Linux такая функциональность отсутствует и ее требуется реализовать для каждого вида документа
• печать документов – Windows позволяет печатать документы (в том числе, офисные) средствами системы, в Linux есть возможность печати ограниченных форматов документов, среди которых отсутствуют офисные. 

Если данная функциональность для заказчика является критичной, переход с ОС Windows на Linux как таковой может оказаться под угрозой. Поэтому при обнаружении таких мест нужно экстренно оповестить заказчика, тщательно все проанализировать и подобрать возможные альтернативы. В худшем случае нужно согласовать деградацию функциональности или отказаться от замещения.

В четвертой статье этого цикла обсудим особенности тестирования по завершению рефакторинга и предложим полезные советы, которые помогают нам при избавлении от платформеннозависимого кода в конфигурациях заказчиков.