Практическое ревью изменения

Ревью помогает обнаружить несоответствие между заявленной задачей и её результатом. Важно проверять поведение и договорённости проекта, а не просто перечислять личные предпочтения к написанию кода. Для старого сайта с постоянными адресами особенно ценно заметить изменение ссылки, которое выглядит небольшой текстовой правкой.

Сценарий lesson-15 архива задаёт локальную ветку с двумя изменениями: полезным объяснением порядка чтения и ошибочным новым URL JavaScript. Мы подготовим замечание, затем исправленный вариант. Комментарии никому не отправляются, GitLab не изменяется, команды и проверки не выполнялись.

Требование раньше различия

В описании задачи сказано: добавить пояснение перед списком, сохранив существующие пути. Исходный каталог ссылается на /courses/javascript/ и /courses/html-css/. По учебному договору страницы по этим путям существуют, а /courses/javascript-next/ ещё нет. Это исходные условия, с которыми рецензент сравнивает работу.

Если начать только со списка изменённых строк, новый адрес легко принять за намеренное развитие каталога. Но требование к постоянным URL делает вопрос однозначным: изменение выходит за границы задачи и нарушает переход. Поэтому сначала читайте описание и контекст, затем само различие.

В подготовленной лаборатории исходная ветка называется feature/course-order, а назначение — main. Прочитайте её итоговое изменение:

git diff main...feature/course-order -- content/courses.md
git log --oneline main..feature/course-order

Ожидается добавление пояснения и замена URL JavaScript. HTML/CSS сохранён. В этой модели оба изменения находятся в одном авторском коммите; это не мешает предложить узкое исправление только адреса. Документация diff описывает сравнения, а наша задача задаёт критерий оценки результата.

Теперь откройте полный конечный документ. Отдельная строка сравнения не показывает, удобно ли расположен абзац и не повторяет ли он соседнюю рекомендацию. Содержательное чтение помогает оценить добавление текста, а точная ссылка позволяет обнаружить функциональную ошибку.

Замечание с воспроизводимым условием

Подготовим один комментарий к строке JavaScript:

Здесь URL изменён на /courses/javascript-next/, но в исходных условиях
есть только /courses/javascript/. Новый путь не входит в задачу и не
имеет страницы в учебной модели. Верните прежний адрес, сохранив
добавленный абзац о порядке чтения. После исправления обе ссылки
должны совпадать с исходным каталогом.

Этот текст связывает наблюдение с конкретным требованием. Он объясняет последствие, предлагает минимальное исправление и называет проверяемое конечное состояние. Автору не приходится угадывать, какое слово заменить и нужно ли удалить весь полезный абзац.

Сравните с замечанием «ссылки какие-то странные». Оно выражает впечатление, но не даёт основания и способа завершить обсуждение. Другая крайность — переписать весь каталог за автора и добавить новые идеи. Тогда исправление ошибки смешивается с незапрошенным изменением содержания. В нашем случае достаточно вернуть одно значение пути.

Не утверждайте «получен ответ 404», если вы не открывали сервер и не проверяли ответ. По условию модели целевой страницы нет; именно так и сформулировано замечание. Ожидаемый сетевой эффект не выдаётся за наблюдавшийся. При реальном просмотре к комментарию можно добавить точный запрос и ответ соответствующего окружения.

Исправление без потери цели

Автор возвращает URL JavaScript в content/courses.md, оставляя новый абзац. Затем читает различие рабочего файла и записывает исправление в ту же ветку отдельным коммитом:

git diff -- content/courses.md
git add content/courses.md
git commit -m "Сохранить постоянный адрес курса JavaScript"

Ожидается узкая обратная замена пути. Коммит с исходной задачей остаётся в истории, как и дополнительное исправление. Для нашего урока не требуется переписывать опубликованную линию. Рецензент сможет увидеть, что именно изменилось после его замечания.

Снова сравните конечный документ с main. Теперь ожидается только поясняющий абзац. URL обеих ссылок совпадают с исходным снимком. Прочитайте также новый список записей: он показывает первоначальную работу и исправление, но решение о готовности основывается на конечном содержимом.

Это различие полезно для большого сайта. Автор может аккуратно вернуть одну ссылку, но случайно удалить другую строку рядом. Поэтому фраза «замечание исправлено» не заменяет повторного чтения затронутого места. Проверка должна охватывать требование, а не только наличие нового коммита с подходящим названием.

Закрытие замечания должно иметь ясное основание. В нашем случае оно формулируется так: в конечном Markdown адрес JavaScript совпадает с исходным, адрес HTML/CSS сохранён, полезное пояснение осталось перед списком. Рецензент может перечислить эти три наблюдения, не требуя от автора произвольного полного переписывания. Если замечание относится к подготовленному, но не выполненному сетевому эффекту, его статус тоже остаётся ограниченным чтением исходника. Это не мешает обнаружить нарушение договора, но не подтверждает поведение хостинга. Для сложного изменения часть вопросов может быть закрыта редакционно, а часть ждать отдельного запуска. Сохраняйте эту разницу в описании работы. Общее слово «готово» полезно только тогда, когда команда одинаково понимает, какие условия оно включает. Наш урок завершает узкое сравнение двух ссылок; расширение каталога и выпуск страницы остаются отдельными решениями.

Обсуждение и границы одобрения

В будущем интерфейсе GitLab замечание можно связать с соответствующей строкой изменения. Руководство по ревью описывает обсуждения и действия рецензента. Здесь подготовлен только локальный текст комментария; никакие сообщения, одобрения или решения в аккаунте не создавались.

Если автор не согласен с требованием, обсудите причину до механического исправления. Например, новая страница действительно может быть подготовлена в другой задаче. Тогда потребуются подтверждение маршрута, согласование границ и изменение описания. В нашем сценарии такой страницы нет, поэтому спор не скрывается за неопределённым «возможно».

Также отделяйте обязательную ошибку от предложения улучшения. Нарушение постоянного пути требует исправления в рамках текущей задачи. Возможность написать дополнительный вводный урок может быть полезной идеей, но не является условием приёма одного поясняющего абзаца. Приоритет комментария должен соответствовать его влиянию на заявленный результат.

Одобрение исходников не подтверждает состав опубликованного выпуска. Рецензент мог прочитать Markdown, но не собранный HTML. В нашей текущей работе не запускаются тесты, учебные команды или деплой, поэтому статус материала остаётся локальным черновиком. Это ограничение важно сохранить и в будущем описании запроса, пока новые действия не будут выполнены.

Полезный результат ревью — не количество комментариев, а устранённое несоответствие и понятный общий договор. Для учебного каталога это добавленный абзац с двумя неизменными адресами. В следующем уроке рассмотрим, как связать выбранный снимок исходников с составом будущего выпуска.