Лучшие практики разработки с низким кодом

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

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

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

• Будьте бдительны и систематически избегайте опечаток и вычитывайте весь текст.

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

• Создавайте события для основных и важных действий.

• Заполняйте поля "описание" и "комментарии", избегайте использования caps lock или требовательного языка.

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

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

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

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

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

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

• Использование функции "sleep" - плохая практика. Старайтесь избегать ее, когда это возможно.

• Делайте отчеты полностью параметризованными.

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

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

• Используйте поля описания и комментариев для передачи информации о назначении того или иного свойства.

• Избегайте использования торговых марок и персонализированных имен.

• Давайте контекстам, переменным и функциям понятные и разумные имена.

• Используйте единую схему именования объектов для тестирования и отладки приложений.

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

• Добавляйте постфикс "F" и "R" для каждой функции и набора правил соответственно.

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

• В начале проекта создайте карту проекта верхнего уровня.

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

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

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

• Использование каталогов и таблиц "многие-ко-многим" вместо прямых ссылок и констант.

• Группируйте части проекта по смыслу.

• Удаляйте ненужные ресурсы.

• Избегайте создания избыточных контекстов.

• Учитывайте разрешения, пользователей и роли

• Создайте индивидуальные учетные записи с правами администратора, если вы не используете LDAP в своем проекте.

При написании кода следование некоторым лучшим практикам может помочь обеспечить эффективность, читабельность и отсутствие ошибок.

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

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

• Избегайте длинных выражений (более 3-5 функций), вместо этого используйте наборы правил.

• Используйте вкладки для вложенных функций.

• Объявляйте параметры функций в одном столбце, если они занимают много места в строке.

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

• Разделяйте длинные строки на строки

• Начинайте строки с апострофов и при необходимости заключайте их в кавычки.

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

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

• Всегда пишите документацию для каждого созданного блока функциональности.

• Упоминайте в документации только ключевую информацию.

• Используйте надежную платформу для документации.

• Используйте шаблон для последовательности в форматировании и организации.

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

• Подчеркивайте важную информацию для конечного пользователя