Документация

Запуск и разворачивание

Проект создан при помощи create-react-app. В качестве пакетного менеджера используется yarn.

Перед началом работы с проектом в любом случае нужно установить зависимости при помощи команды yarn install

---

Ведение репозитория

Репозиторий мы ведем при помощи методологии guthub flow. Это упрощённая версия gitflow. Основные принципы можно посмотреть в интерактивной документации выше.

Назначение веток:

1. master - production ветка. Содержит актуальные изменения, которые попадают в development-сервер.
2. develop - рroduction-ready ветка. Содержит кодовую базу, которая в любой момент готова к выкатыванию в master.

Управление ветками

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

На основе ветки develop создайте ветку с названием по принципу: feature/add-store-page. Название ветки держите понятным и кратким. Если не получается сделать кратко и понятно, то лучше понятно, чем кратко. :) К примеру, feature/add-page-leave-preventer-modal лучше, чем feature/add-page-leave.

Баги, соответственно, хранить в ветках типа bug/add-partner-validation

После завершения фичи/бага сделайте git push и через pull request в develop отправьте изменения на согласования.

Никогда не делайте прямой merge в develop!

Именование коммитов

Коммиты именуем кирилицей. Длина заголовка не больше 72 символов. Длина строки также не больше 72 символов.

Название придумываем отвечая в голове на вопросы:

1. Что делает?
2. Почему (необязательно)?
3. Где?
4. Нужно ли пояснение?

Название должно чётко описывать что присходит. Даже если это какие-то мелкие правки от дизайнера.

Примеры хороших названий:

• Изменяет цвет наведения на пункты меню в сайдбаре

• Добавляет возможность превентить выход пользователя со страницы элемента

  Теперь появляется диалог с подтверждением выхода.
  Если юзер соглашается, то изменения сохраняются.

Примеры плохих названий:

• Изменил цвет наведения на пункты меню в сайдбаре

Что плохого? Не отвечает на вопрос "Что делает".

Дальше без комментариев:

• Изменяет цвет наведения
• Вносит css правки
• Fix

Много примеров плохих названий коммитов на английском

---

Качество кода

Для поддержания кода проекта в читаемом и стандартизированном виде мы придерживаемся стандартам написания кода от airbnb. Ознакомьтесь с стандартами написания кода, прежде чем писать.

Для облегчения поддержания соответствия кода стандартам используются две библиотеки: eslint, prettier.

eslint

Eslint настроен для проекта и установлен в зависимостях. Убедитесь, что ваш редактор кода анализирует код "на ходу". Подходящие гайды по настройке eslint в вашем редакторе вы можете найти тут. Если вы столкнулись с трудностями при настройке линтера - лучше обратитесь к коллегам и настройте вместе.

prettier

Также как и линтер - в проекте содержится пакет необходимой версии и конфиг для него. Но в своём редакторе кода создайте хоткей для форматирования кода.

---

Общие соглашения

Согласуй с командой, если хочешь:

• Ввести новую практику
• Установить библиотеку (даже если она сильно и очень срочно нужна)
• Рефакторить чужой код

При написании кода, руководствуйся принципами:

• Код должен читаться линейно сверху-вниз, слева-направо
• Код должен быть максимально простым и тупым
• Если нужно сделать что-то сложное, лучше сделать это сложным, чем легко читаемым, но запутанным. К примеру, работая с графиками - лучше не пытаться писать так, чтобы это было понятно любому новичку, а следовать рекомендациям разработчиков библиотеки
• Вложенные тернарки - зло. В рендере лучше используте условный рендеринг
• Отступы слева и сверху в css - зло. К примеру, когда нужно отлепить два блока друг от друга - используй отступ у верхнего к низу, а не у нижнего к верху
• Отрицательные отступы - зло
• position: fixed - в большинстве случаев тоже зло
• Не создавай переменные ради переменной, но создавайте переменные каждый раз, если они объясняют код. К примеру, сложные условия лучше разделить на несколько читаемых переменных
• Не допускай "технический долг" они же "костыли". Лучше, в разумной мере, растянуть сроки разработки, чем потом бороться с последствиями костылей. Не допускай этого даже в мелочах. Как правило, "потом" превращается в "никогда" или "придется и задачу делать и костыли переписывать", что ещё больше вгоняет в стресс
• Никогда не замалчивай ошибки
• Никогда не мутируй объекты
• Не делай большую вложенность кода
• Разделяй код всегда. Отступы между строк, модули, степени ответственности и т.п.
• Если нужен декоратор - не используй @decorator синтаксис. Всегда оставляй возможность получить чистый компонент
• В приоритете используй хуки для работы с redux-store, чем connect()
• Не делай лишнюю, очевидную типизацию.