Инструкция Программиста
Различия
Здесь показаны различия между двумя версиями данной страницы.
Предыдущая версия справа и слева Предыдущая версия Следующая версия | Предыдущая версия | ||
foxdev_7:инструкция_программиста [10.05.2019 23:08] admin ↷ Страница перемещена из open_carbon_7:инструкция_программиста в foxdev_7:инструкция_программиста |
foxdev_7:инструкция_программиста [20.03.2021 08:34] (текущий) admin |
||
---|---|---|---|
Строка 7: | Строка 7: | ||
После отладки и тестирования все изменения личного бранча мерджатся реквестом в бранч Interga. | После отладки и тестирования все изменения личного бранча мерджатся реквестом в бранч Interga. | ||
- | ==== Процесс решения задач ==== | + | ==== Правила решения задач ==== |
- | - Задачу выбираем из своего стека скрам-доски, во время скрама, с учетом текущих приоритетов. Скрам-мастер сдвигает задачу на колонку "1 день". | + | Основано на реальных событиях. |
- | - Проверяем, что у задачи стоит длительность 0.5 или 1 день. Без длительности задачу не решаем, если больше дня, то декомпозируем. | + | |
- | - Обязательно получаем **устные** уточнения по задаче и устно предлагаем решение в тч интерфейс и аргументы и тп. | + | * Смотреть общие правила [[https://wika.carbonsoft.ru/carbon_soft:общие_инструкции:как_решать_задачи|https://wika.carbonsoft.ru/carbon_soft:общие_инструкции:как_решать_задачи]] |
- | - Если это Bug, то обязательно лично воспроизводим на **своей** виртуалке и только потом решаем. | + | * Задачу выбираем из своего стека скрам-доски, во время скрама, с учетом текущих приоритетов. Скрам-мастер сдвигает задачу на колонку "1 день". |
- | - Выбираем свой свободный branch, который уже замерджен в Integra. Обычно это попеременно $login1 и $login2, например kolko1 и kolko2. Нельзя решать более одной задачи в одном branch. | + | * Проверяем, что у задачи стоит длительность 0.5 или 1 день. Без длительности задачу не решаем, если больше дня, то декомпозируем. |
- | - Работа с кодом: | + | * Обязательно получаем **устные** уточнения по задаче и устно предлагаем решение в тч интерфейс и аргументы и тп. |
- | * git status - проверяем, что нет локальных изменений. | + | * Если это Bug, то обязательно лично воспроизводим на **своей** виртуалке и только потом решаем. |
- | * git pull - подгружаем последние изменения. | + | * до начала изменения кода, определяем: категорию, масштаб проблемы/задачи |
- | * еще раз git status - убеждаемся, что нет конфликтов. | + | * если задача из категории "запрещённых"(изменения архитектуры), то решаем их по процедуре через технический комитет. Полный список "запрещённых" задач и правила их решения смотрим в должностных инструкциях [[https://wika.carbonsoft.ru/отдел_разработки:инструкции_должностные:должностная_программист|https://wika.carbonsoft.ru/отдел_разработки:инструкции_должностные:должностная_программист]] |
- | * меняем/создаем код, соблюдаем codestyle и соглашения кода. | + | * если задача не "запрещённая", обсуждение проблемы и решения - приветствуется |
+ | * выбираем базовую ветку в которые изменения должны попасть: | ||
+ | * баги/хотфиксы/критичный функционал для определённой ветки. Например мастер(если баг мастера). | ||
+ | * фичи, рефакторинг, крупные правки некритичных багов - интегра | ||
+ | * задача всегда решается разработчиком в отдельной ветке, **созданной от базовой**. | ||
+ | * если ветка старая - обновить до начала работы(pull, reset и т.д.) | ||
+ | * запрещено решать несколько не связанных задач в одной ветке | ||
+ | * от изменения кода до отладки **не более 3 секунд**, если требуется, делаем скрипт копирования только нужных файлов и рестарт нужных служб. Не делаем полную пересборку при отладке! | ||
+ | * Всегда смотрим изменения, которые коммитим: git add -p или git commit -v. Чтобы нежелательные изменения(отладка, и т.п.) не попали в продукт | ||
+ | * **Категорически запрещено** делать "git add ." и "git commit -am" это гарантированный пропуск бага. | ||
+ | * Создаем сообщение коммита русским, понятным простому пользователю языком, в обезличенной форме. Первая строка сообщения попадает в changelog и на сайт. Она должна иметь форму: "Исправлено(worker, tt32453): в некоторых случаях не выставлялся счёт". Во второй строке, и далее, могут быть более подробные пояснения для разработчиков. | ||
+ | * Лучше больше малых коммитов, чем один очень большой. | ||
+ | * после внесения **любых** изменений, обязательно тестирование. В т.ч. разработчик тестирует, что изменения не сломали код и старый функционал, тестируем что новый функционал работает как задумано, другие кейсы, которые разработчик посчитает необходимым проверить. По возможности отдаём приоритет авто-тестам | ||
+ | * перед тестами полная пересборка продукта | ||
* отлаживаем **каждую строку**, даже если 1 байт исправления, в тч при исправлении комментариев, дебагов и текстовых строк, тк вероятность ошибки в каждой новой или исправленной строке всегда 100% | * отлаживаем **каждую строку**, даже если 1 байт исправления, в тч при исправлении комментариев, дебагов и текстовых строк, тк вероятность ошибки в каждой новой или исправленной строке всегда 100% | ||
* если Вы не можете или не хотите отладить и проверить строку, то **Категорически нельзя** добавлять неотлаженную строку кода т.к. Вы создадите очень очень много проблем в будущем. | * если Вы не можете или не хотите отладить и проверить строку, то **Категорически нельзя** добавлять неотлаженную строку кода т.к. Вы создадите очень очень много проблем в будущем. | ||
- | * от изменения кода до отладки **не более 3 секунд**, если требуется, делаем скрипт копирования только нужных файлов и рестарт нужных служб. Не делаем полную пересборку при отладке! | + | * после тестирования, создаём реквесты при помощи merge_name2name. Если изменялись несколько репозиториев, то использовать merge_name2name обязательно(чтобы не возникало случаев, когда часть кода не попадает в слияние) |
- | * git add -p - вносим изменения построчно, особенно проверяем, что ничего лишнего и временного и отладочного не попало в коммит. | + | * в **текст мердж реквеста тезисами пишем "как тестировали"**. Это напоминание, в первую очередь для себя, о правиле тестировать любые изменения. Так же для оценки(самооценки) полноты тестирования. Если не написали, то проводящий код-ревью, должен напомнить об обязательности проверки |
- | * git add имя_нового_файла - добавляем новый файл или git rm имя_файла удаляем лишние файлы. | + | * если создали реквест преждевременно, то переводим его на себя или отменяем, в некоторых случаях допускается ставить статус WIP(например небольшие доработки). Не готовый реквест на проверяющего не вешаем. Это отвлекает. |
- | * **Категорически запрещено** делать "git add ." и "git commit -am" это гарантированный пропуск бага. | + | * если изменения сделаны не в той ветке, например запрос в интегру, а нужно исправить баг в мастере, то тоже **пишем об этом шапке запроса**, и молимся, чтобы принимающий реквест смог сделать автоматический черри пик в нужную ветку |
- | * git commit -m 'Fixed(сайт): Не закрывалась форма логона в firefox' или 'Добавлена печать карточки пользователя' - Создаем коммит русским, понятным простому пользователю языком. Все изменения автоматом попадают в ChangeLog на сайт и в продукт. Лучше больше малых коммитов, чем один очень большой. | + | * после создания мердж реквестов, задача на скрам доске переезжает в колонку testing |
- | * git status - добиваемся чистого вывода. | + | * ветку, где решали задачу менять нельзя, пока реквест не будет принят. Новую задачу решаем в другой ветке, например kolko2. |
- | * git pull - подгружаем текущие изменения, проверяем и разрешаем конфликты. | + | * ревью изменений в основные ветки продукта **всегда** проводит другой разработчик. Кто может проводит код-ревью определяет тим-лид продукта *.dev.teamlead |
- | * git push origin kolko1 - отправляем в свою ветку в gitlab. | + | * ревью изменений в основные ветки платформы: base, auth, common_scripts и т.п. выполняет руководитель процесса разработки devops.head |
- | - Делаем полную пересборку вашей ветки, проводим ручное тестирование основных кейсов использования изменений и fast-autotest. | + | * после внесения правок по результатам ревью, **выполняем пункт тестирование**, обновляем реквесты |
- | - Если все тесты прошли успешно, код передается на codereview: | + | * Когда задача находится в режиме приема реквеста - ответственный за нее остается исполнитель. Он заинтересован, чтобы ревьювер его не продинамил и принял мерж-реквест. Поэтому, если ревью давно не принимают - он должен подойти к ревьюверу лично. Если ревьювер занят и не может провести ревью - он говорит время, когда к нему можно подойти (см. правила решения задач). |
- | * Спец.утилитой создается merge-request из вашего текущего бранча kolko1 в Integra по всем измененным репозиториям. Утилита сама выберет Вашего парного codereviewer'а. Либо имя можно указать параметром. | + | |
- | * После merge-request нельзя ничего менять в kolko1 он залочен, новую задачу решаем в kolko2. | + | |
- | * Codereviewer просмотрев код и, посчитав его нормальным, принимает merge-request из kolko1 в Integra, после этого бранч kolko1 разблокируется. Если с кодом проблемы, то проводятся доработки и бранч остается заблокированным. | + | |
- | * Когда задача находится в режиме приема реквеста - ответственный за нее остается исполнитель. Он заинтересован, чтобы ревьювер его не продинамил и принял мерж-реквест. Поэтому, если ревью давно не принимают - он должен подойти к ревьюверу лично. Если ревьювер занят и не может провести ревью - он говорит время, когда к нему можно подойти (см. правила решения задач). | + | |
- | - На скраме: | + | |
* На скраме мы не спрашиваем ревьюверов, почему они приняли/не приняли/когда примут реквест. Мы это спрашиваем у ответственного по задаче, когда он договорится с его ревьювером. | * На скраме мы не спрашиваем ревьюверов, почему они приняли/не приняли/когда примут реквест. Мы это спрашиваем у ответственного по задаче, когда он договорится с его ревьювером. | ||
- | * Если задача находится на codereview, заявка вешается в колонку "Test". | + | * задача считается решённой и переносится в Done, только после **слияния изменений с нужной веткой**. Пока реквест не принят, задача считается не решённой |
- | - Когда задача успешно прошла codereview, на близжайшем скраме переводим задачу в колонку Done или AlarmDone. | + | * Для Подтверждение закрытия задачи обязтаельно добавляем скрины и или дифф коммита в задачу или в комент. |
Примечания: | Примечания: | ||
* Все разработчики раз в день (если высокая нагрузка, то реже) просматривают в gitlab список открытых на них реквестов. Если обнаружены проблемы: пишут об этом комментарий или сообщают лично, заявку при этом не закрываем - свои незакрытые реквесты просматривает разработчики. Закрытые по ошибке реквесты должны пересоздаваться спец.утилитой. | * Все разработчики раз в день (если высокая нагрузка, то реже) просматривают в gitlab список открытых на них реквестов. Если обнаружены проблемы: пишут об этом комментарий или сообщают лично, заявку при этом не закрываем - свои незакрытые реквесты просматривает разработчики. Закрытые по ошибке реквесты должны пересоздаваться спец.утилитой. | ||
- | * Разработчик раз в день (или чаще) просматривает список своих реквестов. Приняли ли их, что нужно исправить. Если реквест очень срочный - он может подойти к ревьюверу лично или позвонить. | + | * Разработчик раз в день (или чаще) просматривает список своих реквестов. Приняли ли их, что нужно исправить. Если реквест очень срочный - он может подойти к ревьюверу лично или позвонить. |
* Запрещено двигать задачи на скрам-доске, это делает только скрам-мастер. | * Запрещено двигать задачи на скрам-доске, это делает только скрам-мастер. | ||
* Решаем только задачи которые есть на скрам-доске и прикреплена к колонке "N день". | * Решаем только задачи которые есть на скрам-доске и прикреплена к колонке "N день". | ||
Строка 71: | Строка 79: | ||
* Попутно с основной задачей нельзя исправлять код никакой никогда, если увидели багу - создайте задачу. Если все таки попутно поправили то обязательно отладьте и протестируйте. | * Попутно с основной задачей нельзя исправлять код никакой никогда, если увидели багу - создайте задачу. Если все таки попутно поправили то обязательно отладьте и протестируйте. | ||
- | === Критичные правила. Тиражируемый софт === | + | === Критичные правила. Тиражируемый софт === |
* Никогда не делайте массовых обновлений, делаем 10 потом 50 потом далее. | * Никогда не делайте массовых обновлений, делаем 10 потом 50 потом далее. | ||
Строка 81: | Строка 89: | ||
* Встроенные средства резервного копирования, работающие из коробки, для восстановления данных пользователя из-за ошибок программ и пользователей. | * Встроенные средства резервного копирования, работающие из коробки, для восстановления данных пользователя из-за ошибок программ и пользователей. | ||
* Все изменения устанавливаемые клиентам должны быть в тот же день внесены в дистрибутив в свою, клиентскую или временную ветку, до ухода домой. | * Все изменения устанавливаемые клиентам должны быть в тот же день внесены в дистрибутив в свою, клиентскую или временную ветку, до ухода домой. | ||
+ | * Запрещено делать "плохой" дизайн, дизайн должен быть "терпимым". Если не знаете как сделать, советуйтесь с коллегами. По задачам связанным с фронтендом скриншот добавить в решение задачи. | ||
==== Время работы и правила в офисе ==== | ==== Время работы и правила в офисе ==== | ||
Строка 106: | Строка 115: | ||
[[:соглашения_кода:python|python]] | [[:соглашения_кода:python|python]] | ||
- | [[:open_carbon_7:контроль_версий_сборка_тестирование|Читать далее: контроль версий, сборка и тестирование]] | + | [[:foxdev_7:контроль_версий_сборка_тестирование|Читать далее: контроль версий, сборка и тестирование]] |
~~OWNERAPPROVE~~ | ~~OWNERAPPROVE~~ | ||