Здравствуйте, 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

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

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

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

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

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

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

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

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

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

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

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

ry>Ты меня хочешь проэкзаменовать? Или помочь? Экзаменовать не надо. А если помочь, просто напиши.
А я и пишу. Откуда мне знать, какие конкретно в твоём случае связи? Я только советую тебе их поискать.
Их может и не быть. Например, если у вас там чья-нибудь карманная конторка для распила бюджетов Ну, это я утрирую.

ry>Связи, конечно, есть. Только объясни мне, как я могу их увидеть. Кто допустит меня к бухгалтерии. Косвенно, да, могу увидеть.
Я бы на твоём месте поговорил с непосредственным начальством, понял бы, о чем у него голова болит. У него оно, скорее всего, болит не о конкретных деньгах (хотя, может, и о них тоже) но и о более предметных показателях.
Время, удовлетворённость клиента, количество багов и т.п. Найти трассировку для этих показателей будет проще, чем до конечных финансовых показателей. Если у начальника голова правильно работает, то он сам должен знать, как его показатели трассируются на более высокоуровневые "бизнесовые".

ry>Вот, например, прямые убытки: увеличение необходимых ресурсов — времени, количества разработчиков, их квалификации.
Тут как раз понятно

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

Вступление: готовлю предложения по организации процесса код ревью в компании, потому читаю всякую муру. Вот наткнулся на хабре на статью "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 и теория вероятностей".

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

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

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

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

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

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

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

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

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

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

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

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

Вообще-то в наше время статистика показывала, что у квалифицированного программиста только 10% кода — с ошибками.
Это нашло нечаянное подтверждение в личном опыте...
Мы с начальником сидели в Питере в Авроре и писали очередную порцию системы.
Написал я некую подпрограммку — на ассемблере, 22 команды.
Ошибаться — негде. А не работает!
Я к ней и так, и эдак, со словами, и без слов — а не работает!
Я спрашиваю: Лев, как так может быть?!
Он: ищи 2 ошибки.
Я: Почему?
Он: по статистике 10% ошибок.
Ну, я тогда разложил все покомандно внимательно — и нашел 2 ошибки!
Вот так было примерно в 1985 году...

Но вообще-то обсуждение кода — действительно помогает.
Мы практиковали и коллективное обсуждение ДО кодирования, и часто смотрели сам код.
Посторонние глаза, если знают задачу, быстрее видят косяки в коде.
Поэтому мы задачи до и обсуждали — чтобы все примерно представляли, кто какую часть делает.
Как я теперь понимаю, у нас были что-то вроде спринтов — приезжали в командировку, обсуждали задачи, делали, уезжали.

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

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

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

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

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

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

0>>У меня сложилось такое впечатление, что тебе надо "продать" Code Review кому-то далёкому от темы, вот ты и мучаешься.
ry>Свои мучения я описал выше: как можно безболезненнее встроить КР в процессы компании, а это ведь и есть участие в формировании "цены". Но реально продавать будет уже мой начальник.
А не надо "безболезненно". Если какое-то изменение в организации было безболезненным, значит ничего не поменялось. Я помню как однажды внедряли Code Review в одной синей компании на букву "А".
В нашем отделе это свелось чистой формальности: "Вася, я тут на тебя ревью завел, нажми "ОК", чтобы чекин прошёл". Вот так к этой инициативе сверху приспособились и было очень безболезненно.
И бесполезненно

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

П>И ревьювер это проглотит, т.к. его представлениям о "правильном стиле" это будет полностью соответствовать, а разбираться в этом г...окоде досконально ему будет тупо некогда, потому что у него и своих дел полно.

Это же ява, все равно на ней сильно лучше не напишешь.

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

P>Я так скажу, в хорошей команде мотивированной на результат, а не на отбытие номера, код ревью находит ноль целых фиг десятых багов. На этапе притирки команды ревью еще как-то полезен, но через пару-тройку месяцев его можно отменять. Ну разве что для свеженанятых кодеров на испытательном сроке можно оставить.
Извини, не согласен. Весь опыт говорит, что ревью всегда выявляет проблемы — это первое. А второе, если ты знаешь, что за тобой не будут просматривать код, каким бы мотивированным ты ни был, отношение к кодированию несколько меняется. И опять же не забывай о распространении знаний о проекте, обмене опытом.
Для опытной сплочённой мотивированной команды разве что можно проводить менее формальные пост-коммитные ревью в течение всего цикла жизни проекта, да и то с оговорками, типа: для сложных/важных/критичных ситуаций пре-коммитные на стадиях внедрения и поддержки.

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

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

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

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

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

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

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

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

Здравствуйте, 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 не нужен, боже упаси. Просто оно, как и прочие методики, нифига не серебрянная пуля. А значит фигня эти хабровские вероятности и прочая математика — при разных условиях количество багов после их внедрения может как сокращаться, так и расти. Единственное, что дает по-настоящему результат в команде — это опыт ее участников, остальное все — это уже специи.

Здравствуйте, 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, Вы писали:

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

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

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

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

0>>Окей, а что для твоего бизнеса было бы доказательством?
ry>Это не мой бизнес.
Я имел в виду, тот бизнес, в котором ты сейчас работаешь

ry>А интересно — сколько денег это принесёт.
Очень хорошо.
А между CR и прочими инженерными практиками и деньгами бизнеса причинно-следственные связи есть?

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

ry>>А интересно — сколько денег это принесёт.
0>Очень хорошо.
0>А между CR и прочими инженерными практиками и деньгами бизнеса причинно-следственные связи есть?
Ты меня хочешь проэкзаменовать? Или помочь? Экзаменовать не надо. А если помочь, просто напиши.

Связи, конечно, есть. Только объясни мне, как я могу их увидеть. Кто допустит меня к бухгалтерии. Косвенно, да, могу увидеть.
Вот, например, прямые убытки: увеличение необходимых ресурсов — времени, количества разработчиков, их квалификации.
Вот косвенные выгоды: повышение качества кода, рост квалификации разработчиков, распространение знаний о проекте, ускорение введения новых разработчиков на проект и понятные из всего этого плюшки — удовлетворённость заказчика, уменьшение затрат на поиск багов (по сравнению с этапом тестирования и тем более внедрения и эксплуатации), самый эффективный способ повышения квалификации. Но это косвенные. А что делать против аргумента: мы лучшие, мы первые на рынке, мы самые крупные на нём, мы достигли всего этого без КР, так зачем нам это?

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

0>Я бы на твоём месте поговорил с непосредственным начальством, понял бы, о чем у него голова болит.
С непосредственным начальством как раз проблем никаких нет. Именно оно (он ) и является двигателем всего рационального.

0>После прояснения проблем твоего руководства тебе следует понять, как эти вещи влияют на них. Если будешь уверен, что улучшение от внедрения будет, то можно поступить так: зафиксировать показатели as is, внедрить на пилотный период Code Review, и посмотреть, куда метрики пойдут. Если пойдут не туда, то морщить лоб и думать, что пошло не так К такой постановке предложения, я думаю, руководство будет более открыто.
Спасибо. Но опять-таки и предварительный план внедрения уже есть, и пилоты там запланированы, но ещё не подобраны проекты, на которых это будет пилотироваться. А что подбирать, если я ещё не до конца всё наформулировал, не все юз кейсы расписал. Но куда хуже то, что я ещё не во все процессы компании въехал — недавно работаю.

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

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

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

Че-то я не представляю, как ревьюер внесёт ошибку в код.
Ревьюер может дать два типа реакции :
1) Тут написано непонятно
2) Тут не учтён такой-то случай
Он же вьюер (то есть смотритель) а не писатель.

По крайней мере у нас так ревьюили.

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

ry>Мы всё воспринимаем через призму своих опыта и знаний. Парное программирование — супер, у меня был опыт, правда, небольшой. Но пойди и докажи бизнесу его эффективность.

А я и не говорю про эффективность для бизнеса, мне в основном необходимо качество, а для бизнеса более весомый показатель деньги и время. Могу объяснить в виде метафор. Например, я обычный программист 1-го уровня, и другой обычный программист 1-го уровня, а вместе мы для данной конкретной задачи тормозной программист 10-го уровня. Через месяц или два обмениваясь уникальными знаниями каждый по отдельности может достичь по подобным задачам 5-го уровня, но вместе мы уже тормозной программист 15-го уровня. А вот когда общий уровень перестанет возрастать, и индивидуальный уровень к нему приблизится, можно будет разделиться, ну и если надо проводить обзоры кода. Парное программирование как таран взламывающий неприступную крепость. Если бы не это, то можно было бы обойтись без него.

Про обзоры кода есть замечательная тема

Автор:
Дата: 12.01.13

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

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

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

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

0>У меня сложилось такое впечатление, что тебе надо "продать" Code Review кому-то далёкому от темы, вот ты и мучаешься.
Свои мучения я описал выше: как можно безболезненнее встроить КР в процессы компании, а это ведь и есть участие в формировании "цены". Но реально продавать будет уже мой начальник.

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

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

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

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

pik>1. в первую очередь это не посик багов а именно обмен ноу-хау разработчиков

Цель code review (может, ты имел в виду более точный термин code inspection?) — именно поиск ошибок и проблемных мест в коде, действительных или потенциальных/кажущихся. Если процедура не выполняет эту функцию, то это пустая трата времени.

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


V_S>Цель code review (может, ты имел в виду более точный термин code inspection?) — именно поиск ошибок и проблемных мест в коде, действительных или потенциальных/кажущихся. Если процедура не выполняет эту функцию, то это пустая трата времени.

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

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

нет, код перед коммитом должен быть разумеестя бешошибочно функционален, т.е. или автоматический или
ручнной юниттест проходить безошибочно и выполнять функции описанные в ТЗ или подобном. код ревьюер
именно смотрит в первую очередь на реализацию в соответствии с Code Conventions, максимальную простоту(понятность)

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

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

ry>Извини, не согласен. Весь опыт говорит, что ревью всегда выявляет проблемы — это первое.

Странный у тебя опыт. В большинстве команд количество дефектов найденных в процессе ревью со временем падает до нуля. Про это даже в книжках написано.

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

Это и называется "отбывать номер". Посмотри как работают люди в стартапах, когда у них горят глаза получить результат, а не досидеть до очередной зарплаты. Каждый баг это ЧП и мини-расследование как мы до такого докатились и что сделать чтобы этого больше не повторилось никогда. Паттернов багов конечное число и со временем программисты учатся их предотвращать вместо того чтобы надеяться на ревью.

ry>И опять же не забывай о распространении знаний о проекте, обмене опытом.

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

Здравствуйте, 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>С тем, что он падает, конечно, согласен. Но до нуля? Разработчик может свести свои ошибки к какому-то минимуму, но цена

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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