Инструкция Программиста

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

1. Задачу выбираем из своего стека скрам-доски, во время скрама, с учетом текущих приоритетов. Скрам-мастер сдвигает задачу на колонку «1 день».
2. Проверяем, что у задачи стоит длительность 0.5 или 1 день. Без длительности задачу не решаем, если больше дня, то декомпозируем.
3. Обязательно получаем устные уточнения по задаче и устно предлагаем решение в тч интерфейс и аргументы и тп.
4. Если это Bug, то обязательно лично воспроизводим на своей виртуалке и только потом решаем.
5. Выбираем свой свободный branch, который уже замерджен в Integra. Обычно это попеременно $login1 и $login2, например kolko1 и kolko2. Нельзя решать более одной задачи в одном branch.
6. Работа с кодом:
   • git status - проверяем, что нет локальных изменений.
   • git pull - подгружаем последние изменения.
   • еще раз git status - убеждаемся, что нет конфликтов.
   • меняем/создаем код, соблюдаем codestyle и соглашения кода.
   • отлаживаем каждую строку, даже если 1 байт исправления, в тч при исправлении комментариев, дебагов и текстовых строк, тк вероятность ошибки в каждой новой или исправленной строке всегда 100%
   • если Вы не можете или не хотите отладить и проверить строку, то Категорически нельзя добавлять неотлаженную строку кода т.к. Вы создадите очень очень много проблем в будущем.
   • от изменения кода до отладки не более 3 секунд, если требуется, делаем скрипт копирования только нужных файлов и рестарт нужных служб. Не делаем полную пересборку при отладке!
   • git add -p - вносим изменения построчно, особенно проверяем, что ничего лишнего и временного и отладочного не попало в коммит.
   • git add имя_нового_файла - добавляем новый файл или git rm имя_файла удаляем лишние файлы.
   • Категорически запрещено делать «git add .» и «git commit -am» это гарантированный пропуск бага.
   • git commit -m 'Fixed(сайт): Не закрывалась форма логона в firefox' или 'Добавлена печать карточки пользователя' - Создаем коммит русским, понятным простому пользователю языком. Все изменения автоматом попадают в ChangeLog на сайт и в продукт. Лучше больше малых коммитов, чем один очень большой.
   • git status - добиваемся чистого вывода.
   • git pull - подгружаем текущие изменения, проверяем и разрешаем конфликты.
   • git push origin kolko1 - отправляем в свою ветку в gitlab.
7. Делаем полную пересборку вашей ветки, проводим ручное тестирование основных кейсов использования изменений и fast-autotest.
8. Если все тесты прошли успешно, код передается на codereview:
   • Спец.утилитой создается merge-request из вашего текущего бранча kolko1 в Integra по всем измененным репозиториям. Утилита сама выберет Вашего парного codereviewer'а. Либо имя можно указать параметром.
   • После merge-request нельзя ничего менять в kolko1 он залочен, новую задачу решаем в kolko2.
   • Codereviewer просмотрев код и, посчитав его нормальным, принимает merge-request из kolko1 в Integra, после этого бранч kolko1 разблокируется. Если с кодом проблемы, то проводятся доработки и бранч остается заблокированным.
   • Когда задача находится в режиме приема реквеста - ответственный за нее остается исполнитель. Он заинтересован, чтобы ревьювер его не продинамил и принял мерж-реквест. Поэтому, если ревью давно не принимают - он должен подойти к ревьюверу лично. Если ревьювер занят и не может провести ревью - он говорит время, когда к нему можно подойти (см. правила решения задач).
9. На скраме:
   • На скраме мы не спрашиваем ревьюверов, почему они приняли/не приняли/когда примут реквест. Мы это спрашиваем у ответственного по задаче, когда он договорится с его ревьювером.
   • Если задача находится на codereview, заявка вешается в колонку «Test».
10. Когда задача успешно прошла codereview, на близжайшем скраме переводим задачу в колонку Done или AlarmDone.

Примечания:

• Все разработчики раз в день (если высокая нагрузка, то реже) просматривают в gitlab список открытых на них реквестов. Если обнаружены проблемы: пишут об этом комментарий или сообщают лично, заявку при этом не закрываем - свои незакрытые реквесты просматривает разработчики. Закрытые по ошибке реквесты должны пересоздаваться спец.утилитой.
• Разработчик раз в день (или чаще) просматривает список своих реквестов. Приняли ли их, что нужно исправить. Если реквест очень срочный - он может подойти к ревьюверу лично или позвонить.
• Запрещено двигать задачи на скрам-доске, это делает только скрам-мастер.
• Решаем только задачи которые есть на скрам-доске и прикреплена к колонке «N день».
• Категорически запрещено решать задачу, если ее нет на скрам доске.
• Если решили задачу раньше скрама, выбираете следующую вместе со скрам-мастером или сами если скрам-мастер разрешает.
• Если возникла внеплановая аларм-задача или личная инициативная задача, то создается листок задачи и прикрепляется на колонку «1 день» и уведомляем скрам-мастера.
• Ежедневно на скраме скрам-мастер сдвигает задачу на один день влево, если задача дошла до 3 дня привлекается помощник.
• Если потребуются доработки будет создана отдельная задача.
• git commit -am 'Deleted some files' можно использовать только для подтверждения удаления множества файлов, после внесения остальные изменения командой git add -p

• Все ножницы должны быть одинаковы. Всегда и у всех в пределах одного проекта используются одинаковые, согласованные инструменты разработки и отладки. Все типовые инструменты должны быть установлены на рабочем месте утилитой crab либо руками. Инструменты должны быть одной версии. Если используете сторонние инструменты, то все равно все типовые инструменты должны быть установлены.
• У каждого должны быть установлены стенды devops CI: vm_сборщик, vm_autotest, vm_отладки, для бренча $login1 и $login2.
• Список инструментов(Коля доделай):
  • Контроль версий только git
  • Для Python PyCharm
  • Для Си CodeBlocks и gdb
  • Для bash crab_indent, crab_syntax
  • Трекер jira,jira-web,jira-client,jira-python-console. Также можно использовать CRM особенно на этапе когда много задач от клиентов чтоб не дублировать. На первичном этапе version-0.0.0 можно использовать маркерную доску или вики. Также можно использовать другие трекеры по согласованию с руководством.
  • ОС разработчика ubuntu
  • ОС продакшн, devops, CI - Centos 6, иногда Centos7
  • TODO вставить остальное согласованное из обсуждения

• Попутно с основной задачей нельзя исправлять код никакой никогда, если увидели багу - создайте задачу. Если все таки попутно поправили то обязательно отладьте и протестируйте.

• Никогда не делайте массовых обновлений, делаем 10 потом 50 потом далее.
• Софт должен удовлетворять только 80% клиентов и не быть излишне гибким, не должно быть много опций.
• Софт должен работать из коробки сразу после установки.
• Установка должна быть пошаговой с мастером настройки.
• Установка настройка и работа должны быть интуитивно понятны и без документации.
• Не придумываем новых принципов форм интерфейсов, UI используем стандартные понятные пользователям.
• Встроенные средства резервного копирования, работающие из коробки, для восстановления данных пользователя из-за ошибок программ и пользователей.
• Все изменения устанавливаемые клиентам должны быть в тот же день внесены в дистрибутив в свою, клиентскую или временную ветку, до ухода домой.

Рекомендуется делить день на часы 3+2+3 либо на 4+4.

• 3 часа утром решаем сложную задачу, ни с кем не общаемся ничего не читаем, даже почту.
• 2 часа решаем мелкие задачи, читаем почту, проводим скрам, общаемся.
• 3 часа решаем сложную задачу или неприятные мелкие задачи.

Правило тишины

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

Лайфхаки

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

strongbash
python

Читать далее: контроль версий, сборка и тестирование

~~OWNERAPPROVE~~