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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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% и на этом основании делает сабжевый вывод.

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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