Общие рекомендации

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

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

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

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

Как минимум, подобная ошибка может затруднить использование контекстных ссылок. В приведенном выше примере инженер получит ошибку при попытке сослаться на правило с именем getDeviceInformation, так как фактическое имя правила содержит ошибку в написании слова "devise".

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

• When working on large projects with many other people, increase the frequency of backups to ensure that everyone's work is safely backed up

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

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

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

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

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

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

Добавление комментариев к шагу в наборе правил поможет вам и другим инженерам понять назначение шага:

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

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

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

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

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

• Пример ошибки при проверке пароля:

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

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

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

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

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

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

Смотрите раздел "Лучшие практики написания скриптов", чтобы получить больше советов.

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

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

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

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

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

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

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

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

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

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

Когда вы сталкиваетесь с препятствиями в своей работе, рассмотрите следующие шаги:

1. Определите проблему: Четко определите, с какой проблемой вы столкнулись.

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

3. Примените найденные решения: Используйте любые применимые инструкции или идеи для решения проблемы.

Помимо того, что вы являетесь потребителем информации, вы также можете внести свой вклад в развитие сообщества пользователей SberMobile:

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

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

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

Активное участие в создании и обслуживании базы знаний имеет ряд преимуществ:

• Оно обеспечивает сохранность и доступность знаний.

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

• Оно способствует непрерывному обучению и совершенствованию в командах.

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

Зависимость от sleep может создать зависимость от производительности системы, которая может отличаться на разных серверах или после обновления сервера. Текущая переменная может привести к двум основным проблемам:

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

2. Опыт пользователей: Пользователи могут испытывать ненужные задержки при ожидании завершения действий, особенно если продолжительность sleep не оптимизирована.

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

• Произошло событие: Реализуйте события, которые запускают последующие действия при выполнении определенных условий или задач.

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

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

Рассмотрим приложение для инструментальной панели с кнопками, запускающими сложные операции, такие как создание контекста с последующим переходом на экран:

• Неуместное использование: Вставка sleep между созданием контекста и переходом на экран может привести к тому, что пользователи подумают, что приложение потерпело крах из-за невосприимчивого поведения.

• Решение - Активация ключевых слов: Вместо использования sleep можно реализовать активацию по ключевому слову, при которой результаты одной операции (создание контекста) сохраняются в пользовательских свойствах, которые затем служат триггерами для последующих операций (переход экрана).

• Решение - запуск специальных событий: Альтернативный способ запуска специальных событий в критические моменты позволяет беспрепятственно связывать зависимые операции без произвольных задержек.

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

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

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

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

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

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

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

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

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