Как стать автором
Обновить

Комментарии 10

четко, понятно и доступно, всё по делу:)
Спасибо за статью, очень доступно описаны процессы, их особенности и цели.

Что думаешь про подходы без этапа кодревью? Например XP (Extreme Programming), где процесс ревью кода объединен с процессом его написанием в парах. Какие плюсы и минусы видишь в таком подходе?
Я не глубоко знаю тему, могу что-то не учесть и что-то не знать. На мой взгляд, у Extreme Programming плюсы ровно в том в чем и минусы.

Социальные аспекты работают всегда. Когда 2 человека работают за 1 компьютером, это сильно социализирует, что должно положительно сказываться на разработке и текучке кадров. Так и наоборот, разработчики могут разругаться в рабочем процессе, или может они не очень хорошо друг к другу относятся, то преимущество такого подхода становится недостатком

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

По бизнес процессам, трогать не будут, определенно в правильном месте это лучший вариант.
Попадете в Crossover в bootcamp на архитекторской должности в одну из недель на проект Cleaner/Faster/etc. (CodeReview был в одном из таких проектов), к концу этой недели будете уже получать черный пояс по улучшениям и рефакторингу кода :)

Насчёт рефакторинга существующего кода: вопрос договорённостей в команде.


Сейчас у нас, например, правило: если просят сделать рефакторинг, который займёт меньше 5 минут, то надо делать независимо от того, относится это к задаче или нет. Ну или в другой формулировке: если ты изменил какой-то файл в рамках задачи, то его рефакторинг относится к твоей задаче. Если не влазиг в эстимейты, то надо завести задачу и оставить ссылку на неё в коде

Когда оставляют замечания и просят поправить то что не относится к задаче, пусть это небольшие правки, это отнимет время разработчика:
  • Отвлечься от текущей задачи (разработчик теряет контекст и включение обратно может занять 10-15 минут)
  • Прейти в ветку и поправить код
  • Сделать сборку проекта и запусти его (убедиться что ничего не поломано)

Это отнимает время других разработчиков, они теряют контекст своей текущей задачи, тратят время на просмотр исправления.

Я отнес этот пункт к социальным аспектам, данные комментарии могут восприниматься негативно разработчиками. Могу добавить что у меня были случаи когда небольшое замечание и быстрая правка в одну строчку влекло большие изменения в проекте, которые никто не увидел, и это приводило к рефакторингу на несколько дней. Не все разработчики могут остановится в процессе рефакторинга и сказать что это не быстрая правка.

И все же, полностью согласен с Вами, это вопрос договоренности. Люди разные и что работает в одной команде, может не работать в другой.

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

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

Вот ещё: большинства замечаний о скобочках и пробелах быть не должно, потому что такой код не должен попадать в PR, должен отбрасываться линтером или автоматически фикситься.

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории