Лучшие практики low code разработки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Was this page helpful?

Tell us more

Send

Thank you!