...

Глава 1. Стандарты разработки. Соглашения об именовании. История изменений

Тема в разделе "Руководство по настройке форм и сценариев", создана пользователем ELMA365, 14 авг 2023.

  1. ELMA365

    ELMA365 Moderator

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

    Рассмотрим, почему стандарты разработки важны как в целом, так и внутри компании:
    1. Обеспечение качества. Стандарты разработки определяют правила и рекомендации для создания надёжного и безопасного программного продукта. Это позволяет уменьшить количество ошибок и повысить уровень удовлетворённости пользователей.
    2. Улучшение производительности. Следование стандартам позволяет писать более эффективный и оптимизированный код, что уменьшает время разработки.
    3. Снижение затрат. Благодаря установлению стандартов затраты на разработку и обслуживание продукта снижаются до минимума. Это позволяет улучшить финансовые показатели компании.
    4. Улучшение коммуникации. Стандарты определяют единый подход к разработке программного обеспечения, что повышает эффективность командной работы.

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

    Рассмотрим пример правил именования, которые вы можете установить.

    Соглашения об именовании

    • Коды решений, разделов, приложений, свойств: snake_case. Например:
    • раздел Кадры personnel;
    • приложение Отпуск vacation;
    • свойство Дата согласованияapproval_date.
    • Коды процессов: snake_case, в конце добавляется _workflow. Например:
      • процесс отпуска — vacation_workflow.
    • Коды виджетов: snake_case, в конце добавляется _widget. Например:
      • виджет таймера — timer_widget.
    • Наименование функций в сценариях: camelCase. Например:
      • функция инициализации — onInit;
      • функция поиска компаний по ответственному — findCompaniesByResponsible.
    • Наименование переменных, констант в сценариях: snake_case. Например:
      • const company_count = 0;
    • Если функция является обработчиком события изменения какого-либо объекта — onChangeATTRNAME. Например:
      • существует свойство user_list, тогда функция, вызываемая при изменении значения этого поля, будет называться onChangeUserList.
    • Все устаревшие и неиспользуемые контекстные переменные на любом уровне помечаются припиской old_ в начале названия. Например:
      • для устаревшего свойства Дата согласования — old_Дата согласования.
    История изменений

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

    Фиксация изменений осуществляется при помощи ввода комментариев при публикации. Предполагается использование следующих обозначений, которые помогут всем, кто участвует в разработке, быстро сориентироваться в истории:
    • feat: Добавление нового функционала и логики (контекстных переменных, сценариев, задач, виджетов на форме и т. п.). Если объем работ большой — зафиксировать бизнес-задачу, которая была реализована, опционально указать пункты ТЗ, ФТ или аналогичного документа, по которому ведется разработка проекта.
    Примеры:
    «feat: Переработка логики выбора согласующих — будет учитываться матричное подчинение и замещения»
    «feat: JIRA-12345: Учитывать замещения при выборе согласующих»

    • fix — любые правки, которые изменяют поведение ранее разработанного функционала. Можно указать пункты ТЗ, ФТ или аналогичного документа, на которые внесённые изменения влияют. Также сюда относится удаление функций в сценариях, контекстных переменных, форм и т. п.
    Примеры:
    «fix: Удалено свойство Сотрудник, вместо него используем системное свойство Автор»
    «fix: JIRA-12346: Убрать/скрыть неиспользуемые свойства»

    • style — мелкие правки по дизайну и отображению. Описать кратко, что сделано.
    Примеры:
    «style: Забыл раскомментировать строку»
    «style: Привёл в порядок стрелки»
    «style: Поменял местами поля Дата и Пользователь»

    Идеи для вдохновения и улучшений
    Последнее редактирование: 16 авг 2023