Инструкция Программиста
Различия
Здесь показаны различия между двумя версиями данной страницы.
| Предыдущая версия справа и слева Предыдущая версия Следующая версия | Предыдущая версия | ||
|
foxdev_7:инструкция_программиста [15.10.2018 11:19] nikolay_carbonsoft1 Approved(admin 2018/12/04 07:28) |
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 и соглашения кода. | + | * если задача не "запрещённая", обсуждение проблемы и решения - приветствуется |
| - | * отлаживаем **каждую строку**, даже если 1 байт исправления, в тч при исправлении комментариев, дебагов и текстовых строк, тк вероятность ошибки в каждой строке всегда 100% | + | * выбираем базовую ветку в которые изменения должны попасть: |
| + | * баги/хотфиксы/критичный функционал для определённой ветки. Например мастер(если баг мастера). | ||
| + | * фичи, рефакторинг, крупные правки некритичных багов - интегра | ||
| + | * задача всегда решается разработчиком в отдельной ветке, **созданной от базовой**. | ||
| + | * если ветка старая - обновить до начала работы(pull, reset и т.д.) | ||
| + | * запрещено решать несколько не связанных задач в одной ветке | ||
| + | * от изменения кода до отладки **не более 3 секунд**, если требуется, делаем скрипт копирования только нужных файлов и рестарт нужных служб. Не делаем полную пересборку при отладке! | ||
| + | * Всегда смотрим изменения, которые коммитим: git add -p или git commit -v. Чтобы нежелательные изменения(отладка, и т.п.) не попали в продукт | ||
| + | * **Категорически запрещено** делать "git add ." и "git commit -am" это гарантированный пропуск бага. | ||
| + | * Создаем сообщение коммита русским, понятным простому пользователю языком, в обезличенной форме. Первая строка сообщения попадает в changelog и на сайт. Она должна иметь форму: "Исправлено(worker, tt32453): в некоторых случаях не выставлялся счёт". Во второй строке, и далее, могут быть более подробные пояснения для разработчиков. | ||
| + | * Лучше больше малых коммитов, чем один очень большой. | ||
| + | * после внесения **любых** изменений, обязательно тестирование. В т.ч. разработчик тестирует, что изменения не сломали код и старый функционал, тестируем что новый функционал работает как задумано, другие кейсы, которые разработчик посчитает необходимым проверить. По возможности отдаём приоритет авто-тестам | ||
| + | * перед тестами полная пересборка продукта | ||
| + | * отлаживаем **каждую строку**, даже если 1 байт исправления, в тч при исправлении комментариев, дебагов и текстовых строк, тк вероятность ошибки в каждой новой или исправленной строке всегда 100% | ||
| * если Вы не можете или не хотите отладить и проверить строку, то **Категорически нельзя** добавлять неотлаженную строку кода т.к. Вы создадите очень очень много проблем в будущем. | * если Вы не можете или не хотите отладить и проверить строку, то **Категорически нельзя** добавлять неотлаженную строку кода т.к. Вы создадите очень очень много проблем в будущем. | ||
| - | * от изменения кода до отладки **не более 3 секунд**, если требуется, делаем скрипт копирования только нужных файлов и рестарт нужных служб. Не делаем полную пересборку при отладке! | + | * после тестирования, создаём реквесты при помощи merge_name2name. Если изменялись несколько репозиториев, то использовать merge_name2name обязательно(чтобы не возникало случаев, когда часть кода не попадает в слияние) |
| - | * git add -p - вносим изменения построчно, особенно проверяем, что ничего лишнего и временного и отладочного не попало в коммит. | + | * в **текст мердж реквеста тезисами пишем "как тестировали"**. Это напоминание, в первую очередь для себя, о правиле тестировать любые изменения. Так же для оценки(самооценки) полноты тестирования. Если не написали, то проводящий код-ревью, должен напомнить об обязательности проверки |
| - | * git add имя_нового_файла - добавляем новый файл или git rm имя_файла удаляем лишние файлы. | + | * если создали реквест преждевременно, то переводим его на себя или отменяем, в некоторых случаях допускается ставить статус WIP(например небольшие доработки). Не готовый реквест на проверяющего не вешаем. Это отвлекает. |
| - | * **Категорически запрещено** делать "git add ." и "git commit -am" это гарантированный пропуск бага. | + | * если изменения сделаны не в той ветке, например запрос в интегру, а нужно исправить баг в мастере, то тоже **пишем об этом шапке запроса**, и молимся, чтобы принимающий реквест смог сделать автоматический черри пик в нужную ветку |
| - | * git commit -m 'Не закрывалась форма логона в 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 день". | ||
| Строка 51: | Строка 59: | ||
| * Ежедневно на скраме скрам-мастер сдвигает задачу на один день влево, если задача дошла до 3 дня привлекается помощник. | * Ежедневно на скраме скрам-мастер сдвигает задачу на один день влево, если задача дошла до 3 дня привлекается помощник. | ||
| * Если потребуются доработки будет создана отдельная задача. | * Если потребуются доработки будет создана отдельная задача. | ||
| - | * git commit -am 'Deleted some files' можно использовать только для подтверждения удаления множества файлов, после внесения остальныз изменнеия командой git add -p | + | * git commit -am 'Deleted some files' можно использовать только для подтверждения удаления множества файлов, после внесения остальные изменения командой git add -p |
| - | + | ||
| - | ==== Пример ==== | + | |
| - | + | ||
| - | TODO Здесь пример добавит кто то. | + | |
| - | ==== Интструментарий разработки ==== | + | ==== Инструментарий разработки ==== |
| * Все ножницы должны быть одинаковы. Всегда и у всех в пределах одного проекта используются одинаковые, согласованные инструменты разработки и отладки. Все типовые инструменты должны быть установлены на рабочем месте утилитой crab либо руками. Инструменты должны быть одной версии. Если используете сторонние инструменты, то все равно все типовые инструменты должны быть установлены. | * Все ножницы должны быть одинаковы. Всегда и у всех в пределах одного проекта используются одинаковые, согласованные инструменты разработки и отладки. Все типовые инструменты должны быть установлены на рабочем месте утилитой crab либо руками. Инструменты должны быть одной версии. Если используете сторонние инструменты, то все равно все типовые инструменты должны быть установлены. | ||
| Строка 75: | Строка 79: | ||
| * Попутно с основной задачей нельзя исправлять код никакой никогда, если увидели багу - создайте задачу. Если все таки попутно поправили то обязательно отладьте и протестируйте. | * Попутно с основной задачей нельзя исправлять код никакой никогда, если увидели багу - создайте задачу. Если все таки попутно поправили то обязательно отладьте и протестируйте. | ||
| - | Тиражируемый софт | + | === Критичные правила. Тиражируемый софт === |
| * Никогда не делайте массовых обновлений, делаем 10 потом 50 потом далее. | * Никогда не делайте массовых обновлений, делаем 10 потом 50 потом далее. | ||
| Строка 85: | Строка 89: | ||
| * Встроенные средства резервного копирования, работающие из коробки, для восстановления данных пользователя из-за ошибок программ и пользователей. | * Встроенные средства резервного копирования, работающие из коробки, для восстановления данных пользователя из-за ошибок программ и пользователей. | ||
| * Все изменения устанавливаемые клиентам должны быть в тот же день внесены в дистрибутив в свою, клиентскую или временную ветку, до ухода домой. | * Все изменения устанавливаемые клиентам должны быть в тот же день внесены в дистрибутив в свою, клиентскую или временную ветку, до ухода домой. | ||
| + | * Запрещено делать "плохой" дизайн, дизайн должен быть "терпимым". Если не знаете как сделать, советуйтесь с коллегами. По задачам связанным с фронтендом скриншот добавить в решение задачи. | ||
| ==== Время работы и правила в офисе ==== | ==== Время работы и правила в офисе ==== | ||
| Строка 105: | Строка 110: | ||
| * Обязательно используем блокнот с горячей клавишей для мелких задач и буфера обмена. | * Обязательно используем блокнот с горячей клавишей для мелких задач и буфера обмена. | ||
| - | ==== Ссылки на отдельные инструкции по яыкам ==== | + | ==== Ссылки на отдельные инструкции по языкам ==== |
| [[:соглашения_кода:strongbash|strongbash]] \\ | [[:соглашения_кода:strongbash|strongbash]] \\ | ||
| [[:соглашения_кода:python|python]] | [[:соглашения_кода:python|python]] | ||
| - | [[:open_carbon_7:контроль_версий_сборка_тестирование|Читать далее: контроль версий, сборка и тестирование]] | + | [[:foxdev_7:контроль_версий_сборка_тестирование|Читать далее: контроль версий, сборка и тестирование]] |
| ~~OWNERAPPROVE~~ | ~~OWNERAPPROVE~~ | ||
nikolay_carbonsoft1