{{indexmenu_n>35}}

==== Вводные ====

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

==== Правила решения задач ====

Основано на реальных событиях.

  * Смотреть общие правила [[https://wika.carbonsoft.ru/carbon_soft:общие_инструкции:как_решать_задачи|https://wika.carbonsoft.ru/carbon_soft:общие_инструкции:как_решать_задачи]]
  * Задачу выбираем из своего стека скрам-доски, во время скрама, с учетом текущих приоритетов. Скрам-мастер сдвигает задачу на колонку "1 день".
  * Проверяем, что у задачи стоит длительность 0.5 или 1 день. Без длительности задачу не решаем, если больше дня, то декомпозируем.
  * Обязательно получаем **устные**  уточнения по задаче и устно предлагаем решение в тч интерфейс и аргументы и тп.
  * Если это Bug, то обязательно лично воспроизводим на **своей**  виртуалке и только потом решаем.
  * до начала изменения кода, определяем: категорию, масштаб проблемы/задачи
  * если задача из категории "запрещённых"(изменения архитектуры), то решаем их по процедуре через технический комитет. Полный список "запрещённых" задач и правила их решения смотрим в должностных инструкциях [[https://wika.carbonsoft.ru/отдел_разработки:инструкции_должностные:должностная_программист|https://wika.carbonsoft.ru/отдел_разработки:инструкции_должностные:должностная_программист]]
  * если задача не "запрещённая", обсуждение проблемы и решения - приветствуется
  * выбираем базовую ветку в которые изменения должны попасть:
      * баги/хотфиксы/критичный функционал для определённой ветки. Например мастер(если баг мастера).
      * фичи, рефакторинг, крупные правки некритичных багов - интегра
  * задача всегда решается разработчиком в отдельной ветке, **созданной от базовой**.
  * если ветка старая - обновить до начала работы(pull, reset и т.д.)
  * запрещено решать несколько не связанных задач в одной ветке
  * от изменения кода до отладки **не более 3 секунд**, если требуется, делаем скрипт копирования только нужных файлов и рестарт нужных служб. Не делаем полную пересборку при отладке!
  * Всегда смотрим изменения, которые коммитим: git add -p или git commit -v. Чтобы нежелательные изменения(отладка, и т.п.) не попали в продукт
      * **Категорически запрещено**  делать "git add ." и "git commit -am" это гарантированный пропуск бага.
  * Создаем сообщение коммита русским, понятным простому пользователю языком, в обезличенной форме. Первая строка сообщения попадает в changelog и на сайт. Она должна иметь форму: "Исправлено(worker, tt32453): в некоторых случаях не выставлялся счёт". Во второй строке, и далее, могут быть более подробные пояснения для разработчиков.
  * Лучше больше малых коммитов, чем один очень большой.
  * после внесения **любых**  изменений, обязательно тестирование. В т.ч. разработчик тестирует, что изменения не сломали код и старый функционал, тестируем что новый функционал работает как задумано, другие кейсы, которые разработчик посчитает необходимым проверить. По возможности отдаём приоритет авто-тестам
      * перед тестами полная пересборка продукта
      * отлаживаем **каждую строку**, даже если 1 байт исправления, в тч при исправлении комментариев, дебагов и текстовых строк, тк вероятность ошибки в каждой новой или исправленной строке всегда 100%
      * если Вы не можете или не хотите отладить и проверить строку, то **Категорически нельзя**  добавлять неотлаженную строку кода т.к. Вы создадите очень очень много проблем в будущем.
  * после тестирования, создаём реквесты при помощи merge_name2name. Если изменялись несколько репозиториев, то использовать merge_name2name обязательно(чтобы не возникало случаев, когда часть кода не попадает в слияние)
  * в **текст мердж реквеста тезисами пишем "как тестировали"**. Это напоминание, в первую очередь для себя, о правиле тестировать любые изменения. Так же для оценки(самооценки) полноты тестирования. Если не написали, то проводящий код-ревью, должен напомнить об обязательности проверки
  * если создали реквест преждевременно, то переводим его на себя или отменяем, в некоторых случаях допускается ставить статус WIP(например небольшие доработки). Не готовый реквест на проверяющего не вешаем. Это отвлекает.
  * если изменения сделаны не в той ветке, например запрос в интегру, а нужно исправить баг в мастере, то тоже **пишем об этом шапке запроса**, и молимся, чтобы принимающий реквест смог сделать автоматический черри пик в нужную ветку
  * после создания мердж реквестов, задача на скрам доске переезжает в колонку testing
  * ветку, где решали задачу менять нельзя, пока реквест не будет принят. Новую задачу решаем в другой ветке, например kolko2.
  * ревью изменений в основные ветки продукта **всегда**  проводит другой разработчик. Кто может проводит код-ревью определяет тим-лид продукта *.dev.teamlead
  * ревью изменений в основные ветки платформы: base, auth, common_scripts и т.п. выполняет руководитель процесса разработки devops.head
  * после внесения правок по результатам ревью, **выполняем пункт тестирование**, обновляем реквесты
  * Когда задача находится в режиме приема реквеста - ответственный за нее остается исполнитель. Он заинтересован, чтобы ревьювер его не продинамил и принял мерж-реквест. Поэтому, если ревью давно не принимают - он должен подойти к ревьюверу лично. Если ревьювер занят и не может провести ревью - он говорит время, когда к нему можно подойти (см. правила решения задач).
      * На скраме мы не спрашиваем ревьюверов, почему они приняли/не приняли/когда примут реквест. Мы это спрашиваем у ответственного по задаче, когда он договорится с его ревьювером.
  * задача считается решённой и переносится в Done, только после **слияния изменений с нужной веткой**. Пока реквест не принят, задача считается не решённой
  * Для Подтверждение закрытия задачи обязтаельно добавляем скрины и или дифф коммита в задачу или в комент.

Примечания:

  * Все разработчики раз в день (если высокая нагрузка, то реже) просматривают в 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|strongbash]] \\
[[:соглашения_кода:python|python]]

[[:foxdev_7:контроль_версий_сборка_тестирование|Читать далее: контроль версий, сборка и тестирование]]

~~OWNERAPPROVE~~