Бывает по разному. Самый частый вариант в общих чертах выглядит так: 1. Разработчикам запрещается заливать код на продуктовое окружение напрямую. 2. Любой код в начале отправляется на проверку командой. Обычно для этого используется какой-то сервис, вроде gitlab\github. 3. Только после того как код разработчика получит разрешение от одного или нескольких сотрудников он может оказаться на проде.
Такой подход решает сразу несколько проблем: часть ошибок отлавливается, знания о коде и каких то приемах распространяются внутри команды, стиль написания кода "уравнивается". Но главное, когда знаешь что твой код точно посмотрят коллеги писать уж совсем плохо не хочется.
Вариаций этого механизма есть целая куча, все проекты и команды уникальны. Универсальной серебряной пули нет.
Абсолютно адекватная тема, если грамотно подать и учитывать, что если человек поддерживает процессы , у него рутина и проще не ртчеты писать, а список тикетов показать
не понятно из статьи норм тема или не норм, весь процесс тут не описан. А вообще код проверяют, если ты новичок то твой код будет отсматривать твой непосредственный руководитель. Если иерархии в команде нет, то кто-то из коллег смотрит, обычно тот кто разбирается в той вещи которую ты изменяешь
Код проверяют те, кто в этом шарит. И в идеале, понимают логику, заложенную в функционале, который ты пишешь/меняешь. Для отчётности есть джира/редмаин. Код (включая информацию о том, кто написал и что изменил) в гите. Всякие идиотские отчёты используют только там, где есть самодуры, ничего не понимающие в процессе разработки, но при этом желающие хотя бы себя убедить, что все идёт хорошо (ибо отчёты- это про лапшу на ушах, а не про факты)
айтишники, поясните. сам вкатываюсь, много че слышал, но про такое впервые. это норм тема или причуда маска какая-то? как вообще код проверяют?
Бывает по разному. Самый частый вариант в общих чертах выглядит так:
1. Разработчикам запрещается заливать код на продуктовое окружение напрямую.
2. Любой код в начале отправляется на проверку командой. Обычно для этого используется какой-то сервис, вроде gitlab\github.
3. Только после того как код разработчика получит разрешение от одного или нескольких сотрудников он может оказаться на проде.
Такой подход решает сразу несколько проблем: часть ошибок отлавливается, знания о коде и каких то приемах распространяются внутри команды, стиль написания кода "уравнивается". Но главное, когда знаешь что твой код точно посмотрят коллеги писать уж совсем плохо не хочется.
Вариаций этого механизма есть целая куча, все проекты и команды уникальны. Универсальной серебряной пули нет.
Я личинка айтишника, но вроде бы это норм тема. Код-ревью.
Можно в git проанализировать коммиты при желании. Тут в статье мб неправильно донесли инфу.
Абсолютно адекватная тема, если грамотно подать и учитывать, что если человек поддерживает процессы , у него рутина и проще не ртчеты писать, а список тикетов показать
не понятно из статьи норм тема или не норм, весь процесс тут не описан. А вообще код проверяют, если ты новичок то твой код будет отсматривать твой непосредственный руководитель. Если иерархии в команде нет, то кто-то из коллег смотрит, обычно тот кто разбирается в той вещи которую ты изменяешь
Код проверяют те, кто в этом шарит. И в идеале, понимают логику, заложенную в функционале, который ты пишешь/меняешь. Для отчётности есть джира/редмаин. Код (включая информацию о том, кто написал и что изменил) в гите. Всякие идиотские отчёты используют только там, где есть самодуры, ничего не понимающие в процессе разработки, но при этом желающие хотя бы себя убедить, что все идёт хорошо (ибо отчёты- это про лапшу на ушах, а не про факты)