Инструкция Программиста
Различия
Здесь показаны различия между двумя версиями данной страницы.
| Предыдущая версия справа и слева Предыдущая версия Следующая версия | Предыдущая версия | ||
|
foxdev_7:инструкция_программиста [29.01.2018 06:25] nikolay_carbonsoft1 Approved(admin 2018/03/02 05:22) |
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% | + | * выбираем базовую ветку в которые изменения должны попасть: |
| - | * если Вы не можете или не хотите отладить и проверить строку, то **Категорически нельзя** добавлять неотлаженную строку кода т.к. Вы создадите очень очень много проблем в будущем. | + | * баги/хотфиксы/критичный функционал для определённой ветки. Например мастер(если баг мастера). |
| - | * от изменения кода до отладки **не более 3 секунд**, если требуется, делаем скрипт копирования только нужных файлов и рестарт нужных служб. Не делаем полную пересборку при отладке! | + | * фичи, рефакторинг, крупные правки некритичных багов - интегра |
| - | * git add -p - вносим изменения построчно, особенно проверяем, что ничего лишнего и временного и отладочного не попало в коммит. | + | * задача всегда решается разработчиком в отдельной ветке, **созданной от базовой**. |
| - | * git add имя_нового_файла - добавляем новый файл или git rm имя_файла удаляем лишние файлы. | + | * если ветка старая - обновить до начала работы(pull, reset и т.д.) |
| + | * запрещено решать несколько не связанных задач в одной ветке | ||
| + | * от изменения кода до отладки **не более 3 секунд**, если требуется, делаем скрипт копирования только нужных файлов и рестарт нужных служб. Не делаем полную пересборку при отладке! | ||
| + | * Всегда смотрим изменения, которые коммитим: git add -p или git commit -v. Чтобы нежелательные изменения(отладка, и т.п.) не попали в продукт | ||
| * **Категорически запрещено** делать "git add ." и "git commit -am" это гарантированный пропуск бага. | * **Категорически запрещено** делать "git add ." и "git commit -am" это гарантированный пропуск бага. | ||
| - | * git commit -m 'Не закрывалась форма логона в firefox' или 'Добавлена печать карточки пользователя' - Создаем коммит русским, понятным простому пользователю языком. Все изменения автоматом попадают в ChangeLog на сайт и в продукт. Лучше больше малых коммитов, чем один очень большой. | + | * Создаем сообщение коммита русским, понятным простому пользователю языком, в обезличенной форме. Первая строка сообщения попадает в changelog и на сайт. Она должна иметь форму: "Исправлено(worker, tt32453): в некоторых случаях не выставлялся счёт". Во второй строке, и далее, могут быть более подробные пояснения для разработчиков. |
| - | * git status - добиваемся чистого вывода. | + | * Лучше больше малых коммитов, чем один очень большой. |
| - | * git pull - подгружаем текущие изменения, проверяем и разрешаем конфликты. | + | * после внесения **любых** изменений, обязательно тестирование. В т.ч. разработчик тестирует, что изменения не сломали код и старый функционал, тестируем что новый функционал работает как задумано, другие кейсы, которые разработчик посчитает необходимым проверить. По возможности отдаём приоритет авто-тестам |
| - | * git push origin kolko1 - отправляем в свою ветку в gitlab. | + | * перед тестами полная пересборка продукта |
| - | - Делаем полную пересборку вашей ветки, проводим ручное тестирование основных кейсов использования изменений и fast-autotest. | + | * отлаживаем **каждую строку**, даже если 1 байт исправления, в тч при исправлении комментариев, дебагов и текстовых строк, тк вероятность ошибки в каждой новой или исправленной строке всегда 100% |
| - | - Если все тесты прошли успешно: | + | * если Вы не можете или не хотите отладить и проверить строку, то **Категорически нельзя** добавлять неотлаженную строку кода т.к. Вы создадите очень очень много проблем в будущем. |
| - | * Спец.утилитой создается merge-request из вашего текущего бранча kolko1 в Integra по всем измененным репозиториям. Утилита сама выберет Вашего парного codereviewer'а. Либо имя можно указать параметром. | + | * после тестирования, создаём реквесты при помощи merge_name2name. Если изменялись несколько репозиториев, то использовать merge_name2name обязательно(чтобы не возникало случаев, когда часть кода не попадает в слияние) |
| - | * Закрываем задачу в трекере. | + | * в **текст мердж реквеста тезисами пишем "как тестировали"**. Это напоминание, в первую очередь для себя, о правиле тестировать любые изменения. Так же для оценки(самооценки) полноты тестирования. Если не написали, то проводящий код-ревью, должен напомнить об обязательности проверки |
| - | * Пьем чай с ништяками. | + | * если создали реквест преждевременно, то переводим его на себя или отменяем, в некоторых случаях допускается ставить статус WIP(например небольшие доработки). Не готовый реквест на проверяющего не вешаем. Это отвлекает. |
| - | * После merge-request нельзя ничего менять в kolko1 он залочен, новую задачу решаем в kolko2. | + | * если изменения сделаны не в той ветке, например запрос в интегру, а нужно исправить баг в мастере, то тоже **пишем об этом шапке запроса**, и молимся, чтобы принимающий реквест смог сделать автоматический черри пик в нужную ветку |
| - | * Codereviewer просмотрев код и, посчитав его нормальным, принимает merge-request из kolko1 в Integra, после этого бранч kolko1 разблокируется. Если с кодом проблемы, то проводятся доработки и бранч остается заблокированным. | + | * после создания мердж реквестов, задача на скрам доске переезжает в колонку testing |
| - | - На ближайшем скраме скрам-мастер спрашивает про Вашу задачу и переводит Закрытую задачу в колонку Done или AlarmDone. | + | * ветку, где решали задачу менять нельзя, пока реквест не будет принят. Новую задачу решаем в другой ветке, например kolko2. |
| + | * ревью изменений в основные ветки продукта **всегда** проводит другой разработчик. Кто может проводит код-ревью определяет тим-лид продукта *.dev.teamlead | ||
| + | * ревью изменений в основные ветки платформы: base, auth, common_scripts и т.п. выполняет руководитель процесса разработки devops.head | ||
| + | * после внесения правок по результатам ревью, **выполняем пункт тестирование**, обновляем реквесты | ||
| + | * Когда задача находится в режиме приема реквеста - ответственный за нее остается исполнитель. Он заинтересован, чтобы ревьювер его не продинамил и принял мерж-реквест. Поэтому, если ревью давно не принимают - он должен подойти к ревьюверу лично. Если ревьювер занят и не может провести ревью - он говорит время, когда к нему можно подойти (см. правила решения задач). | ||
| + | * На скраме мы не спрашиваем ревьюверов, почему они приняли/не приняли/когда примут реквест. Мы это спрашиваем у ответственного по задаче, когда он договорится с его ревьювером. | ||
| + | * задача считается решённой и переносится в Done, только после **слияния изменений с нужной веткой**. Пока реквест не принят, задача считается не решённой | ||
| + | * Для Подтверждение закрытия задачи обязтаельно добавляем скрины и или дифф коммита в задачу или в комент. | ||
| Примечания: | Примечания: | ||
| + | * Все разработчики раз в день (если высокая нагрузка, то реже) просматривают в gitlab список открытых на них реквестов. Если обнаружены проблемы: пишут об этом комментарий или сообщают лично, заявку при этом не закрываем - свои незакрытые реквесты просматривает разработчики. Закрытые по ошибке реквесты должны пересоздаваться спец.утилитой. | ||
| + | * Разработчик раз в день (или чаще) просматривает список своих реквестов. Приняли ли их, что нужно исправить. Если реквест очень срочный - он может подойти к ревьюверу лично или позвонить. | ||
| * Запрещено двигать задачи на скрам-доске, это делает только скрам-мастер. | * Запрещено двигать задачи на скрам-доске, это делает только скрам-мастер. | ||
| * Решаем только задачи которые есть на скрам-доске и прикреплена к колонке "N день". | * Решаем только задачи которые есть на скрам-доске и прикреплена к колонке "N день". | ||
| * Категорически запрещено решать задачу, если ее нет на скрам доске. | * Категорически запрещено решать задачу, если ее нет на скрам доске. | ||
| - | * Если решили задачу раньше скрама, выбираете следующую вместе со скрам-мастером или сами если срам-мастер разрешает. | + | * Если решили задачу раньше скрама, выбираете следующую вместе со скрам-мастером или сами если скрам-мастер разрешает. |
| * Если возникла внеплановая аларм-задача или личная инициативная задача, то создается листок задачи и прикрепляется на колонку "1 день" и уведомляем скрам-мастера. | * Если возникла внеплановая аларм-задача или личная инициативная задача, то создается листок задачи и прикрепляется на колонку "1 день" и уведомляем скрам-мастера. | ||
| * Ежедневно на скраме скрам-мастер сдвигает задачу на один день влево, если задача дошла до 3 дня привлекается помощник. | * Ежедневно на скраме скрам-мастер сдвигает задачу на один день влево, если задача дошла до 3 дня привлекается помощник. | ||
| * Если потребуются доработки будет создана отдельная задача. | * Если потребуются доработки будет создана отдельная задача. | ||
| - | * git commit -am 'Deleted some files' можно использовать только для подтверждения удаления множества файлов, после внесения остальныз изменнеия командой git add -p | + | * git commit -am 'Deleted some files' можно использовать только для подтверждения удаления множества файлов, после внесения остальные изменения командой git add -p |
| - | ==== Пример ==== | + | ==== Инструментарий разработки ==== |
| - | + | ||
| - | TODO Здесь пример добавит кто то. | + | |
| - | + | ||
| - | ==== Интструментарий разработки ==== | + | |
| * Все ножницы должны быть одинаковы. Всегда и у всех в пределах одного проекта используются одинаковые, согласованные инструменты разработки и отладки. Все типовые инструменты должны быть установлены на рабочем месте утилитой crab либо руками. Инструменты должны быть одной версии. Если используете сторонние инструменты, то все равно все типовые инструменты должны быть установлены. | * Все ножницы должны быть одинаковы. Всегда и у всех в пределах одного проекта используются одинаковые, согласованные инструменты разработки и отладки. Все типовые инструменты должны быть установлены на рабочем месте утилитой crab либо руками. Инструменты должны быть одной версии. Если используете сторонние инструменты, то все равно все типовые инструменты должны быть установлены. | ||
| Строка 71: | Строка 79: | ||
| * Попутно с основной задачей нельзя исправлять код никакой никогда, если увидели багу - создайте задачу. Если все таки попутно поправили то обязательно отладьте и протестируйте. | * Попутно с основной задачей нельзя исправлять код никакой никогда, если увидели багу - создайте задачу. Если все таки попутно поправили то обязательно отладьте и протестируйте. | ||
| - | Тиражируемый софт | + | === Критичные правила. Тиражируемый софт === |
| * Никогда не делайте массовых обновлений, делаем 10 потом 50 потом далее. | * Никогда не делайте массовых обновлений, делаем 10 потом 50 потом далее. | ||
| Строка 81: | Строка 89: | ||
| * Встроенные средства резервного копирования, работающие из коробки, для восстановления данных пользователя из-за ошибок программ и пользователей. | * Встроенные средства резервного копирования, работающие из коробки, для восстановления данных пользователя из-за ошибок программ и пользователей. | ||
| * Все изменения устанавливаемые клиентам должны быть в тот же день внесены в дистрибутив в свою, клиентскую или временную ветку, до ухода домой. | * Все изменения устанавливаемые клиентам должны быть в тот же день внесены в дистрибутив в свою, клиентскую или временную ветку, до ухода домой. | ||
| + | * Запрещено делать "плохой" дизайн, дизайн должен быть "терпимым". Если не знаете как сделать, советуйтесь с коллегами. По задачам связанным с фронтендом скриншот добавить в решение задачи. | ||
| ==== Время работы и правила в офисе ==== | ==== Время работы и правила в офисе ==== | ||
| Строка 101: | Строка 110: | ||
| * Обязательно используем блокнот с горячей клавишей для мелких задач и буфера обмена. | * Обязательно используем блокнот с горячей клавишей для мелких задач и буфера обмена. | ||
| - | ==== Ссылки на отдельные инструкции по яыкам ==== | + | ==== Ссылки на отдельные инструкции по языкам ==== |
| [[:соглашения_кода:strongbash|strongbash]] \\ | [[:соглашения_кода:strongbash|strongbash]] \\ | ||
| [[:соглашения_кода:python|python]] | [[:соглашения_кода:python|python]] | ||
| - | [[:open_carbon_7:контроль_версий_сборка_тестирование|Читать далее: контроль версий, сборка и тестирование]] | + | [[:foxdev_7:контроль_версий_сборка_тестирование|Читать далее: контроль версий, сборка и тестирование]] |
| + | |||
| + | ~~OWNERAPPROVE~~ | ||
nikolay_carbonsoft1