Общая передовая практика

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

Например, описание контекста:

Комментарий к шагу в наборе правил:

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

Пример опечаток:

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

• После завершения работы с определенным контекстом или таблицей создайте резервную копию его текущей версии.

• Рекомендуется создавать резервные копии текущего контекста или таблицы перед обеденным перерывом.

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

• Модель может выполнять различные процессы. Лучшей практикой является создание событий после выполнения важных действий, таких как "начало синхронизации" или "конец синхронизации". Однако события следует использовать разумно, поскольку слишком частое их срабатывание может создать ненужную нагрузку на сервер. Хорошим примером такой практики является функция "управление аватарами" в ресурсах платформы.

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

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

Другие пользователи должны иметь возможность понять назначение контекста, функции или другого элемента из его описания или комментариев.

Избегайте использования комментариев типа "не трогайте это" или "я не знаю, как это работает".

Пример комментария в наборе правил:

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

В качестве валидаторов можно использовать регулярные выражения (regex). Вот два примера:

• Для выражений в привязках для приборных панелей используйте следующее правило, чтобы разрешить любую цифру: {env/value}~=([0-9]+).

• Для переменных выберите специальную опцию и выберите тип, затем напишите правило. Например, чтобы разрешить только строчные латинские буквы, используйте следующее правило: {env/value}~=([a-z]+).

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

• Проверка пароля пользователя:

Пример информации о пользователе:

Не все могут владеть языком Java, что может создать трудности для других инженеров, работающих над проектом или поддерживающих его.

Если возможно, рассмотрите возможность поиска полезных функций "кода Java" и добавления их к базовой функциональности платформы для использования в других проектах.

Использование скриптов может быть целесообразным в некоторых случаях, например:

• Когда функций aggregate и addColumns недостаточно для цикла:

  Если требуется добавить вложенную функцию типа "aggregate(aggregate,...),...,...", то это хороший показатель для использования Java-скрипта. Если требуются дополнительные уровни вложенности, настоятельно рекомендуется использовать скрипты.

• При работе с большими массивами данных:

  Для анализа массивов данных сценарии могут быть лучшим вариантом. Например, функция для вычисления CRC.

• При использовании необычной логики для разбора строк:

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

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

• Группируйте привязки по видимой области (шаги в мастере, вкладки из tabPanel).

• Располагайте связанные привязки друг за другом

Предположим, у вас есть контейнер с двумя вкладками, где первая вкладка содержит comboBox и dataTable, а вторая - lineChart. Когда пользователь выбирает опцию из comboBox, должны обновляться и таблица данных, и линейная диаграмма.

Этого можно добиться двумя способами. Плохая реализация заключается в активации привязки для lineChart каждый раз, когда пользователь выбирает опцию из comboBox, что приводит к пустой трате ресурсов, поскольку привязка может быть активирована много раз без отображения какой-либо информации.

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

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

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

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

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

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

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

Пример плохой практики: