Почему ваши пул-реквесты такие большие и что с этим делать

Почему большие пул-реквесты — это проблема навыков, а не характера

Вы когда-нибудь отправляли пул-реквест на 1500 строк и ждали ревью несколько дней? Знакомая ситуация? Часто думают, что большие PR — это вопрос дисциплины. «Просто делай PR меньше». Но на самом деле разбить крупную задачу на маленькие, независимые куски — это навык, которому почти нигде не учат. В этой статье вы узнаете, как освоить этот навык и почему он стал критически важным в эпоху AI.

Почему большие PR вредят команде

Большие пул-реквесты — одна из главных причин багов, задержек и выгорания. Когда один PR висит неделями, ревьюер вынужден держать в голове целую подсистему. Как следствие — ошибки пропускаются, дедлайны срываются. И это не вина разработчиков: они просто не умеют иначе. Хорошая новость: этому можно научиться.

Что происходит, когда PR становится меньше

Вот что я заметил, когда начал дробить свои PR:

• Больше багов ловится на ревью. Ревьюер может осмысленно проверить 200 изменений, но не 2000.
• PR быстрее проходят ревью и мержатся. Меньше времени в очереди — быстрее фичи попадают в продакшен.
• Перестаёт быть страшно. Вы фокусируетесь на одной части, а не пытаетесь удержать в голове всю систему.
• Вы становитесь лучше в планировании. Чтобы отправить маленький PR, нужно сначала разбить задачу — а значит, понять её структуру.

Маленькие PR заставляют видеть систему как набор кирпичиков Lego, которые собираются вместе. Как только вы научитесь видеть эти кирпичики, декомпозиция перестаёт быть накладной — это просто ваш способ думать.

Как выглядит команда, которая делает маленькие PR

В команде, которой я сейчас руководствую, маленькие PR — это норма. Результаты говорят сами за себя:

• Среднее время от открытия до мержа — около 1,5 дней.
• Багов гораздо меньше, а те, что есть, легко находятся и исправляются — потому что изменение, которое их вызвало, было маленьким и понятным.
• Сроки поставки более предсказуемы: мы обещаем — и доставляем.

Честно признаюсь: много планирования и декомпозиции я делаю сам. Это ключевой навык, которому я учу команду. Мы не вводим правило «PR не больше 300 строк» как догму, но эта цифра помогает сформировать привычку. Важна сама привычка, а не точное число.

AI изменил правила игры

Раньше был естественный ограничитель размера PR: написать 2000 строк кода вручную — тяжело. Размер сам себя ограничивал. AI убрал это трение. Теперь можно сгенерировать сотни изменений одним промптом. Но усилие не исчезло — оно переместилось на ревьюера. Автор платит почти ничего, ревьюер — всё.

Это значит, что навык разбивать работу на маленькие куски стал не просто полезным, а критически важным. Если раньше «делай PR меньше» подкреплялось стоимостью написания, то теперь это нужно осознанно внедрять против инструмента, который с радостью выдаст вам тысячу изменений, которые вы даже не обдумывали.

Пример: как разбить задачу на маленькие PR

Допустим, вам нужно добавить биллинг в систему. Вместо одного гигантского PR разбейте на этапы:

1. Модель данных: добавить таблицы Invoice и Payment.
2. API создания счёта: эндпоинт POST /invoices.
3. API оплаты: эндпоинт POST /payments.
4. Интеграция с платежным шлюзом: вызов внешнего API.
5. UI для отображения счетов: страница со списком.

Каждый этап — отдельный PR, который можно заревьюить и замержить за день.

# Пример: маленький PR — добавление модели данных
from django.db import models

class Invoice(models.Model):
    user = models.ForeignKey(User, on_delete=models.CASCADE)
    amount = models.DecimalField(max_digits=10, decimal_places=2)
    created_at = models.DateTimeField(auto_now_add=True)

class Payment(models.Model):
    invoice = models.ForeignKey(Invoice, on_delete=models.CASCADE)
    amount = models.DecimalField(max_digits=10, decimal_places=2)
    status = models.CharField(max_length=20, choices=[('pending', 'Ожидание'), ('completed', 'Завершён')])
    created_at = models.DateTimeField(auto_now_add=True)

Этот PR содержит только модель — его легко проверить и смержить.

Как научиться видеть кирпичики

Вот несколько практических шагов, которые помогут вам разбивать задачи:

• Начните с планирования. Прежде чем писать код, набросайте список шагов. Каждый шаг должен быть самодостаточным и давать ценность (пусть даже маленькую).
• Используйте feature toggles. Если шаг слишком мал, чтобы быть самостоятельной фичей, спрячьте его за флагом.
• Делите по слоям. Сначала модель, потом бизнес-логика, потом API, потом UI. Не смешивайте всё в одном PR.
• Практикуйтесь на простых задачах. Даже багфикс можно разбить на «написать тест, воспроизводящий баг» и «исправить код».

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

Что делать прямо сейчас

1. Возьмите следующую задачу и разбейте её на 3-5 маленьких PR. Запишите их в виде списка.
2. Отправьте первый PR, как только он будет готов — не ждите, пока сделаете всё.
3. Попросите коллегу заревьюить его и замержить. Повторите.

Вы удивитесь, насколько быстрее начнут двигаться задачи и насколько меньше станет багов.