2019-09-20

Q&A: бесконечные очереди на ревью

Я младший разработчик. У нас микросервисная архитектура, я работаю на одном сервисе с чуваком, который не очень общителен, очень требовательный к коду. Я на проекте недавно. Это нормально, что PR может и по неделе без ревью лежать? PR небольшой, строк 300-400. Такое было уже не сколько раз, что подскажите делать? Меня это немного напрягает, так как это серьезно тормозит мою работу, приходиться делать временные бранчи, в которых я работаю, пока код на ревью. Так же не могу вовремя таску закрыть.

Конечно, это не нормально. Старшим разработчиком становятся не тогда, когда на стуле ямка от жопы продавилась, а тогда, когда дошло как с командой работать и зачем вы всем этим занимаетесь. Тут же явно отсутствует понимание со стороны "старших" разработчиков того, что твоя работа она тоже нужна, твой код он может и не столь критичен, но такой забытый код быстро "протухает". Да ты и сам уже заметил, что на ровном месте получаешь постоянные мердж-конфликты, возишься с нагромождением веток, задачи простаивают.

Что тут делать? У проблемы две стороны.

  • Первая: в команде существует модель разработки (бранчи, код ревью и прочие процессы), но отсутствует культура разработки (забить на ревью, и быть "необщительным", хм...)

Сделать ты тут особо ничего не можешь. Максимум -- обозначить проблему на каком-нибудь митинге, где вы обсуждаете вопросы работы или резульаты спринтов (в скраме это будет "ретроспектива"). Спокойно, без обид и наездов расскажи, что вот тебе сложно, фокус теряется, мерджи бесконечные.

Ну и старая добрая пассивная агрессия тоже может помочь. Утром можно напомнить коллеге: "привет, как ты думаешь, у тебя сегодня будет время посмотреть PR#123, который я пять дней назад опубликовал?"

  • Вторая (возможная) проблема: не очень простые пулл-реквесты.

Тебе может и кажется, что они небольшие, но даже ради 400 строк нужно вникнуть в задачу.

Поставь себя на место ревьюера. Что нужно для того, чтобы он быстро проверил твой код?

Попробуй делать подробные описания изменений в PR. Расскажи в двух словах, что надо было сделать, и подробно опиши что и почему сделал. Отметь какие-нибудь важные моменты. Если уместно, то скриншоты сделай (было-стало). Ну и попробуй дробить PR на более мелкие. Это не так просто, как кажется, но это полезный навык.