> For the complete documentation index, see [llms.txt](https://akrisanov.gitbook.io/team-playbook/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://akrisanov.gitbook.io/team-playbook/engineering-practices/kod-revyu.md). # Код-ревью ### Мотивация * Поддержка и улучшение качества кодовой базы и, как следствие, продукта * Возможность формировать инженерные практики и адаптироваться к изменениям ### Перед созданием MR * Разделяйте большие изменения на несколько MR * Разбиение изменений в рамках одного MR на несколько коммитов также упрощает ревью * Создавайте MR даже для изменений, не связанных с конкретной задачей в таск-трекере ### Создание MR *См.* [*Оформление merge request*](https://confluence.planfact.io/pages/viewpage.action?pageId=168696372) Основная задача автора – предоставить внятное объяснение зачем вносятся изменения. Хотя формат MR включает в себя ссылку на задачу, не стоит полагаться на то, что ревьювер перейдет по ней и будет самостоятельно выяснять контекст. Вся необходимая информация должна быть в описании MR. Если в MR есть стилистические или другие неважные изменения, стоит указать на них и сказать ревьюверу важно ли обратить на них внимание. Другим важным аспектом является подсвечивание рисков, связанных с выкаткой изменений, и шагов валидации решения. Для вливания ветки в мастер достаточного одного аппрува:
Настройка репозитория – Settings / Merge Requests
Автор MR самостоятельно выбирает ревьювера для своего MR. Желательно, чтобы это был человек, знакомый с доменной областью. Т.к. в задаче в таск-трекере присутствует поле Reviewer, ревьювера крайне желательно указать его и там. Любой член команды может провести дополнительное ревью изменений при наличии свободного времени, желания и согласовании с автором. ### Ревью изменений *Для простых изменений (пара строк кода в рамках несложной логики, изменения текста в UI и пр.) проводить код-ревью не обязательно. Решение остается за автором MR.* #### **Задачи автора MR** * Поддерживать MR в актуальном состоянии: rebase, исправление конфликтов, правки в рамках ревью * Следить за тем, чтобы ревьювер не забыл про MR * Слияние с мастер-веткой #### **Задачи ревьювера** * (глобальная) помочь команде поддерживать качество кодовой базы и продукта * (локальная) помочь автору изменений найти и учесть возможные недоработки * (личная) лучше понимать кодовую базу и продукт #### **Как делать ревью** * MR без описания или *с незаполненным шаблоном* должен быть отклонен * Если какие-то вещи кажутся вам неочевидными или неясно почему они были сделаны – задавайте вопросы * Оставляя обратную связь, старайте категоризировать комментарии: вопрос, комментарий, ошибка, стиль кода и т.д. Например: * 🐛 потенциальный баг или ошибка в коде * ❓вопрос для прояснения непонятных моментов * 🎨 комментарии по стилю кода * ✏️ предложение к рефакторингу * Взвешенно предлагайте альтернативные варианты – конечное решение остается за автором MR * Привлекайте третью сторону, если не можете найти консенсус с автором * Закрывайте треды, которые вы инициировали – это поможет быстрее вмержить изменения * Не забывайте хвалить и подбадривать коллег. No blame culture here. #### **Как принимать ревью автору MR** * Будьте дружелюбны и открыты к комментариям. Ваш ревьювер – ваш друг (см. Цели ревью и Задачи ревьювера). * Отвечая на комментарии ревьювера, старайтесь давать конкретные ответы и предложения * Помечайте обсуждение как resolved после принятия решения по нему – будут внесены правки, заведена новая задача * Привлекайте третью сторону, если не можете найти консенсус с ревьювером * Если по итогу ревью оказывается, что вы не учли моменты несущие риски для команды и продукта, MR ставится в статус "Заблокирован" и выносится на обсуждение.