Коллеги,

пожалуйста, поделитесь ссылками на исследования, раскрывающие экономический эффект "модных" практик: design/code review, unit testing, парное программирования и прочих
Интересуют исследования на фактическом материале с цифрами.
Заранее спасибо.

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

0>пожалуйста, поделитесь ссылками на исследования, раскрывающие экономический эффект "модных" практик: design/code review, unit testing, парное программирования и прочих
0>Интересуют исследования на фактическом материале с цифрами.
0>Заранее спасибо.

В "экономический эффект" переводится затраченное время, и стоимость исправления ошибок. Так как для каждого проекта это переводится по своему, то более корректным будет разделить вопрос экономики и влиянии данных практик на простейшие софтверные метрики, определяющие экономику — трудозатраты, плотность ошибок (Defects/KLOC). Оценки и сравнительные измерения последнего, это не такая простая вещь, и работ не так много. Но кое что есть.

Начать надо с поиска индустриальной статистики по софтверным метрикам. Для примера — что найдено за 3 минуты в гугле:
http://www.cs.umd.edu/~mvz/pub/eworkshop02.pdf
“Peer reviews catch 60% of the defects.”

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


G>Начать надо с поиска индустриальной статистики по софтверным метрикам. Для примера — что найдено за 3 минуты в гугле:
G>http://www.cs.umd.edu/~mvz/pub/eworkshop02.pdf
G>“Peer reviews catch 60% of the defects.”
Подобные вещи я находил. Интересуют как раз примеры из реальных проектов, которые бы учитывали затраты на ревью против выгоды от раннего обнаружения ошибок + замедления роста техдолга.

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

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


G>>Начать надо с поиска индустриальной статистики по софтверным метрикам. Для примера — что найдено за 3 минуты в гугле:
G>>http://www.cs.umd.edu/~mvz/pub/eworkshop02.pdf
G>>“Peer reviews catch 60% of the defects.”
0>Подобные вещи я находил. Интересуют как раз примеры из реальных проектов, которые бы учитывали затраты на ревью против выгоды от раннего обнаружения ошибок + замедления роста техдолга.

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

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

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

G>>“Peer reviews catch 60% of the defects.”
0>Подобные вещи я находил. Интересуют как раз примеры из реальных проектов, которые бы учитывали затраты на ревью против выгоды от раннего обнаружения ошибок + замедления роста техдолга.

Тут все не просто. Например, по нашим метрикам, code review в среднем происходит примерно в 8-10 раз быстрее, чем написание того же кода. Т.е. как бы +10% времени.

Однако, (уже по статистике PSP/TSP Carnegie-Mellon SEI) при превышении time-on-task (непосредственно потраченного времени на проектирование, кодирование, и отладку) границы в 4 часа средний объем сделанной работы в день перестает расти — так как от накапливающегося утомления программист вносит больше ошибок, и тратит на их обнаружение и исправление больше времени.

Таким образом, если ограничить code review, скажем, 1 часом в день, то эти затраты даются бесплатно. Имеем чистую выгоду от раннего обнаружения ошибок. В этой части выводам PSP/TSP можно доверять — они получены анализом большого объема статистики с реальных проектов.

Что до понятия "техдолга" — его объективно не существует. Что существует — коэффициент "хрупкости кода" (maintainability), обозначающий среднюю стоимость неких типовых правок в той или иной часть системы. Очевидно, что если правок в некую систему Х не ожидается (или ожидается немного), то ее "хрупкость" нам не принесет больших потерь. Также очевидно, что это выходит за рамки ситуации по отдельному проекту, и что очень сложно собрать точную статистику.

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

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

B>Т.е. ты хочешь сравнить один и тот же проект, сделанный без ревью с сделанный с ревью и сравнить разницу?
B>Думаю это нереально.
SmartBear проводили похожий эксперимент: взяли завершенный проект, который делался без code review и отдали другой команде на инспекицю.
Те нашли 60% багов, выявленных в тестировании и ещё кучу новых. Там были цифры о том, что исправление этих багов сразу после ревью сэкономило
бы $200.000, но там не было информации о том, сколько времени было потрачено на ревью.

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

G>Тут все не просто. Например, по нашим метрикам, code review в среднем происходит примерно в 8-10 раз быстрее, чем написание того же кода. Т.е. как бы +10% времени.
А эти метрики учитывают только саму инспекцию или инспекцию + исправление дефектов?

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

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

G>>Тут все не просто. Например, по нашим метрикам, code review в среднем происходит примерно в 8-10 раз быстрее, чем написание того же кода. Т.е. как бы +10% времени.
0>А эти метрики учитывают только саму инспекцию или инспекцию + исправление дефектов?

Нет, это чистое время на инспекцию (ревью). Кстати, важный момент.

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

Это к слову о затратах, статистике, и пр. Они (как и выходной эффект ревью) сильно зависит от способа проведения ревью, который выбираете вы сами.

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

G>Мы закладывали время на ревью как 200 строк кода в час (без пустых строк и комментариев), и старались его соблюдать. Почему так: опыт показал, что на большей скорости ошибки ловятся как-то плохо. Понятное дело, что на меньшей скорости будет ловиться больше ошибок. Мы решили, что 200 для нас удобный и практически оправданный темп.

Это в CQG было, в команде "Одиссей". Очень давно, лет 8 назад. С++ с обилием COM — надо отметить, что этот код инспектируется довольно просто, особенно при наличии четких стандартов на кодирование, и предварительной инспекции detailed design тем же человеком (т.е. на момент кодинспекции ты уже как правило в курсе, о чем будет этот код).

Это я к тому, что абсолютные метрики надо очень осторожно переносить между платформами, продуктами, и командами.

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

G>Это в CQG было, в команде "Одиссей". Очень давно, лет 8 назад. С++ с обилием COM — надо отметить, что этот код инспектируется довольно просто, особенно при наличии четких стандартов на кодирование, и предварительной инспекции detailed design тем же человеком (т.е. на момент кодинспекции ты уже как правило в курсе, о чем будет этот код).

Ну, еще пара подробностей про тот процесс. На инспекцию detailed design отдавались откомментированные хедера (*.hpp). Проверку на соблюдение стандарта оформления выполнял отдельный человек — очень быстро. Остальные были обязаны проверять по существу.

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

G>Нет, это чистое время на инспекцию (ревью). Кстати, важный момент.
А с фиксами дефектов? По нашему опыту весь цикл ревью-исправление-контроль занимает в среднем примерно столько же времени, сколько и первоначальное кодирование. Думаем, что с этим делать.

G>Мы закладывали время на ревью как 200 строк кода в час (без пустых строк и комментариев), и старались его соблюдать. Почему так: опыт показал, что на большей скорости ошибки ловятся как-то плохо. Понятное дело, что на меньшей скорости будет ловиться больше ошибок. Мы решили, что 200 для нас удобный и практически оправданный темп.
Интересный момент, мне пока в голову не приходило включать в свои рассуждения этот параметр

G>Это к слову о затратах, статистике, и пр. Они (как и выходной эффект ревью) сильно зависит от способа проведения ревью, который выбираете вы сами.
А какой способ применяется у вас?

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

G>Таким образом, если ограничить code review, скажем, 1 часом в день, то эти затраты даются бесплатно.

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

G>Однако, (уже по статистике PSP/TSP Carnegie-Mellon SEI) при превышении time-on-task (непосредственно потраченного времени на проектирование, кодирование, и отладку) границы в 4 часа средний объем сделанной работы в день перестает расти — так как от накапливающегося утомления программист вносит больше ошибок, и тратит на их обнаружение и исправление больше времени.

Не могли бы ссылкой поделиться? Тоже слышал про это, но непосредственно ссылки на исследование не нашел .

G>Таким образом, если ограничить code review, скажем, 1 часом в день, то эти затраты даются бесплатно. Имеем чистую выгоду от раннего обнаружения ошибок. В этой части выводам PSP/TSP можно доверять — они получены анализом большого объема статистики с реальных проектов.

Логика не совсем понятна. Если 4 часа разработки кушают дневной запас маны, то почему 1 час code review вообще маны не кушает? Это не спиномозговая деятельность, а вполне себе интеллектуальная. И даже не факт, что требующая меньше усилий, чем проектирование и написание собственного кода. Я знаком со многими программистами, для которых делать cod review чужого кода тяжелее, чем писать свой. У меня такая плохая выборка?

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

Не совсем так.
Ключевая особенность peer review — то, что ваш код, написанный одним человеком (с любимыми им паттернами и не менее любимыми ошибками) проверяется другим человеком с совсем другими шаблонами мышления. Эффект "свежего взгляда".
Приведу аналогию — когда в команду приходит свежий разработчик со стороны, он в первые же дни-недели находит и набивает столько шишек, сколько "опытный разработчик в теме проекта" за полгода. Потому что новый разработчик идет максимально прямолинейно и логично. А не пытается избежать подводных граблей (грабель?), про которые "опытные" уже знают.

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

G>>Это к слову о затратах, статистике, и пр. Они (как и выходной эффект ревью) сильно зависит от способа проведения ревью, который выбираете вы сами.
0>А какой способ применяется у вас?

Я думаю, ограничивать время на ревью разумными рамками (не меньше и не больше), и стараться сделать the best в это время — это важно, и так делать правильно. В противном случае возникает слишком много самых разных вопросов.

Начиная от того, насколько это оправданно по времени, и заканчивая тем, что непонятно, насколько глубоко ревьюверу надо копать код. Ни то ни другое — непонятно. Рамки, основанные на среднем темпе ревью (SLOC/hr), позволяют ответить на оба вопроса. Обыкновенно, нам не нужно ревью слишком большой ценой, сколько бы пользы оно не приносило (если мы не запускаем ракеты в космос, где приоритеты стоят по другому), и нам не нужно дешевое ревью, если оно не ловит ошибок.

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

Кстати, парное программирование — это предельный случай ревью, происходящего непрерывно. К нему приложимы все те же самые рассуждения, и отдельное ревью для парного программирования не нужно.

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

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

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

G>>Однако, (уже по статистике PSP/TSP Carnegie-Mellon SEI) при превышении time-on-task (непосредственно потраченного времени на проектирование, кодирование, и отладку) границы в 4 часа средний объем сделанной работы в день перестает расти — так как от накапливающегося утомления программист вносит больше ошибок, и тратит на их обнаружение и исправление больше времени.

EOH>Не могли бы ссылкой поделиться? Тоже слышал про это, но непосредственно ссылки на исследование не нашел .

Несколько раз пытался найти ссылку в сети — не нашел. Но нас этому учили на курсе PSP спецы из Six Sigma Software, оно как бы надежно. Кроме того, есть мнение, что это написано в книге про PSP. Нам их выдавали, но мы все потеряли, так как несерьезно тогда относились к этому матану.

Плюс — мы на реальных проектах потом это наблюдали много раз — задирание time on task выше 4-х часов никак не ускоряет проект, он все равно завершается ровно в предсказанное хитрой PSP-тулзой время .

G>>Таким образом, если ограничить code review, скажем, 1 часом в день, то эти затраты даются бесплатно. Имеем чистую выгоду от раннего обнаружения ошибок. В этой части выводам PSP/TSP можно доверять — они получены анализом большого объема статистики с реальных проектов.

EOH>Логика не совсем понятна. Если 4 часа разработки кушают дневной запас маны, то почему 1 час code review вообще маны не кушает? Это не спиномозговая деятельность, а вполне себе интеллектуальная. И даже не факт, что требующая меньше усилий, чем проектирование и написание собственного кода. Я знаком со многими программистами, для которых делать cod review чужого кода тяжелее, чем писать свой. У меня такая плохая выборка?

А в PSP нет никакой логики — это не эмпирическая, а экспериментальная дисциплина, основанная на статистике. Вот так вот получается. Точка.

Логику можно искать для объяснения экспериментальных данных. Типа, например, переключение вида активности и темы помогает. И это правда, кстати.