Здравствуйте, ry, Вы писали:

ry>Вот наткнулся на хабре на статью "Code Review и теория вероятностей".

Грубая подгонка. Автор заранее знает ответ. А потом просто делает подгонку под результат. В жизни все намного интереснее. Приведенные формулы требуют, чтобы надежности были независимы. Это достаточно неочевидный момент, хотя бы в силу того, что люди склонны допускать одни и те же ошибки. Во-вторых, система достаточно вариабельна по такому параметру, как затраченное время. Если у меня будет немного времени на ревью, я смогу понять только общую идею, которая использовалась. Что уже полезно с точки зрения знания архитектуры в целом. Но почти ничего не даст с точки зрения ловли багов. Если, конечно, первый программист не идиот.

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

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

Здравствуйте, pestis, Вы писали:

ry>>Извини, не согласен. Весь опыт говорит, что ревью всегда выявляет проблемы — это первое.
P>Странный у тебя опыт. В большинстве команд количество дефектов найденных в процессе ревью со временем падает до нуля. Про это даже в книжках написано.
С тем, что он падает, конечно, согласен. Но до нуля? Разработчик может свести свои ошибки к какому-то минимуму, но цена этого будет больше (это, конечно же, исключительно мои наблюдения над собой), чем затраты на код ревью с привлечением других разработчиков: я написал код, далее проверил, потом ещё перепроверил, на следующий день ещё раз. И всё равно оставлю ошибки, которые найдут другие.

ry>>А второе, если ты знаешь, что за тобой не будут просматривать код, каким бы мотивированным ты ни был, отношение к кодированию несколько меняется.
P>Это и называется "отбывать номер".
Нет. Смотри про цену выше.

P>Посмотри как работают люди в стартапах, когда у них горят глаза получить результат, а не досидеть до очередной зарплаты. Каждый баг это ЧП и мини-расследование как мы до такого докатились и что сделать чтобы этого больше не повторилось никогда.
Я работал в стартапе. И поставил там процесс разработки с полного нуля. Того состояния, которое ты описываешь, я не видел. И кстати, почти год без зарплаты по 10-14 часов практически без выходных.

P>Паттернов багов конечное число и со временем программисты учатся их предотвращать вместо того чтобы надеяться на ревью.
Абсолютно верно

ry>>И опять же не забывай о распространении знаний о проекте, обмене опытом.
P>От этого один вред. Единственный способ сделать хороший проект это индивидуальное владение кодом и общее видение архитектуры. Если Вася знает как написан модуль Пети никакого счастья это ему не принесет. Объем памяти ограничен и если Вася запомнит детали реализации чужого модуля, он автоматически забудет как устроен его собственный модуль, а это вообще никуда не годится.
Если человек не способен одновременно работать над несколькими проектами — это печально, а если он не способен держать в голове пару модулей одного проекта — я даже не знаю подходящего названия для этого

Здравствуйте, Mystic, Вы писали:

Я практически со всем с тобой согласен, кроме разве что этого:
M>Если у меня будет немного времени на ревью, я смогу понять только общую идею, которая использовалась.
M>Более пристальный анализ потребует больше времени. Более того, я не удивлюсь, что для того, чтобы достичь надежности программиста, писавшего код, придется потратить больше времени, чем на само написание кода с нуля.
если, конечно, мы с тобой по-разному понимаем, что такое много и что такое мало времени на ревью.
Вот, например, есть такой график

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

И процесс ревью не требует достигать выделенного. Достигаешь в рамках разумного времени — супер, нет — не надо.

Здравствуйте, ry, Вы писали:

ry>если, конечно, мы с тобой по-разному понимаем, что такое много и что такое мало времени на ревью.
ry>Вот, например, есть такой график
ry>Image: average_number_of_defects_found.png
ry>(взято отсюда), показывающий, что не надо тратить на ревью больше одного часа — падает его эффективность (конечно же, всё индивидуально). То есть один час на ревью — это уже много.

ry>И процесс ревью не требует достигать выделенного. Достигаешь в рамках разумного времени — супер, нет — не надо.

Это ревью чего? Одной функции? Одного коммита? Какая сложность кода? Например, я могу дать один свой сишный код на ревью, но боюсь, что одного часа будет мало для того, чтобы понять идею. Будет больше ложных срабатываний...

Здравствуйте, Mystic, Вы писали:

M> Это ревью чего? Одной функции? Одного коммита? Какая сложность кода? Например, я могу дать один свой сишный код на ревью, но боюсь, что одного часа будет мало для того, чтобы понять идею. Будет больше ложных срабатываний...

Я придерживаюсь мнения что ревью может работать только покомитно. Все остальные ревью (раз в неделю/месяц/год) скорее тупой попил бюджета.

Здравствуйте, Dziman, Вы писали:

D>Я придерживаюсь мнения что ревью может работать только покомитно. Все остальные ревью (раз в неделю/месяц/год) скорее тупой попил бюджета.
Это уже будет ближе к code inspection — родному брату code review. Макконнелл утверждает, что code inspection более эффективен, но сложнее в имплементации.

Здравствуйте, Mystic, Вы писали:

ry>>что такое много и что такое мало времени на ревью.
ry>>Вот, например, есть такой график, показывающий, что не надо тратить на ревью больше одного часа — падает его эффективность (конечно же, всё индивидуально). То есть один час на ревью — это уже много.

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

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

Здравствуйте, ry, Вы писали:

ry>Представь крупную компанию — несколько тысяч разработчиков. И, как я писал, мне нужно встроить в процессы разработки код ревью. Шаг влево, шаг вправо — и процесс станет неэффективным: либо много ресурсов на него выделять, либо мало дефектов будет выявляться. Нужно найти и обеспечить определённую оптимальность, которая будет опробоваться на пилотах, и этот процесс, конечно же, на них не завершится, а будет и далее развиваться.
Это что за компания в которой тысячи разработчиков?! помимо всех известных. Вообще раз нет ревью, то значит и не надо. Нет базы по которой можно было бы судить о его полезности и нет понмиания у менджмента.

Здравствуйте, diez_p, Вы писали:

_>Вообще раз нет ревью, то значит и не надо. Нет базы по которой можно было бы судить о его полезности и нет понмиания у менджмента.
В каком-то виде код ревью всё же присутствует. Спрос со стороны проектных и технических менеджеров есть. Раз выделили бюджет на внедрение, значит, и высший менеджмент дозрел.

Здравствуйте, ry, Вы писали:

ry>Здравствуйте, diez_p, Вы писали:

_>>Вообще раз нет ревью, то значит и не надо. Нет базы по которой можно было бы судить о его полезности и нет понмиания у менджмента.
ry>В каком-то виде код ревью всё же присутствует. Спрос со стороны проектных и технических менеджеров есть. Раз выделили бюджет на внедрение, значит, и высший менеджмент дозрел.
Плюсы выше я описывал. Но есть еще одно но, чтобы у вас действительно была польза от ревью, у вас должна быть команда, когда замечание не перерастает в конфликт, а обсуждается. С точки зрения бюджетов, надо четко понимать, сколько дефектов доходит до заказчика и сколько они стоят.

Здравствуйте, ry, Вы писали:

ry>С тем, что он падает, конечно, согласен. Но до нуля? Разработчик может свести свои ошибки к какому-то минимуму, но цена

До нуля. Ошибки становятся слишком комплексные и перестают находиться на ревью.

ry>Нет. Смотри про цену выше.

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

ry>Я работал в стартапе. И поставил там процесс разработки с полного нуля. Того состояния, которое ты описываешь, я не видел. И кстати, почти год без зарплаты по 10-14 часов практически без выходных.

Как известно, программист физически не способен работать продуктивно больше 4 часов в день. Если вы пахали по 10-14 часов, значит никакого процесса разработки там не было, а была сплошная штурмовщина и потогонка. В таком состоянии программист делает тупейшие баги, а потом часами их отлаживает. Логично что в такой ситуации код ревью работал, но это не нормально.

ry>Если человек не способен одновременно работать над несколькими проектами — это печально, а если он не способен держать в голове пару модулей одного проекта — я даже не знаю подходящего названия для этого

При чем тут способен-не способен? Объем памяти ограничен и чтобы запомнить что-то нужно забыть что-то другое. Когда человек работает над своим модулем, он держит всю информацию в оперативной памяти и исправление занимает у него 5 минут. Когда он лезет в чужой модуль, ему сперва нужно вспомнить как там все устроено, потом понять что там натворили коллеги с прошлого раза и только потом он сможет что-то поправить. Вся эта возня отнимает очень много энергии и, главное, совершенно лишает стимула повышать качество. Достаточно столкнуть задачу на минимально достаточном уровне, а разгребать проблемы придется коллегам. Единственная методология хоть что-то предлагающая для коллективного владения кодом это экстермальное программирование, и то оно начинает буксовать на проектах больше миллиона строк.

Здравствуйте, ry,

http://www.ibm.com/developerworks/rational/library/11-proven-practices-for-peer-review/

Здравствуйте, uncommon, Вы писали:

LVV>>Вообще-то в наше время статистика показывала, что у квалифицированного программиста только 10% кода — с ошибками.

U>Отсюда вывод: в функции из меньше чем 10 строк ошибок быть не может.

Значит, разбить весь код на функции меньше десяти строк, и после этого можно не тестировать.

Здравствуйте, uncommon, Вы писали:

LVV>>Вообще-то в наше время статистика показывала, что у квалифицированного программиста только 10% кода — с ошибками.

U>Отсюда вывод: в функции из меньше чем 10 строк ошибок быть не может.

Там одна ошибка — в семантике самой функции