Инструкция Программиста
Различия
Здесь показаны различия между двумя версиями данной страницы.
| Предыдущая версия справа и слева Предыдущая версия Следующая версия | Предыдущая версия | ||
|
foxdev_7:инструкция_программиста [22.12.2017 07:14] admin |
foxdev_7:инструкция_программиста [20.03.2021 08:34] (текущий) admin |
||
|---|---|---|---|
| Строка 1: | Строка 1: | ||
| {{indexmenu_n>35}} | {{indexmenu_n>35}} | ||
| + | |||
| ==== Вводные ==== | ==== Вводные ==== | ||
| + | |||
| Каждый программист имеет свою систему сборки и тестирования, свои бранчи.\\ | Каждый программист имеет свою систему сборки и тестирования, свои бранчи.\\ | ||
| Каждый программист может собрать, отладить и протестировать свой личный дистрибутив продукта независимо от серверов CI.\\ | Каждый программист может собрать, отладить и протестировать свой личный дистрибутив продукта независимо от серверов CI.\\ | ||
| После отладки и тестирования все изменения личного бранча мерджатся реквестом в бранч Interga. | После отладки и тестирования все изменения личного бранча мерджатся реквестом в бранч Interga. | ||
| - | ==== Процесс решения задач ==== | + | |
| - | - Задачу выбираем из своего стека скрам-доски, во время сркама, с учетом текущих приоритетов. Скрам-мастер сдвигает задачу на колонку "1 день". | + | ==== Правила решения задач ==== |
| - | - Проверяем, что у задачи стоит длительность 0.5 или 1 день. Без длительности задачу не решаем, если больше дня, то декомпозируем. | + | |
| - | - Обязательно получаем **устные** уточнения по задаче и устно предлагаем решение в тч интерфейс и аргументы и тп. | + | Основано на реальных событиях. |
| - | - Если это Bug, то обязательно лично воспроизводим на **своей** виртуалке и только потом решаем. | + | |
| - | - Выбираем свой свободный branch, который уже замерджен в Integra. Обычно это попеременно $login1 и $login2, например kolko1 и kolko2. Нельзя решать более одной задачи в одном branch. | + | * Смотреть общие правила [[https://wika.carbonsoft.ru/carbon_soft:общие_инструкции:как_решать_задачи|https://wika.carbonsoft.ru/carbon_soft:общие_инструкции:как_решать_задачи]] |
| - | - Работа с кодом: | + | * Задачу выбираем из своего стека скрам-доски, во время скрама, с учетом текущих приоритетов. Скрам-мастер сдвигает задачу на колонку "1 день". |
| - | * git status - проверяем, что нет локальных изменений. | + | * Проверяем, что у задачи стоит длительность 0.5 или 1 день. Без длительности задачу не решаем, если больше дня, то декомпозируем. |
| - | * git pull - подгружаем последние изменения. | + | * Обязательно получаем **устные** уточнения по задаче и устно предлагаем решение в тч интерфейс и аргументы и тп. |
| - | * еще раз git status - убеждаемся, что нет конфликтов. | + | * Если это Bug, то обязательно лично воспроизводим на **своей** виртуалке и только потом решаем. |
| - | * меняем/создаем код, соблюдаем codestyle и соглашения кода. | + | * до начала изменения кода, определяем: категорию, масштаб проблемы/задачи |
| - | * отлаживаем **каждую строку**, даже если 1 байт исправления, в тч при исправлении комментариев, дебагов и текстовых строк, тк вероятность ошибки в каждой строке всегда 100% | + | * если задача из категории "запрещённых"(изменения архитектуры), то решаем их по процедуре через технический комитет. Полный список "запрещённых" задач и правила их решения смотрим в должностных инструкциях [[https://wika.carbonsoft.ru/отдел_разработки:инструкции_должностные:должностная_программист|https://wika.carbonsoft.ru/отдел_разработки:инструкции_должностные:должностная_программист]] |
| - | * если Вы не можете или не хотите отладить и проверить строку, то **Категорически нельзя** добавлять неотлаженную строку кода т.к. Вы создадите очень очень много проблем в будущем. | + | * если задача не "запрещённая", обсуждение проблемы и решения - приветствуется |
| - | * от изменения кода до отладки **не более 3 секунд**, если требуется, делаем скрипт копирования только нужных файлов и рестарт нужных служб. Не делаем полную пересборку при отладке! | + | * выбираем базовую ветку в которые изменения должны попасть: |
| - | * git add -p - вносим изменения построчно, особенно проверяем, что ничего лишнего и временного и отладочного не попало в коммит. | + | * баги/хотфиксы/критичный функционал для определённой ветки. Например мастер(если баг мастера). |
| - | * git add имя_нового_файла - добавляем новый файл или git rm имя_файла удаляем лишние файлы. | + | * фичи, рефакторинг, крупные правки некритичных багов - интегра |
| - | * **Категорически запрещено** делать "git add ." и "git commit -am" это гарантированный пропуск бага. | + | * задача всегда решается разработчиком в отдельной ветке, **созданной от базовой**. |
| - | * git commit -m 'Не закрывалась форма логона в firefox' или 'Добавлена печать карточки пользователя' - Создаем коммит русским, понятным простому пользователю языком. Все изменения автоматом попадают в ChangeLog на сайт и в продукт. Лучше больше малых коммитов, чем один очень большой. | + | * если ветка старая - обновить до начала работы(pull, reset и т.д.) |
| - | * git status - добиваемся чистого вывода. | + | * запрещено решать несколько не связанных задач в одной ветке |
| - | * git pull - подгружаем текущие изменения, проверяем и разрешаем конфликты. | + | * от изменения кода до отладки **не более 3 секунд**, если требуется, делаем скрипт копирования только нужных файлов и рестарт нужных служб. Не делаем полную пересборку при отладке! |
| - | * git push origin kolko1 - отправляем в свою ветку в gitlab. | + | * Всегда смотрим изменения, которые коммитим: git add -p или git commit -v. Чтобы нежелательные изменения(отладка, и т.п.) не попали в продукт |
| - | - Делаем полную пересборку вашей ветки, проводим ручное тестирование основных кейсов использования изменений и fast-autotest. | + | * **Категорически запрещено** делать "git add ." и "git commit -am" это гарантированный пропуск бага. |
| - | - Если все тесты прошли успешно: | + | * Создаем сообщение коммита русским, понятным простому пользователю языком, в обезличенной форме. Первая строка сообщения попадает в changelog и на сайт. Она должна иметь форму: "Исправлено(worker, tt32453): в некоторых случаях не выставлялся счёт". Во второй строке, и далее, могут быть более подробные пояснения для разработчиков. |
| - | * Спец.утилитой создается merge-request из вашего текущего бранча kolko1 в Integra по всем измененным репозиториям. Утилита сама выберет Вашего парного codereviewer'а. Либо имя можно указать параметром. | + | * Лучше больше малых коммитов, чем один очень большой. |
| - | * Закрываем задачу в трекере. | + | * после внесения **любых** изменений, обязательно тестирование. В т.ч. разработчик тестирует, что изменения не сломали код и старый функционал, тестируем что новый функционал работает как задумано, другие кейсы, которые разработчик посчитает необходимым проверить. По возможности отдаём приоритет авто-тестам |
| - | * Пьем чай с ништяками. | + | * перед тестами полная пересборка продукта |
| - | * После merge-request нельзя ничего менять в kolko1 он залочен, новую задачу решаем в kolko2. | + | * отлаживаем **каждую строку**, даже если 1 байт исправления, в тч при исправлении комментариев, дебагов и текстовых строк, тк вероятность ошибки в каждой новой или исправленной строке всегда 100% |
| - | * Codereviewer просмотрев код и, посчитав его нормальным, принимает merge-request из kolko1 в Integra, после этого бранч kolko1 разблокируется. Если с кодом проблемы, то проводятся доработки и бранч остается заблокированным. | + | * если Вы не можете или не хотите отладить и проверить строку, то **Категорически нельзя** добавлять неотлаженную строку кода т.к. Вы создадите очень очень много проблем в будущем. |
| - | - На ближайшем скраме скрам-мастер спрашивает про Вашу задачу и переводит Закрытую задачу в колонку Done или AlarmDone. | + | * после тестирования, создаём реквесты при помощи merge_name2name. Если изменялись несколько репозиториев, то использовать merge_name2name обязательно(чтобы не возникало случаев, когда часть кода не попадает в слияние) |
| + | * в **текст мердж реквеста тезисами пишем "как тестировали"**. Это напоминание, в первую очередь для себя, о правиле тестировать любые изменения. Так же для оценки(самооценки) полноты тестирования. Если не написали, то проводящий код-ревью, должен напомнить об обязательности проверки | ||
| + | * если создали реквест преждевременно, то переводим его на себя или отменяем, в некоторых случаях допускается ставить статус WIP(например небольшие доработки). Не готовый реквест на проверяющего не вешаем. Это отвлекает. | ||
| + | * если изменения сделаны не в той ветке, например запрос в интегру, а нужно исправить баг в мастере, то тоже **пишем об этом шапке запроса**, и молимся, чтобы принимающий реквест смог сделать автоматический черри пик в нужную ветку | ||
| + | * после создания мердж реквестов, задача на скрам доске переезжает в колонку testing | ||
| + | * ветку, где решали задачу менять нельзя, пока реквест не будет принят. Новую задачу решаем в другой ветке, например 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 либо руками. Инструменты должны быть одной версии. Если используете сторонние инструменты, то все равно все типовые инструменты должны быть установлены. | ||
| - | * У каждого должны быть установлены стенды devops CI: vm_сборщик, vm_autotest, vm_отладки, для бренча $login1 и $login2. | + | * У каждого должны быть установлены стенды devops CI: vm_сборщик, vm_autotest, vm_отладки, для бренча $login1 и $login2. |
| * Список инструментов(Коля доделай): | * Список инструментов(Коля доделай): | ||
| - | * Контроль версий только git | + | * Контроль версий только git |
| - | * Для Python PyCharm | + | * Для Python PyCharm |
| - | * Для Си CodeBlocks и gdb | + | * Для Си CodeBlocks и gdb |
| - | * Для bash crab_indent, crab_syntax | + | * Для bash crab_indent, crab_syntax |
| - | * Трекер jira,jira-web,jira-client,jira-python-console. Также можно использовать CRM особенно на этапе когда много задач от клиентов чтоб не дублировать. На первичном этапе version-0.0.0 можно использовать маркерную доску или вики. Также можно использовать другие трекеры по согласованию с руководством. | + | * Трекер jira,jira-web,jira-client,jira-python-console. Также можно использовать CRM особенно на этапе когда много задач от клиентов чтоб не дублировать. На первичном этапе version-0.0.0 можно использовать маркерную доску или вики. Также можно использовать другие трекеры по согласованию с руководством. |
| - | * ОС разработчика ubuntu | + | * ОС разработчика ubuntu |
| - | * ОС продакшн, devops, CI - Centos 6, иногда Centos7 | + | * ОС продакшн, devops, CI - Centos 6, иногда Centos7 |
| - | * TODO вставить остальное согласованное из обсуждения | + | * TODO вставить остальное согласованное из обсуждения |
| ==== Критичные правила разработки ==== | ==== Критичные правила разработки ==== | ||
| + | |||
| * Попутно с основной задачей нельзя исправлять код никакой никогда, если увидели багу - создайте задачу. Если все таки попутно поправили то обязательно отладьте и протестируйте. | * Попутно с основной задачей нельзя исправлять код никакой никогда, если увидели багу - создайте задачу. Если все таки попутно поправили то обязательно отладьте и протестируйте. | ||
| - | Тиражируемый софт | + | |
| + | === Критичные правила. Тиражируемый софт === | ||
| * Никогда не делайте массовых обновлений, делаем 10 потом 50 потом далее. | * Никогда не делайте массовых обновлений, делаем 10 потом 50 потом далее. | ||
| * Софт должен удовлетворять только 80% клиентов и не быть излишне гибким, не должно быть много опций. | * Софт должен удовлетворять только 80% клиентов и не быть излишне гибким, не должно быть много опций. | ||
| Строка 70: | Строка 89: | ||
| * Встроенные средства резервного копирования, работающие из коробки, для восстановления данных пользователя из-за ошибок программ и пользователей. | * Встроенные средства резервного копирования, работающие из коробки, для восстановления данных пользователя из-за ошибок программ и пользователей. | ||
| * Все изменения устанавливаемые клиентам должны быть в тот же день внесены в дистрибутив в свою, клиентскую или временную ветку, до ухода домой. | * Все изменения устанавливаемые клиентам должны быть в тот же день внесены в дистрибутив в свою, клиентскую или временную ветку, до ухода домой. | ||
| + | * Запрещено делать "плохой" дизайн, дизайн должен быть "терпимым". Если не знаете как сделать, советуйтесь с коллегами. По задачам связанным с фронтендом скриншот добавить в решение задачи. | ||
| + | |||
| ==== Время работы и правила в офисе ==== | ==== Время работы и правила в офисе ==== | ||
| + | |||
| Рекомендуется делить день на часы 3+2+3 либо на 4+4. | Рекомендуется делить день на часы 3+2+3 либо на 4+4. | ||
| + | |||
| * 3 часа утром решаем сложную задачу, ни с кем не общаемся ничего не читаем, даже почту. | * 3 часа утром решаем сложную задачу, ни с кем не общаемся ничего не читаем, даже почту. | ||
| * 2 часа решаем мелкие задачи, читаем почту, проводим скрам, общаемся. | * 2 часа решаем мелкие задачи, читаем почту, проводим скрам, общаемся. | ||
| * 3 часа решаем сложную задачу или неприятные мелкие задачи. | * 3 часа решаем сложную задачу или неприятные мелкие задачи. | ||
| + | |||
| Правило тишины | Правило тишины | ||
| - | * Во время рабочего дня выключаем все месендежры и/или интернет на телефоне, выключаем скайп, почту и любые всплывающие сообщения. | + | |
| + | * Во время рабочего дня выключаем все месендежры и/или интернет на телефоне, выключаем скайп, почту и любые всплывающие сообщения. | ||
| * В первой половине дня не ходим спрашивать советов, и не отвлекаем коллег. | * В первой половине дня не ходим спрашивать советов, и не отвлекаем коллег. | ||
| - | * Если звонит личный телефон - общаемся в коридоре или чайной, уважаем тишину колег | + | * Если звонит личный телефон - общаемся в коридоре или чайной, уважаем тишину колег |
| Лайфхаки | Лайфхаки | ||
| + | |||
| * Если есть задачи которые решать не хочется, но надо используем лайф-хак, садимся и делаем хоты бы 1 строчку или одну минуту, и процесс пойдет. | * Если есть задачи которые решать не хочется, но надо используем лайф-хак, садимся и делаем хоты бы 1 строчку или одну минуту, и процесс пойдет. | ||
| * Обязательно используем блокнот с горячей клавишей для мелких задач и буфера обмена. | * Обязательно используем блокнот с горячей клавишей для мелких задач и буфера обмена. | ||
| + | ==== Ссылки на отдельные инструкции по языкам ==== | ||
| + | [[:соглашения_кода:strongbash|strongbash]] \\ | ||
| + | [[:соглашения_кода:python|python]] | ||
| + | [[:foxdev_7:контроль_версий_сборка_тестирование|Читать далее: контроль версий, сборка и тестирование]] | ||
| - | ==== Ссылки на отдельные инструкции по яыкам ==== | + | ~~OWNERAPPROVE~~ |
| - | + | ||
| - | [[соглашения_кода:hardbash]]\\ | + | |
| - | [[соглашения_кода:python]] | + | |
| - | [[open_carbon_7:контроль_версий_сборка_тестирование|Читать далее: контроль версий, сборка и тестирование]] | ||
admin