Иногда это приходит в виде уведомления, но чаще в виде безобидного прямого сообщения Slack:
- Привет, Дэни! Доброе утро.
- Привет, доброе утро, как дела?
- Все хорошо, а ты?
- Все хорошо, спасибо.
- Я хотел бы попросить вас просмотреть только что созданный мной PR…
- Конечно! Без проблем. Как только будет время, посмотрю…
Как наивно… Время?
Вы идете в PR и находите 72 измененных файла, из которых 1298 добавленных строк кода и 872 удаленных!
Время? Что мне нужно, так это взять несколько выходных, чтобы просмотреть ваш PR!!
Не так давно я получил еще один, в котором было… подождите… 255 измененных файлов!! Я не помню, сколько строк, но… 255 файлов!!
И последнее… Оно сопровождалось очень кратким предложением: «Пожалуйста, помогите просмотреть этот PR» и ссылкой. Очень просто. Открываю ПР и …… 🥁 🥁 🥁…… 5825 новых строк!!!
Но действительно?
Мне нужно было бы одолжить целую новую жизнь, чтобы пересмотреть это!
Хотя есть некоторые разработчики, которые против пулл-реквестов, я все же думаю, что мы можем получить от них пользу… Я по-прежнему придерживаюсь мнения, что PR — это полезный инструмент, мы можем извлечь из него выгоду… Конечно, при правильном его использовании.
Если вы пришлете мне пиар до тех пор, пока Британская энциклопедия. Если Дон Кихот — сказка по сравнению с пиаром, то, наверное, он не такой уж и полезный.
Я понимаю, что иногда это будет неизбежно. Вы переименовываете класс, пакет, метод или извлекаете часть класса в новый или переводите библиотеку в новую версию, которая создает критическое изменение… Я понимаю, что такого рода изменения могут привести к десятым долям изменений в проекте. Изменения, которые могут затронуть множество файлов и строк.
Но проблема не в этом. Потому что обычно это может привести к легким изменениям, которые легко просмотреть.
Проблема в том, что когда вы создаете PR, чтобы проверить, что вы работали над ними с детства. И «так как я работаю над этим, я собираюсь реорганизовать это»или «Эта другая карточка связана с этой, я буду работать над обеими в одном PR», или…
Вы знаете, что происходит, когда нужно просмотреть такой длинный PR?
Человек не полностью сосредоточен на PR и очень легко теряет его из виду. Заходит коллега, что-то спрашивает, отвлекает, а когда возвращаешься на PR, не понимаешь, куда смотрел. Если вы хотите понять все изменения и контекст, вы должны прыгать между сотнями строк, чтобы следить за нитью кода. Потом подходит другой коллега и спрашивает, не хочешь ли ты выпить кофе. Вы идете, потому что вам нужно перевести дух, но когда вы возвращаетесь к своему прекрасному пиару, вы полностью теряетесь. Затем вы идете домой (потому что у вас есть жизнь за пределами этого пиара), но на следующий день вы теряете след. Вы женитесь, у вас появятся дети… пока однажды вы не устанете от этого пиара, что постоянно сбиваетесь со следа, и не думаете: «Ты что? Черт возьми, я собираюсь одобрить это и посмотреть, что произойдет. Если что-то пойдет не так, мы исправим это позже в другом PR. мне все равно”
Если мы хотим, чтобы PR был эффективным и добавлял ценность процессу разработки, он должен быть не таким долгим. Он должен позволять рецензентам понять его, просмотреть его без особых дополнительных усилий и легко следовать новому коду. Если мы создадим монстра и воспользуемся одним PR, потому что «Поскольку я с этим, я собираюсь сделать этот рефакторинг», «Я собираюсь реализовать эту задачу, она все еще слева», «Я собираюсь включить свой дипломный выпускной проект», он теряет ценность PR.
Вероятно, вы выполняете больше работы, чем должны. Вероятно, задача или история не очень хорошо разбита.
Потому что, когда передо мной возникает один из таких случаев, я начинаю думать, что, вероятно, философия разработки на основе ствола — неплохой вариант.
