собачники против кинофобов

Redjik

Джедай-мастер
Да любой разработчик, который уже более-менее является частью команды. Если он плохо знаком с той часть системы, которую ревьюит, то заодно примерно поймёт как она устроена.

А у вас, насколько я понимаю, сразу 2 проблемы:
1) code review нет => можно коммитить всякое говно
2) чувак не понимает устройства других частей системы, он работает только со своей. Уволился чувак => сосите копайтесь в его говне, все остальные впервые увидели этот код. Single point of failure практически :)
Обожаю твою переходы на личности =)
У нас норм все. Все же опытные ребята, жаль что у вас команда джуников, за которыми нужно каждый чих проверять.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
на самом деле, вопрос как сделать так, чтобы ребята сами писали хорошо, и не следить за всем постоянно - очень интересный, это была моя цель, и получилось :)
сейчас у нас скорее проблема с перфекционизмом - все хотят сделать хорошо, но для этого надо переписать 10 классов, и надо уговорить себя принять несовершенство мира

hit by the bus решается передачей работы над каждым модулем поочередно каждому разработчику и документированием важных алгоритмов,
а code review - ну, у качества есть цена, и есть разные участки, когда общий уровень кодинга неплохой - все вычитывать необязательно
 
Последнее редактирование:

AmdY

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

fixxxer

К.О.
Партнер клуба
команда джуников, за которыми нужно каждый чих проверять.
Проверять каждый чих, действительно, нужно только у новых членов команды, при этом, если он не дурак, стилистических ошибок уже не будет к 3-4 коммиту.

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

grigori

( ͡° ͜ʖ ͡°)
Команда форума
fixxxer, а для знания архитектуры ревью не нужен, достаточно просто поговорить и прочесть API в IDE

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

fixxxer

К.О.
Партнер клуба
Я не о знании архитектуры, а о некотором чутье правильного вектора ее развития и видении потенциальных проблем в коде в будущем. Тут скорее даже дело не в чисто программной архитектуре, а в понимании вектора бизнес-хотелок на ближайшее будущее, что как раз обычно есть только у лида. Понятно, что, в идеале такие вопросы надо решать еще на этапе постановки задачи, но на практике обычно не так =)
 

AmdY

Пью пиво
Команда форума
fixxxer, иногда и вовсе для соблюдение единого стиля говнокодинга. :(

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

fixxxer

К.О.
Партнер клуба
AmdY, ну, говнокод в одном стиле лучше говнокода в разных стилях. :) Всем приходится работать с легаси.

оно возвращается за счёт единого стиля и лучшего понимания проекта, нахождение бпгоа и регресий на ранних этапах и т.д. Да и с привычкой, они занимают пару минут, за чашкой кофе можно пяток просмотреть
ага, ну и обычно с каждым коммитером проходишь по цепочке
1) пачка комментов и требование исправлений
2) ну вроде нормально, вот тут по мелочи поправь
3) бегло проглядывая approve
4) да мержь уже сам в мастер;) на этом этапе если человеку нужен ревью он просит о нем сам
 
Последнее редактирование:

Absinthe

жожо
Не, надо хитрее, с какой-нибудь опцией можно пушить, пропуская хуки, но будет письмо на dev о том, что был not verified push или как-то так.
@codingStandardsIgnoreStart
@codingStandardsIgnoreEnd

Я другого не пойму, вот пишите code review нужен. А кто его делать то будет?
Тот, что уже проработал некоторое количество времени.
 
  • Like
Реакции: WMix

grigori

( ͡° ͜ʖ ͡°)
Команда форума
а, понятно, просто мы работаем вместе не первый год, и я знаю кто, что и как пишет
сейчас провожу интенсивный курс обучения руководства, перевел разработку с переписывания неправильно понятого на проектирование
 
Последнее редактирование:

Eugene Bond

sudo rm - rf /
вставлю свои 5 копеек: мы любую задачу начинаем с парного планирования, во время которого задача обсуждается детально, разрабатывается прототип, иногда пара тестов. в процесс вовлечен как минимум один сеньор тим-мембер (что снижает риск ошибки на стадии проектирования решения).
ревью мы устраиваем в виде "review party" - вся команда участвует. помагает обмену знаний о системе и иногда даже сеньор тим-мемберы получают фидбэк на счет своих решений

на счет @ - IMO иногда это бывает уместно, но зачастую как раз связано с неудачно-спроектированным решением
 
Сверху