Зачем показывать незавершённую работу
В незавершённом коде уже может быть решение, от которого зависит вся оставшаяся работа. Его стоит обсудить до того, как мы начнём строить на нём остальное: к моменту полного ревью менять его может оказаться гораздо труднее.
В раннем пулреквесте нужно объяснить, какое решение уже можно обсуждать. Если просто отправить код на проверку, другой разработчик может начать с недоделок, которые автор и сам собирался исправить. Один потратит время на замечания, второй будет объяснять, почему их пока рано делать.
Представим, что мы добавляем импорт старых публикаций в блог. Окончательного интерфейса ещё нет, не все ошибки разобраны, но уже решили находить публикации по исходному адресу и обновлять их текст при повторной загрузке. Если после первого импорта текст исправят через редактор, повторная загрузка того же файла затрёт правки. Лучше сейчас договориться, какие изменения импорт имеет право вносить, чем переделывать готовое обновление записей.
В описании такого пулреквеста я бы написал: «Импорт пока не готов. Предлагаю находить публикации по исходному адресу, обновлять найденные и добавлять новые. Что делать, если текст на сайте уже отредактирован? Обработку ошибок ещё допишу». Теперь понятно, на какой вопрос нужен ответ. Замечания о временных названиях могут подождать.
Для этого не всегда нужен работающий интерфейс. Иногда достаточно нескольких записей из исходного файла и примера того, что должно получиться. Пулреквест удобен тем, что обсуждение остаётся рядом с изменениями. Объём готового кода сам по себе не определяет, пора ли задать вопрос.
В HTML Academy мы старались открывать пулреквесты как можно раньше, даже если пока изменился только README. Пометка WIP, work in progress, сообщала, что работа продолжается. Но одной пометки мало: она не объясняет, что уже стоит обсудить и какие части ещё будут меняться.
Если просим показывать изменения раньше, то и проверять их нужно с учётом готовности. Можно договориться о поведении импорта, а подробное ревью оставить до завершения кода. Когда каждую промежуточную версию оценивают как законченную, следующую работу её автор, скорее всего, постарается показать попозже.
После разговора стоит записать принятое решение. В нашем примере это правила повторного импорта и поведение при изменённом тексте. По ним получится проверить готовую реализацию, не восстанавливая замысел из переписки.
Мне не нужно видеть каждую промежуточную строку. Важно успеть обсудить решение, пока мы ещё можем спокойно его поменять.