Должностная инстукция разработчика ProstorDesign

Тут расписаны основные принципы нашей работы.

Обязанности разработчика

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

• В начале рабочего дня присутствовать на летучке (время согласуется)
• В течении рабочего дня своевременно реагировать на сообщения (в течении часа) и на звонки (срочно, значит, сразу)
• В конце рабочего дня проставлять выполненные задачи в Trello
• В конце рабочего дня заполнять Google Calendar. Название мероприятия копируем полностью из карточки, над которой работаешь

Коммуникации

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

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

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

Git

Руководство по Git

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

Затем обязательно прочесть следующие главы книги (скачиваем PDF):

• Введение
• Основы Git
• Ветвление в Git
• Инструменты Git - Припрятывание и очистка
• Инструменты Git - Перезапись истории
• Инструменты Git - Раскрытие тайн Reset
• Инструменты Git - Обнаружение ошибок с помощью Git
• Приложение С: Команды Git

Коммиты

Долгосрочный успех проекта зависит (помимо всего прочего) от того, насколько его удобно поддерживать, а история коммитов — один из самых мощных инструментов мейнтенера. Разобраться, почему что-то случилось [в коде] месяцы или годы назад становится не только возможно, но и удобно.

Оформление коммита

Правила хорошего оформления коммита:

• Отделяйте заголовок от тела пустой строкой
• Указывайте тип коммита, отделяемый ":" и пробелом
• Ограничивайте заголовок 50 символами
• Пишите заголовок с заглавной буквы
• Не ставьте точку в конце заголовка
• Используйте прошедное время в заголовке
• Переходите на следующую строку в теле на 72 символах
• В теле отвечайте на вопросы что и почему, а не как

Типы коммита:

• feat: новый функционал, доработка нового функционала
• fix: исправление бага без изменения функционала
• refactor: оптимизация и/или переписывание функционала для удобства чтения и работы с ним
• cleanup: чистка неиспользуемого кода, комментариев, логов и пустых строк
• docs: документирование и комментирование кода
• version: инкрементирование версии программы
• build: изменение параметров сборки, новые зависимости и т.д.

Пример коммита:

cleanup: Резюмировал изменения в 50 символах или меньше

Тут объясните их более детально, если необходимо. Выполняйте
переносы строк примерно на 72 символах. В некоторых ситуациях
первая строка комментания считается его заголовком, а все 
остальное - телом. Крайне важно отделять оделять одно от другого
пустой строкой (если у сообщения вообще есть тело, конечно);
различные инструменты типа `log`, `shortlog`и `rebase` не поймут
вас, если заголовк и тело не будут отделены.

Объясните здесь, какую проблему решает этот коммит. Уделите 
больше внимания тому, почему вы внесли эти изменения, а не тому, 
как именно вы это сделали (это объяснит за вас код).
Есть ли побочные-эфффекты или другие неочевидные последствия у 
этих изменений? Если да, это нужно объяснить здесь.

Параграфы разделяются пустыми строками.

 - Можно делать маркированные списки

 - Обычно в качестве маркера списка используется звездочка или 
   тире с пробелом перед ними; но тут есть разные соглашения

Обязательно указываем номер и название карточки Trello:

Задача: #123 название_карточки

Во время слияния ветки, проверяющий должен подписаться в коммите:

Проверяющий: Иванов Иван

Информация взята из данной статьи за некоторыми изменениями. Обязательна к ознакомлению.

Содержание коммита

Во время работы часто бывает лень придумывать название и описание к коммиту, особенно, если это мелкая правка. Это совершенно нормально, если в течении рабочего дня у Вас образовалась цепочка коммитов: upd1->upd2->fix1->fix2 и т.д. Самое главное - не push'ить их в общедоступную ветку! Заместо этого нужно с помощью rebase прибраться в этих коммитах и привести историю в порядок, сделав из нескольких коммитов, например, один, или наоборот.

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

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

GitFlow

GitFlow - это модель ветвления разработки. Ознакомиться с ней нужно в этой статье. Можно еще и эту почитать.

Основные (постоянные) ветви:

• master - основная (продакшн) ветка
• develop - ветвь разработки

Вспомогательные (временные) ветви

• feature_name - ветви новой функциональности. Рождаются и вливаются в develop
• release/{version} - ветки релизов. Рождаются из develop, вливаются в master и develop
• hotfix/{version} - ветки срочных исправлений. Рождаются из master, вливаются в master и develop. Исключение: если в данный момент существует ветвь release, то вливаем в неё заместо develop

CodeReview

CodeReview проводится другим разработчиком. Проверяющий при слиянии ветки подписывается под коммитом слияния.

Стиль кода

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

Исключения:

• Используем tab'ы заместо пробелов

Стиль для PHP

Для PHP используем стандарт PSR, а в частности:

• PSR-1: оригинл, PSR-1: русская версия
• PSR-12: оригинал, PSR-12: русская версия

Стиль JavaScript

Для JavaScript используем следующие стандарты:

• Маленькая статья по стилю кода
• Стандарт Airbnb: английская версия, русская версия

Чистый и читаемый код

Зачастую, написание кода занимает 10% времени, а остальные 90% — это чтение того, что уже было написано. Поэтому хорошо и удобно читаемый код — это важно.

Три базовых принципа чистого кода. Он должен быть:

• макимально линейным
• коротким
• самодокументированным

Полную статью нужно прочитать по ссылке.

Статьи по чистому коду для языков:

• PHP: английская версия, русская версия
• JavaScript: английская версия, русская версия

Принципы разработки

Основные методологии разработки:

• DRY "Не повторяйте себя": статья 1, статья 2
• KISS "Делайте вещи проще": статья 1, статья 2
• YAGNI "Вам это не понадобится": статья 1, статья 2

Основные тезисы:

• Лучший код — это ненаписанный код
• Простота - залог надёжности. Всё следует упрощать до тех пор, пока это возможно
• Разбивайте задачи на подзадачи, которые не должны по вашему мнению длиться более 4-12 часов написания кода и должны решаться одним или парой классов
• Каждая часть ПО должна иметь единственное, непротиворечивое и авторитетное представление в рамках системы, т.е. дублирование кода недопустимо. Изменение единственного элемента системы не должно требовать внесения изменений в другие, логически не связанные элементы. Т.е. элементы, которые логически связаны, должны изменяться предсказуемо и единообразно
• Не нужно добавлять функциональность, в которой нет надобности
• Сохраняйте ваши методы и классы маленькими. Каждый метод должен состоять не более чем из 30-40 строк и должен решать одну задачу, а не множество случаев. Если в вашем методе множество условий, разбейте его на несколько
• Придумайте решение задачи сначала, потом напишите код
• Не бойтесь переписывать код
• Не бойтесь избавляться от кода. Если вы столкнулись с новыми требованиями, или не были оповещены о них ранее, тогда порой лучше придумать новое, более изящное решение, решающее и старые и новые задачи