Согласна с тем, что Code Review ничего не гарантирует, но не согласна, что его не стоит использовать. По-моему, плюсов гораздо больше, чем минусов.
Насчет почвы для конфликтов – это опять же про культуру в команде и soft skills. Если люди не могут договориться, не могут корректно давать обратную связь и воспринимать ее, то тут проблема не в Code Review.
Я перечислила примеры инструментов, которые могут использоваться для Code Review. И буквально первая ссылка в этом списке – ссылка на GitHub, где написано про Pull Requests: "Pull requests are fundamental to how teams review and improve code on GitHub."
Для всех остальных упомянутых в статье инструментов также на главных страницах по ссылкам явно написано, что они используются в том числе для Code Review. Про Crucible опять же буквально написано в официальной документации "Crucible allows you to request, perform and manage code reviews."
То, что можно настроить CI/CD, это прекрасно, но это никак не относится ни к теме статьи, ни к моим комментариям, ни к тому как эта статья задумывалась. И то, что указанные инструменты можно еще как-то использовать, помимо непосредственно Code Review – тоже. Я нигде не пишу, что это их единственное назначение и/или что это все инструменты для ревью, которые есть. Не было цели описать инструменты и все кейсы их использования.
Если для вас в статье нет ничего нового, а указанные инструменты вы используете иначе – это ок. Я не вижу тут причины для споров. Просто, возможно, вы не целевая аудитория этой статьи.
Ну и еще вариант - если задача сделана, всё работает, а задачу очень ждут и времени мало, то замечания по ревью (если они не критичные) можно вынести в отдельную задачу с техдолгом и взять ее в следующий спринт (если у вас спринты).
1-2 дня - это максимум на ожидание ревью. Обычно в тот же день или на следующий ревью проходит. Вы описали прям суровый вариант, когда что-то сильно пошло не так (причем еще до ревью), что аж несколько раз пришлось править замечания. В реальности я даже такого не припомню, обычно одного раунда правок достаточно, максимум двух.
Если задача очень большая, то перед тем, как ее делать, также можно обсудить какие-то архитектурные моменты в команде, чтобы как раз не править потом глобально после ревью уже готовую задачу.
Ну и также в момент разработки тоже можно советоваться с коллегами по каким-то вопросам, чтобы не возникало потом каких-то больших переделок на ревью.
Самые большие ревью с большим количеством правок возникают обычно в ситуациях:
в команду пришел новый человек и это его первая задача (и возможно она была сразу большая)
задача была большая, плохо декомпозирована и возникла проблема в реализации, требуется много правок
Если такое происходит, то главное сделать выводы из ситуаций и в будущем скорректировать процессы, чтобы их избежать. Например, давать новым сотрудникам задачи поменьше, обсуждать реализацию до начала разработки задачи (общие моменты: вроде "вот тут добавляем поля в БД, здесь делаем такие-то классы, вот этот функционал будет реализован аналогично такому-то"), дробить задачи на более мелкие.
Как раз уже думаю над примерно таким форматом статьи - пройтись по кейсам и описать, как решали. Судя по комментариям, актуально будет в виде такого формата сделать.
Я думаю, что имеет смысл на основе вопросов в комментах сделать отдельную статью и в ней практические ситуации разобрать, т.к. это уже прям конкретные особенности команды и культуры в ней
Не соглашусь. Здесь именно про Code Review и инструменты в конце статьи могут использоваться для Code Review в командах (это не значит, что они только для этого). Более того, был опыт использования большинства из них при ревью в разных компаниях. Кстати, про Fisheye хорошее дополнение.
Но вся суть – не в инструментах, а в подходе. Можно ревьювить код задачи без специальных инструментов, а просто переключаясь в ветку задачи и смотря комиты по ней в в вашей текущей IDE. Инструменты я привела просто в качестве примеров, если вдруг кому-то нужно будет.
У нас такого, к счастью, нет) Мы в целом договорились что ревью за 1-2 дня проходит.
Но я сталкивалась раньше с такими случаями. Мы решали такие вопросы с тимлидами и в целом с четким воркфлоу в командах. Например, у нас были случаи, когда другая команда вносила правки в код нашей команды в рамках их задачи и ревью было на нас - мы договорились, что у таких ревью приоритет выше, чем у всех остальных ревью и старались их делать быстрее. Ну и в обратную сторону - аналогично. Другие команды старались наши ревью смотреть быстрее и приоритетнее.
Вообще ситуация "срочное ревью" возможна только если это багфикс чего-то на бою и обычно там не очень много кода и ревью можно быстро провести. В остальных случаях по идее не должно быть такой срочности. Если она есть, то, по-моему, тут что-то не так с процессами, возможно, на уровне приоритетов задач от PM.
Ну и в игры "тянул мой PR, я тоже потяну" - для начала просто не вступайте, это непродуктивно и никому от этого хорошо не будет. В целом это вопрос про культуру в командах. Если есть возможность, можно это обсудить на ретроспективах или донести до тимлидов команд. Чтобы был процесс, который все понимают и не было необходимости отвлекать кого-то в личке. Ну и посмотреть, почему вообще с какими-то задачами возникает такая срочность именно на этапе ревью и действительно ли она возникает или это просто разработчик хочет быстрее закрыть тикет, а то такое тоже бывает.
Если задачи хорошо декомпозированы, то временные затраты обычно не большие (+ час-два к задаче). Еще, например, у нас сейчас в команде договоренность, что задачи в статусе ревью висят не более 24 часов (1-2 дня условно) - то есть задержка релиза тоже небольшая. Если задача маленькая, то ревью вообще практически не добавляет затрат - полчаса или меньше на ревью.
Мне кажется, что в небольшой команде наоборот легче всего ревьювить. И быстрее всего. Вот когда продукт разделен на разные части и там разные команды отвечают за код, а вы отдаете в ревью что-то другой команде - то вот тут могут быть случаи, что ревью зависло и надо отдельно напоминать про него другой команде. Уже второй комментарий про опыт, наверное действительно стоит сделать отдельно статью про реализацию)
Про это как раз написано в месте - что все ревьювят всех. Я считаю, что не должно быть такого, что кто-то один в команде принимает все решения. Вы правы - это бывает очень токсично и непродуктивно + вредит продукту скорее всего. Команда все-таки должна уметь договариваться и уважать мнения друг друга. Если есть аргументы, почему какое-то решение человек считает подходящим, то можно донести это при ревью и ревьювер может пропускать код, даже если был изначально не согласен с чем-то. Спасибо, что вынесли этот кейс в комментарий.
А что именно про опыт? Часть вот этих чеклистов мы, например, использовали в команде, прям писали их даже во внутренней документации для новых сотрудников, которые раньше не делали ревью. Сейчас используем Pull Requests в GitHub для самого процесса ревью, большие задачи стараемся комитить мелкими частями. Эта статья именно больше про теорию и задумывалась. Но могу и про опыт написать отдельно, мне просто кажется, что там будет мало.
Согласна с тем, что Code Review ничего не гарантирует, но не согласна, что его не стоит использовать. По-моему, плюсов гораздо больше, чем минусов.
Насчет почвы для конфликтов – это опять же про культуру в команде и soft skills. Если люди не могут договориться, не могут корректно давать обратную связь и воспринимать ее, то тут проблема не в Code Review.
Видео посмотрю, спасибо за ссылки!
Я подозреваю, что имеется в виду, что ревьювят минимум два человека – то есть нужно два апрува, прежде чем задача пройдет дальше.
Я перечислила примеры инструментов, которые могут использоваться для Code Review. И буквально первая ссылка в этом списке – ссылка на GitHub, где написано про Pull Requests: "Pull requests are fundamental to how teams review and improve code on GitHub."
Для всех остальных упомянутых в статье инструментов также на главных страницах по ссылкам явно написано, что они используются в том числе для Code Review. Про Crucible опять же буквально написано в официальной документации "Crucible allows you to request, perform and manage code reviews."
То, что можно настроить CI/CD, это прекрасно, но это никак не относится ни к теме статьи, ни к моим комментариям, ни к тому как эта статья задумывалась. И то, что указанные инструменты можно еще как-то использовать, помимо непосредственно Code Review – тоже. Я нигде не пишу, что это их единственное назначение и/или что это все инструменты для ревью, которые есть. Не было цели описать инструменты и все кейсы их использования.
Если для вас в статье нет ничего нового, а указанные инструменты вы используете иначе – это ок. Я не вижу тут причины для споров. Просто, возможно, вы не целевая аудитория этой статьи.
Ну и еще вариант - если задача сделана, всё работает, а задачу очень ждут и времени мало, то замечания по ревью (если они не критичные) можно вынести в отдельную задачу с техдолгом и взять ее в следующий спринт (если у вас спринты).
1-2 дня - это максимум на ожидание ревью. Обычно в тот же день или на следующий ревью проходит. Вы описали прям суровый вариант, когда что-то сильно пошло не так (причем еще до ревью), что аж несколько раз пришлось править замечания. В реальности я даже такого не припомню, обычно одного раунда правок достаточно, максимум двух.
Если задача очень большая, то перед тем, как ее делать, также можно обсудить какие-то архитектурные моменты в команде, чтобы как раз не править потом глобально после ревью уже готовую задачу.
Ну и также в момент разработки тоже можно советоваться с коллегами по каким-то вопросам, чтобы не возникало потом каких-то больших переделок на ревью.
Самые большие ревью с большим количеством правок возникают обычно в ситуациях:
в команду пришел новый человек и это его первая задача (и возможно она была сразу большая)
задача была большая, плохо декомпозирована и возникла проблема в реализации, требуется много правок
Если такое происходит, то главное сделать выводы из ситуаций и в будущем скорректировать процессы, чтобы их избежать. Например, давать новым сотрудникам задачи поменьше, обсуждать реализацию до начала разработки задачи (общие моменты: вроде "вот тут добавляем поля в БД, здесь делаем такие-то классы, вот этот функционал будет реализован аналогично такому-то"), дробить задачи на более мелкие.
Да нет, я думаю оставлю тут ссылку потом. Если хотите, можете подписаться, но не заставляю)
Как раз уже думаю над примерно таким форматом статьи - пройтись по кейсам и описать, как решали. Судя по комментариям, актуально будет в виде такого формата сделать.
Спасибо!
Я думаю, что имеет смысл на основе вопросов в комментах сделать отдельную статью и в ней практические ситуации разобрать, т.к. это уже прям конкретные особенности команды и культуры в ней
Не соглашусь. Здесь именно про Code Review и инструменты в конце статьи могут использоваться для Code Review в командах (это не значит, что они только для этого). Более того, был опыт использования большинства из них при ревью в разных компаниях. Кстати, про Fisheye хорошее дополнение.
Но вся суть – не в инструментах, а в подходе. Можно ревьювить код задачи без специальных инструментов, а просто переключаясь в ветку задачи и смотря комиты по ней в в вашей текущей IDE. Инструменты я привела просто в качестве примеров, если вдруг кому-то нужно будет.
У нас такого, к счастью, нет) Мы в целом договорились что ревью за 1-2 дня проходит.
Но я сталкивалась раньше с такими случаями. Мы решали такие вопросы с тимлидами и в целом с четким воркфлоу в командах. Например, у нас были случаи, когда другая команда вносила правки в код нашей команды в рамках их задачи и ревью было на нас - мы договорились, что у таких ревью приоритет выше, чем у всех остальных ревью и старались их делать быстрее. Ну и в обратную сторону - аналогично. Другие команды старались наши ревью смотреть быстрее и приоритетнее.
Вообще ситуация "срочное ревью" возможна только если это багфикс чего-то на бою и обычно там не очень много кода и ревью можно быстро провести. В остальных случаях по идее не должно быть такой срочности. Если она есть, то, по-моему, тут что-то не так с процессами, возможно, на уровне приоритетов задач от PM.
Ну и в игры "тянул мой PR, я тоже потяну" - для начала просто не вступайте, это непродуктивно и никому от этого хорошо не будет. В целом это вопрос про культуру в командах. Если есть возможность, можно это обсудить на ретроспективах или донести до тимлидов команд. Чтобы был процесс, который все понимают и не было необходимости отвлекать кого-то в личке. Ну и посмотреть, почему вообще с какими-то задачами возникает такая срочность именно на этапе ревью и действительно ли она возникает или это просто разработчик хочет быстрее закрыть тикет, а то такое тоже бывает.
Если задачи хорошо декомпозированы, то временные затраты обычно не большие (+ час-два к задаче). Еще, например, у нас сейчас в команде договоренность, что задачи в статусе ревью висят не более 24 часов (1-2 дня условно) - то есть задержка релиза тоже небольшая. Если задача маленькая, то ревью вообще практически не добавляет затрат - полчаса или меньше на ревью.
Мне кажется, что в небольшой команде наоборот легче всего ревьювить. И быстрее всего. Вот когда продукт разделен на разные части и там разные команды отвечают за код, а вы отдаете в ревью что-то другой команде - то вот тут могут быть случаи, что ревью зависло и надо отдельно напоминать про него другой команде. Уже второй комментарий про опыт, наверное действительно стоит сделать отдельно статью про реализацию)
Про это как раз написано в месте - что все ревьювят всех. Я считаю, что не должно быть такого, что кто-то один в команде принимает все решения. Вы правы - это бывает очень токсично и непродуктивно + вредит продукту скорее всего. Команда все-таки должна уметь договариваться и уважать мнения друг друга. Если есть аргументы, почему какое-то решение человек считает подходящим, то можно донести это при ревью и ревьювер может пропускать код, даже если был изначально не согласен с чем-то. Спасибо, что вынесли этот кейс в комментарий.
А что именно про опыт? Часть вот этих чеклистов мы, например, использовали в команде, прям писали их даже во внутренней документации для новых сотрудников, которые раньше не делали ревью. Сейчас используем Pull Requests в GitHub для самого процесса ревью, большие задачи стараемся комитить мелкими частями. Эта статья именно больше про теорию и задумывалась. Но могу и про опыт написать отдельно, мне просто кажется, что там будет мало.