Skip to content

Правила разработки

Отправной точкой разработки является issue (проблема или проблемная постановка), оформленная во внутреннем трекере задач.

Описание задачи

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

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

В формулировке также может быть предложена реализация.

Пример:

  • неправильная постановка: “требуется перенести хранение логов из SQL базы в timeseries базу”.

  • Лучше изменить на: ”уменьшить загрузку SQL сервера и скорость работы за счёт переноса логов в timeseries базу для снижения необходимых для работы сервера ресурсов”.

Проблема или задача должна быть протегирована тегами подсистемы, к которым она относится, а также тегами класса — проблема, задача

Приоритеты

Приоритетом развития является стабильность ПО, поэтому программист при выборе очередной задачи должен приоритетно выбирать задачи, помеченные как дефекты ( тег #bug).

Процесс внесения изменений в ПО

При изменении ПО, нужно создавать отдельную ветку в системе контроля версий git. Ветку нужно именовать с указанием номера issue задачи или проблемы.

После внесения изменений, создаётся Merge request который должен быть просмотрен другим автором и допущен к слиянию с основной веткой.

Выбор версии системы делать по принципам «Семантического версионирования 2.0.0» https://semver.org/lang/ru/

Чек-лист внесения изменений в ПО:

  • созданы и пройдены внутренние юнит тесты
  • создана или обновлена документация, в En и Ru ветках
  • изменены номера версий в ресурсных файлах (default.inc.php и version.h)
  • создана запись в файле ChangeLog.Glaber
  • если меняются директивы конфигурации — изменения внесены в прототип конфигурации (.conf файлы)
  • если меняются DDL таблиц данных — изменения внесены в файлы описания структур данных, сгенерированы новые ddl файлы, исправлена схема для генерации ООМ файлов схемы php

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