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

[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 нужен. А кто его делать то будет?

Тот, что уже проработал некоторое количество времени.

 

[grigori]

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

 

[Eugene Bond]

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

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

 

[Sam Dark]

Ну и чтобы вернуть тему в исходное русло, привет из PHP-FIG: https://github.com/php-fig/fig-standards/pull/262/

 

[grigori]

http://devconf.ru/offers/31
Создал заявку на конфу - голосуйте за нее!