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

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

Мне кажется без заглядывание в то, какие изменения сделанны, в статистике будет много мусора.

Самые мои большие изменения обычно проходили ревью очень быстро, так как их не очень то и читали.

Применил автоформатирование , переименовал файл с 5К строк, добавил большой JSON в репозиторий.


Посмотрел на статистику моих изменений по одному опенсорсному проекту.
527 commits 102,902 ++ 106,413 -- При этом реально новых фич и нового кода там относительно немного.



Самые мои большие изменения обычно проходили ревью очень быстро, так как их не очень то и читали.

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

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

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

А можете подробнее описать, чем в этом плане отличается Grerrit от Gitlab'а, например.

верно подмечено, нужно пинать) а еще хорошее покрытие тестами позволяет менее тщательно смотреть ревью. а линтеры устраняют холивары за красоту кода.

Я как раз про те случаи, когда ревью как таковое смысла не имеет. Обсудили, что хотим иметь JSON с парой тысяч объектов в репозитории, я его туда положил. Нечего там особо ревьюить, а изменений на много тысяч строк. Да такое случается не часто, но за счёт размеров статистику подпортит.

Как быть, если ты пилишь большую фичу? Условное внедрение акций для клиентов принесет много кода в репу. Я без сарказма, реально хочу знать)

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

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

Публикации

Истории