Вступление: готовлю предложения по организации процесса код ревью в компании, потому читаю всякую муру. Вот наткнулся на хабре на статью "Code Review и теория вероятностей".

Автор пишет обоснование:

представим себе некоего программиста Васю. Он пишет код. Ну, потому, что он программист. Допустим, Вася — хороший программист и 75% его кода не содержит ошибок

Далее:

если Петя (примерно той же квалификации) просмотрит его код, он уменьшит количество багов вдвое (до 12.5%). Ну потому что они примерно одинаковой квалификации, но всё-таки разные люди и получается мы тратим на этот кусок работы в 2 раза больше ресурсов, значит получим в 2 раза меньше багов

Далее:

Теперь давайте посмотрим как оно есть на самом деле

И по формуле из ТВ 1 — (1-X)*(1-Y) автор получает, что не 12.5%, а всего 6.25% и на этом основании делает сабжевый вывод.

Нисколько не критикуя полезность код ревью, давайте посмотрим как на самом деле, даже применяя авторскую аргументацию. Просто следуя словам автора:

на самом деле, я, конечно, вру и вряд ли Вася такой гуру,

и подставляя вместо 0.75 число 0.5, получаю 0.75, то есть вполне "ожидаемый результат" (без ТВ), противоречащий выводу статьи.
Надеюсь понятно, что произойдёт, если взять, например, 0.4

К чему я это: сначала хотел в КУ, но потом подумалось, чтобы кому-то из нас самому не попасть в КУ, применяя аргументацию автора при защите необходимости введения код ревью в процесс разработки.

Сокращения
ТВ — теория вероятностей.

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

ry>Вступление: готовлю предложения по организации процесса код ревью в компании, потому читаю всякую муру. Вот наткнулся на хабре на статью "Code Review и теория вероятностей".

Хабр же РенТВ в мире it.


Исключения есть (отчаянно рекомендую блог МосИгры за качественный ликбез по основам построения бизнес-процессов), но их доля — примерно как доля хороших авторов в ЖЖ. Ну, т.е. шансы как с динозавром, 50:50.

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

S>Хабр же РенТВ в мире it.
записал в цитатник

You will always get what you always got
  If you always do  what you always did

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

ry>Вступление: готовлю предложения по организации процесса код ревью в компании, потому читаю всякую муру. Вот наткнулся на хабре на статью "Code Review и теория вероятностей".

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

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

K>Вообще-то если человек заранее знает, что он своё дерьмо творчество
K>будет другому человеку показывать, он изначально по-другому писать будет.

Угу. Например, если он знает, что ревьювер очень любит на каждый чих объявлять константы и делать функции с единственным выходом, то чтобы не трепать себе нервы, он будет сразу писать что-нибудь типа такого:

public String getCurrentUserDisplayStyle() {
  String result = null;
  try {
    User user = getCurrentUser();
    if (user == null) {
      user = getGuestUser();
    } else {
      if (user.isNew() and !user.isBanned()) {
        result = DISPLAY_STYLE_FOR_NEW_USER;
      } else if (user.isBanned()) {
        result = DISPLAY_STYLE_FOR_BANNED_USER;
      } else if (user.isAdmin()) {
        result = DISPLAY_STYLE_FOR_ADMIN;
      }
    }
    if (result == null) {
      result = DEFAULT_DISPLAY_STYLE;
      try {
        List<DisplayStyle> styles = getUserCustomDisplayStyles(user);
        for (DisplayStyle : style) {
          if (style.isActive() && style.isSelected()) {
            StringBuffer buf = new StringBuffer();
            buf.append(CUSTOM_DISPLAY_STYLE_PREFIX);
            buf.append(COMMON_PREFIX_DELIMITER);
            buf.append(style.getName());
            result = buf.toString();
          }
        }
      } catch (UnsupportedFeatureException e) {
        log.info(CUSTOM_DISPLAY_STYLES_IS_NOT_SUPPORTED_ERROR_MESSAGE);
      }
    }  
  } catch (Exception e) {
    // User is not logged in or not found
    // TODO: Process actual exceptions and log it later
    throw new IllegalStateException(UNKNOWN_ERROR_MESSAGE);
  }
  return result;
}

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

K>Поэтому результат может быть и в десять раз.

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

PS Это я не к тому, что code review не нужен, боже упаси. Просто оно, как и прочие методики, нифига не серебрянная пуля. А значит фигня эти хабровские вероятности и прочая математика — при разных условиях количество багов после их внедрения может как сокращаться, так и расти. Единственное, что дает по-настоящему результат в команде — это опыт ее участников, остальное все — это уже специи.

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

Я бы сказал что ревью действует как "фильтр" — если команда "настроена" правильно, после ревью будут оставаться хорошие практики, а плохие давиться.
А если неправильно — всё будет наоборот, или просто никак.

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

K>>Поэтому результат может быть и в десять раз.
П>А может и не быть. Все зависит от того, что именно команда понимает под "хорошим кодом" и насколько харизматичен ее член/тимлид, который это понимание сумел пропихнуть в качестве общепринятого.
П>PS Это я не к тому, что code review не нужен, боже упаси. Просто оно, как и прочие методики, нифига не серебрянная пуля. А значит фигня эти хабровские вероятности и прочая математика — при разных условиях количество багов после их внедрения может как сокращаться, так и расти.

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

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

П>Единственное, что дает по-настоящему результат в команде — это опыт ее участников, остальное все — это уже специи.

опытных людей сложнее направлять. не все готовы подстраиваться под других.
всё-таки опыт != профессионализм (а тут много чего притягивается в этот термин)

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

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

ry>Вступление: готовлю предложения по организации процесса код ревью в компании, потому читаю всякую муру. Вот наткнулся на хабре на статью "Code Review и теория вероятностей".

ry>Автор пишет обоснование:
ry>

ry>представим себе некоего программиста Васю. Он пишет код. Ну, потому, что он программист. Допустим, Вася — хороший программист и 75% его кода не содержит ошибок

ry>Далее:
ry>

ry>если Петя (примерно той же квалификации) просмотрит его код, он уменьшит количество багов вдвое (до 12.5%). Ну потому что они примерно одинаковой квалификации, но всё-таки разные люди и получается мы тратим на этот кусок работы в 2 раза больше ресурсов, значит получим в 2 раза меньше багов

ry>Далее:
ry>

ry>Теперь давайте посмотрим как оно есть на самом деле

ry>И по формуле из ТВ 1 — (1-X)*(1-Y) автор получает, что не 12.5%, а всего 6.25% и на этом основании делает сабжевый вывод.

ry>Нисколько не критикуя полезность код ревью, давайте посмотрим как на самом деле, даже применяя авторскую аргументацию. Просто следуя словам автора:
ry>

ry>на самом деле, я, конечно, вру и вряд ли Вася такой гуру,

ry>и подставляя вместо 0.75 число 0.5, получаю 0.75, то есть вполне "ожидаемый результат" (без ТВ), противоречащий выводу статьи.
ry>Надеюсь понятно, что произойдёт, если взять, например, 0.4

ry>К чему я это: сначала хотел в КУ, но потом подумалось, чтобы кому-то из нас самому не попасть в КУ, применяя аргументацию автора при защите необходимости введения код ревью в процесс разработки.

ry>Сокращения
ry>ТВ — теория вероятностей.

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

ry>Вступление: готовлю предложения по организации процесса код ревью в компании, потому читаю всякую муру. Вот наткнулся на хабре на статью "Code Review и теория вероятностей".

Автор просто не рубит в теории игр и в кодревью. Вероятность ошибки в коде после кодревью равна вероятности ошибки последнего отревьювершего код. Никакого перемножения вероятности там нет. Если за подованом будет ревьювить мастер — это одно, если за мастером подаван это другое. А по формуле одно и тоже.

Есть баги простые, есть сложные. Какие то баги легко найти, какие то сложно. Нельзя так с цифрами вольно обращаться. Хитрый баг легко может проскользнуть мимо тысяч глаз. Например примитивнейший баг с переполнением в бинарном поиске публиковался в куче книг, был, например, в стандартной библиотеке Java и, наверняка, во многих других библиотеках. Также в библиотеке Java и некоторых других языков нашли баг в алгоритме сортировки, довольно хитрый баг, нашли его, попытавшись его верифицировать. Фиг такой баг найдут какие ревью. Тут надо сидеть и алгоритм расписывать-разбирать днями до последней косточки.

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

Про Code Review я однозначно говорю да
1. Нахождение дефектов, в противном случае они стрельнут либо у тестировщика, либо у пользователя. В результате получаем на ранней стадии более стабильный софт, в будущем будет фикс уже других дефектов
2. Остальные члены команды в курсе что происходит в проекте, не по наслышке. Несколько человек знают о том как работает тот или иной функционал, взаимозаменяемость.
3. Формируется общий взгляд команды на дизайн и стиль кода. Время на понимание чужого кода уходит меньше т.к. стиль везде одинаковый.

С точки зрения менеджерства, ревью вносит разнообразие в роаботу программиста.

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

B>Если за подованом будет ревьювить мастер — это одно, если за мастером подаван это другое. А по формуле одно и тоже.

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

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

ry>Вступление: готовлю предложения по организации процесса код ревью в компании, потому читаю всякую муру. Вот наткнулся на хабре на статью "Code Review и теория вероятностей".

В данное время использую не обзоры кода, а парное программирование, тот же vnc. Дело в том, что различие навыков которые нужно объединить для достижения цели слишком велико. Выгоднее привести код общему знаменателю, в том числе и архитектуру, а потом уже писать его отдельно и проводить обзоры.

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

А ещё традиционные системы управления проектов рассматривают обзоры кода как задачи. Те в свою очередь представлены в виде функциональности (feature) и совершённых ошибок (bugs). Таким образом обзоры кода можно рассматривать не только как средство устранения ошибок, но и как инструмент изменения функциональности. Опять же авторство кода никуда не пропадает.

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

Чукча приходит в издательство и представляет свою книгу.
Редактор смотрит и видит вместо букв — неведомые закорючки.
Он спрашивает:
— Чукча, ты читать вообще умеешь?
— Чукча, однако, не читатель. Чукча — писатель.

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

ry>>Вступление: готовлю предложения по организации процесса код ревью в компании, потому читаю всякую муру. Вот наткнулся на хабре на статью "Code Review и теория вероятностей".

V>В данное время использую не обзоры кода, а парное программирование, тот же vnc. Дело в том, что различие навыков которые нужно объединить для достижения цели слишком велико. Выгоднее привести код общему знаменателю, в том числе и архитектуру, а потом уже писать его отдельно и проводить обзоры.
Мы всё воспринимаем через призму своих опыта и знаний. Парное программирование — супер, у меня был опыт, правда, небольшой. Но пойди и докажи бизнесу его эффективность. Супер — это ведь на моём личном восприятии (тем более, что я был неопытным, а работал с гуру). А для бизнеса? Повторюсь, в данный момент готовлю предложения по внедрению код ревью в компании. А компания — самый крупняк в мире в своей области, куча офисов и клиентов по всему миру. И жила до сих пор без всяких код ревью, и занимает ведущие позиции на рынке. Огромный объём кода. Привести его к общему знаменателю? ("Где деньги, Зин?" (с) ) Внедрить бы код ревью как можно безболезненнее, чтобы проще было и разработчикам, и менеджерам, при этом чтобы трудно было обойти данный шаг в процессе разработки (в идеале, невозможно), не сильно увеличивая ресурсы, необходимые для проекта, встроить в текущие процессы.

Прошу прощения, что многое поскипал. Нисколько не сомневаюсь, что твои мысли и действия абсолютно правильны в тех условиях, в которых варишься именно ты. Достаточно много можно говорить: у каждого свой опыт; куча нюансов; устоявшиеся процессы в компаниях; личные предпочтения, наконец.

V>

V>— Чукча, однако, не читатель. Чукча — писатель.

Все мы немного чукчи (или много? )

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

ry>Мы всё воспринимаем через призму своих опыта и знаний. Парное программирование — супер, у меня был опыт, правда, небольшой. Но пойди и докажи бизнесу его эффективность. Супер — это ведь на моём личном восприятии (тем более, что я был неопытным, а работал с гуру). А для бизнеса? Повторюсь, в данный момент готовлю предложения по внедрению код ревью в компании. А компания — самый крупняк в мире в своей области, куча офисов и клиентов по всему миру. И жила до сих пор без всяких код ревью, и занимает ведущие позиции на рынке. Огромный объём кода. Привести его к общему знаменателю? ("Где деньги, Зин?" (с) ) Внедрить бы код ревью как можно безболезненнее, чтобы проще было и разработчикам, и менеджерам, при этом чтобы трудно было обойти данный шаг в процессе разработки (в идеале, невозможно), не сильно увеличивая ресурсы, необходимые для проекта, встроить в текущие процессы.
Строго говоря, личное впечатление ничего не значит. У многих есть личное впечатление, что гомеопатия их лечит, а доказательная медицина говорит, что это всё фуфло.

Чтобы доказать нужность чего-то бизнесу, надо показать, что это улучшит показатели, интересные бизнесу.
Ты это можешь сделать? Если да, то проблем нет. Если нет, то откуда ты сам знаешь, что это нужно не только тебе?

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

0>Чтобы доказать нужность чего-то бизнесу, надо показать, что это улучшит показатели, интересные бизнесу.
0>Ты это можешь сделать? Если да, то проблем нет. Если нет, то откуда ты сам знаешь, что это нужно не только тебе?
Именно об этом я и говорю: лично я не могу доказать бизнесу эффективность парного программирования. Я ведь и себе не могу этого доказать. А мои личные впечатления мало кому интересны.

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

ry>Вступление: готовлю предложения по организации процесса код ревью в компании, потому читаю всякую муру.

прочитай и моё, из личного опыта
1. в первую очередь это не посик багов а именно обмен ноу-хау разработчиков
2. общий стандарт(Code Conventions) позволяет легко разработчикам выполнять работы в различных разделах большого
проекта или в других проектах(= взаимозаменямость коллег), код ревью обеспечивает выполнение этого стандарта всеми.
3. особенно в сложном дизайне к примеру COM объектов да и сложных алгоритмах важно не пропустить
через релиз конструкцию или ошибочную или не имеющую будущее, 2 человека тут всяко лучше одного.

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

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

ry>Именно об этом я и говорю: лично я не могу доказать бизнесу эффективность парного программирования. Я ведь и себе не могу этого доказать. А мои личные впечатления мало кому интересны.
Окей, а что для твоего бизнеса было бы доказательством?

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

pik>прочитай и моё, из личного опыта
pik>или коротоко — тим с код ревью имеет значительные преимущества перед тимом без оного
Спасибо. Правда, лично мне не нужно доказывать эффективность код ревью. Я прошёл путь развития в одной из аутсосрных компаний от СММ3 до СММ5, причём она первой в России сертифицировалась на 5 уровень. И прошёл путь становления в ней процессов формальных код инспекций.
Только не подумай, что я против описания чьего-то собственного опыта. Обязательно нужно писать. Писать о своём опыте, о своём видении. Это нужно опытным, это нужно молодым. Думаю, нужно писать больше о конкретных ситуациях, потому что теоретические изыскания мы прочитаем в книжках. Уверен, не нужно здесь стесняться чесать свой ЧСВ и обязательно рассказывать о своих успехах, вполне конкретных достижениях. Это же ещё и очень интересно и познавательно.

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

0>Окей, а что для твоего бизнеса было бы доказательством?
Это не мой бизнес. А интересно — сколько денег это принесёт.