Инструкция Программиста
Различия
Здесь показаны различия между двумя версиями данной страницы.
| Предыдущая версия справа и слева Предыдущая версия Следующая версия | Предыдущая версия | ||
|
foxdev_7:инструкция_программиста [18.11.2020 08:28] zimo |
foxdev_7:инструкция_программиста [20.03.2021 08:34] (текущий) admin |
||
|---|---|---|---|
| Строка 10: | Строка 10: | ||
| Основано на реальных событиях. | Основано на реальных событиях. | ||
| - | * Смотреть общие правила [[https://wika.carbonsoft.ru/carbon_soft:общие_инструкции:как_решать_задачи]] | + | |
| + | * Смотреть общие правила [[https://wika.carbonsoft.ru/carbon_soft:общие_инструкции:как_решать_задачи|https://wika.carbonsoft.ru/carbon_soft:общие_инструкции:как_решать_задачи]] | ||
| * Задачу выбираем из своего стека скрам-доски, во время скрама, с учетом текущих приоритетов. Скрам-мастер сдвигает задачу на колонку "1 день". | * Задачу выбираем из своего стека скрам-доски, во время скрама, с учетом текущих приоритетов. Скрам-мастер сдвигает задачу на колонку "1 день". | ||
| * Проверяем, что у задачи стоит длительность 0.5 или 1 день. Без длительности задачу не решаем, если больше дня, то декомпозируем. | * Проверяем, что у задачи стоит длительность 0.5 или 1 день. Без длительности задачу не решаем, если больше дня, то декомпозируем. | ||
| Строка 16: | Строка 17: | ||
| * Если это Bug, то обязательно лично воспроизводим на **своей** виртуалке и только потом решаем. | * Если это Bug, то обязательно лично воспроизводим на **своей** виртуалке и только потом решаем. | ||
| * до начала изменения кода, определяем: категорию, масштаб проблемы/задачи | * до начала изменения кода, определяем: категорию, масштаб проблемы/задачи | ||
| - | * если задача из категории "запрещённых"(изменения архитектуры), то решаем их по процедуре через технический комитет. Полный список "запрещённых" задач и правила их решения смотрим в должностных инструкциях [[https://wika.carbonsoft.ru/отдел_разработки:инструкции_должностные:должностная_программист]] | + | * если задача из категории "запрещённых"(изменения архитектуры), то решаем их по процедуре через технический комитет. Полный список "запрещённых" задач и правила их решения смотрим в должностных инструкциях [[https://wika.carbonsoft.ru/отдел_разработки:инструкции_должностные:должностная_программист|https://wika.carbonsoft.ru/отдел_разработки:инструкции_должностные:должностная_программист]] |
| * если задача не "запрещённая", обсуждение проблемы и решения - приветствуется | * если задача не "запрещённая", обсуждение проблемы и решения - приветствуется | ||
| * выбираем базовую ветку в которые изменения должны попасть: | * выбираем базовую ветку в которые изменения должны попасть: | ||
| - | * баги/хотфиксы/критичный функционал для определённой ветки. Например мастер(если баг мастера). | + | * баги/хотфиксы/критичный функционал для определённой ветки. Например мастер(если баг мастера). |
| - | * фичи, рефакторинг, крупные правки некритичных багов - интегра | + | * фичи, рефакторинг, крупные правки некритичных багов - интегра |
| - | * задача всегда решается разработчиком в отдельной ветке, **созданной от базовой**. | + | * задача всегда решается разработчиком в отдельной ветке, **созданной от базовой**. |
| * если ветка старая - обновить до начала работы(pull, reset и т.д.) | * если ветка старая - обновить до начала работы(pull, reset и т.д.) | ||
| * запрещено решать несколько не связанных задач в одной ветке | * запрещено решать несколько не связанных задач в одной ветке | ||
| Строка 29: | Строка 30: | ||
| * Создаем сообщение коммита русским, понятным простому пользователю языком, в обезличенной форме. Первая строка сообщения попадает в changelog и на сайт. Она должна иметь форму: "Исправлено(worker, tt32453): в некоторых случаях не выставлялся счёт". Во второй строке, и далее, могут быть более подробные пояснения для разработчиков. | * Создаем сообщение коммита русским, понятным простому пользователю языком, в обезличенной форме. Первая строка сообщения попадает в changelog и на сайт. Она должна иметь форму: "Исправлено(worker, tt32453): в некоторых случаях не выставлялся счёт". Во второй строке, и далее, могут быть более подробные пояснения для разработчиков. | ||
| * Лучше больше малых коммитов, чем один очень большой. | * Лучше больше малых коммитов, чем один очень большой. | ||
| - | * после внесения **любых** изменений, обязательно тестирование. В т.ч. разработчик тестирует, что изменения не сломали код и старый функционал, тестируем что новый функционал работает как задумано, другие кейсы, которые разработчик посчитает необходимым проверить. По возможности отдаём приоритет авто-тестам | + | * после внесения **любых** изменений, обязательно тестирование. В т.ч. разработчик тестирует, что изменения не сломали код и старый функционал, тестируем что новый функционал работает как задумано, другие кейсы, которые разработчик посчитает необходимым проверить. По возможности отдаём приоритет авто-тестам |
| - | * перед тестами полная пересборка продукта | + | * перед тестами полная пересборка продукта |
| - | * отлаживаем **каждую строку**, даже если 1 байт исправления, в тч при исправлении комментариев, дебагов и текстовых строк, тк вероятность ошибки в каждой новой или исправленной строке всегда 100% | + | * отлаживаем **каждую строку**, даже если 1 байт исправления, в тч при исправлении комментариев, дебагов и текстовых строк, тк вероятность ошибки в каждой новой или исправленной строке всегда 100% |
| - | * если Вы не можете или не хотите отладить и проверить строку, то **Категорически нельзя** добавлять неотлаженную строку кода т.к. Вы создадите очень очень много проблем в будущем. | + | * если Вы не можете или не хотите отладить и проверить строку, то **Категорически нельзя** добавлять неотлаженную строку кода т.к. Вы создадите очень очень много проблем в будущем. |
| * после тестирования, создаём реквесты при помощи merge_name2name. Если изменялись несколько репозиториев, то использовать merge_name2name обязательно(чтобы не возникало случаев, когда часть кода не попадает в слияние) | * после тестирования, создаём реквесты при помощи merge_name2name. Если изменялись несколько репозиториев, то использовать merge_name2name обязательно(чтобы не возникало случаев, когда часть кода не попадает в слияние) | ||
| * в **текст мердж реквеста тезисами пишем "как тестировали"**. Это напоминание, в первую очередь для себя, о правиле тестировать любые изменения. Так же для оценки(самооценки) полноты тестирования. Если не написали, то проводящий код-ревью, должен напомнить об обязательности проверки | * в **текст мердж реквеста тезисами пишем "как тестировали"**. Это напоминание, в первую очередь для себя, о правиле тестировать любые изменения. Так же для оценки(самооценки) полноты тестирования. Если не написали, то проводящий код-ревью, должен напомнить об обязательности проверки | ||
| Строка 39: | Строка 40: | ||
| * после создания мердж реквестов, задача на скрам доске переезжает в колонку testing | * после создания мердж реквестов, задача на скрам доске переезжает в колонку testing | ||
| * ветку, где решали задачу менять нельзя, пока реквест не будет принят. Новую задачу решаем в другой ветке, например kolko2. | * ветку, где решали задачу менять нельзя, пока реквест не будет принят. Новую задачу решаем в другой ветке, например kolko2. | ||
| - | * ревью изменений в основные ветки продукта **всегда** проводит другой разработчик. Кто может проводит код-ревью определяет тим-лид продукта *.dev.teamlead | + | * ревью изменений в основные ветки продукта **всегда** проводит другой разработчик. Кто может проводит код-ревью определяет тим-лид продукта *.dev.teamlead |
| * ревью изменений в основные ветки платформы: base, auth, common_scripts и т.п. выполняет руководитель процесса разработки devops.head | * ревью изменений в основные ветки платформы: base, auth, common_scripts и т.п. выполняет руководитель процесса разработки devops.head | ||
| * после внесения правок по результатам ревью, **выполняем пункт тестирование**, обновляем реквесты | * после внесения правок по результатам ревью, **выполняем пункт тестирование**, обновляем реквесты | ||
| Строка 45: | Строка 46: | ||
| * На скраме мы не спрашиваем ревьюверов, почему они приняли/не приняли/когда примут реквест. Мы это спрашиваем у ответственного по задаче, когда он договорится с его ревьювером. | * На скраме мы не спрашиваем ревьюверов, почему они приняли/не приняли/когда примут реквест. Мы это спрашиваем у ответственного по задаче, когда он договорится с его ревьювером. | ||
| * задача считается решённой и переносится в Done, только после **слияния изменений с нужной веткой**. Пока реквест не принят, задача считается не решённой | * задача считается решённой и переносится в Done, только после **слияния изменений с нужной веткой**. Пока реквест не принят, задача считается не решённой | ||
| + | * Для Подтверждение закрытия задачи обязтаельно добавляем скрины и или дифф коммита в задачу или в комент. | ||
| Примечания: | Примечания: | ||
| + | |||
| * Все разработчики раз в день (если высокая нагрузка, то реже) просматривают в gitlab список открытых на них реквестов. Если обнаружены проблемы: пишут об этом комментарий или сообщают лично, заявку при этом не закрываем - свои незакрытые реквесты просматривает разработчики. Закрытые по ошибке реквесты должны пересоздаваться спец.утилитой. | * Все разработчики раз в день (если высокая нагрузка, то реже) просматривают в gitlab список открытых на них реквестов. Если обнаружены проблемы: пишут об этом комментарий или сообщают лично, заявку при этом не закрываем - свои незакрытые реквесты просматривает разработчики. Закрытые по ошибке реквесты должны пересоздаваться спец.утилитой. | ||
| * Разработчик раз в день (или чаще) просматривает список своих реквестов. Приняли ли их, что нужно исправить. Если реквест очень срочный - он может подойти к ревьюверу лично или позвонить. | * Разработчик раз в день (или чаще) просматривает список своих реквестов. Приняли ли их, что нужно исправить. Если реквест очень срочный - он может подойти к ревьюверу лично или позвонить. | ||
| Строка 86: | Строка 89: | ||
| * Встроенные средства резервного копирования, работающие из коробки, для восстановления данных пользователя из-за ошибок программ и пользователей. | * Встроенные средства резервного копирования, работающие из коробки, для восстановления данных пользователя из-за ошибок программ и пользователей. | ||
| * Все изменения устанавливаемые клиентам должны быть в тот же день внесены в дистрибутив в свою, клиентскую или временную ветку, до ухода домой. | * Все изменения устанавливаемые клиентам должны быть в тот же день внесены в дистрибутив в свою, клиентскую или временную ветку, до ухода домой. | ||
| + | * Запрещено делать "плохой" дизайн, дизайн должен быть "терпимым". Если не знаете как сделать, советуйтесь с коллегами. По задачам связанным с фронтендом скриншот добавить в решение задачи. | ||
| ==== Время работы и правила в офисе ==== | ==== Время работы и правила в офисе ==== | ||
zimo