Комментарии 27
Спасибо за отчет.
Вы не анализировали динамику багов, полученных от заказчика: возросло их количество или уменьшилось? На мой взгляд увеличение времени разработки должно компенсироваться уменьшением времени исправления багов.
Вы не анализировали динамику багов, полученных от заказчика: возросло их количество или уменьшилось? На мой взгляд увеличение времени разработки должно компенсироваться уменьшением времени исправления багов.
CR позволяет уменьшить количество багов, а не уменьшить время их исправления.
без CR:
Извините, не туда нажал.
Я думаю, что количество ошибок остается тем же, но время их обнаружения сокращается + сокращается время на понимание сути ошибки, так как вам о ней говорит технический специалист, а не заказчик. А это значит, что сокращается все таки время исправления ошибок, а не количество.
Хотя если вы имеете ввиду только те ошибки, что дошли до заказчика, то соглашусь с вашей точкой зрения.
Я думаю, что количество ошибок остается тем же, но время их обнаружения сокращается + сокращается время на понимание сути ошибки, так как вам о ней говорит технический специалист, а не заказчик. А это значит, что сокращается все таки время исправления ошибок, а не количество.
Хотя если вы имеете ввиду только те ошибки, что дошли до заказчика, то соглашусь с вашей точкой зрения.
Code review косвенно влияет на время устранения багов и уменьшает вероятность возниконовения багов (то есть их количество). Поясню. Код после review, как правило, более качественный, содержит логи в правильных местах, что ускоряет процесс выснения причины бага. Однако суммарное время потраченное на баг всеми участниками процесса (тестеры, разработчики, менеджеры) сокращается не очень значительно, потому что собственно поиск проблемы и ее устранение это относительно небольшая часть суммарно потраченного времени. С другой стороны, многие баги так и не возникнут, потому что код, прошедший review, содержит меньше велосипедов и потенциально опасных решений. То, что code review уменьшает вероятность возникноовения багов, значительно экономит время коллектива.
Динамику багов не анализировали.
Могу ответить на ваш вопрос только в рамках неточных моих личных субъективных оценок.
По моему предыдущему проекту могу сказать, что дефектов при внедрении инспекций становится реально меньше, по моим ощущениям от 40% до 80%. Особенно инспекции эффективно снижают до 50% и ниже кол-во багов на старых проектах, в которых нет модульных тестов и код соответствующий. Ещё хочу отметить, что многопоточный код однозначно необходимо инспектировать, сложно одному всё предусмотреть, коллеги реально помогают находить потенциальные баги.
Багов становится меньше ещё по одной простой причине – психологический фактор.
Я, как разработчик, тщательней проверяю код и принимаю более взвешенные проектные решения, зная, что меня проверят другие разработчики.
Это уже профессиональная этика или даже гордость за свой труд, что я сделал хорошо и мне не стыдно это показать.
И наоборот, самый плохой код, который я встречал и встречаю – код, который ни кто не смотрел, кроме самого разработчика.
Даже по себе, сравнивая код, написанный приблизительно в одно и тоже время, один – ни кто кроме меня не смотрел, второй – мне проводили инспекцию. Так вот, догадайтесь, за какой код я испытываю стыд? Отвечу – за первый, который кроме меня ни кто не смотрел. Лучше я три минуты буду выглядеть дураком, чем останусь им Поэтому мой выбор – инспекция.
Честно скажу по себе, когда у нас ещё не было инспекций кода и хотел отправить драйвер для нашей платы в mainline ядра linux, то код писал и проверял очень тщательно, потому что знал – разнесут в пух и прах за плохой код Времени на него потратил на 20% больше, чем на обычный, зато код спокойно поняли и мои коллеги и инспекторы в ядре. +20% за написание качественного кода — это много или мало? Тут выбор каждый делает сам в зависимости от характера проекта.
Имхо, конечно всё.
Могу ответить на ваш вопрос только в рамках неточных моих личных субъективных оценок.
По моему предыдущему проекту могу сказать, что дефектов при внедрении инспекций становится реально меньше, по моим ощущениям от 40% до 80%. Особенно инспекции эффективно снижают до 50% и ниже кол-во багов на старых проектах, в которых нет модульных тестов и код соответствующий. Ещё хочу отметить, что многопоточный код однозначно необходимо инспектировать, сложно одному всё предусмотреть, коллеги реально помогают находить потенциальные баги.
Багов становится меньше ещё по одной простой причине – психологический фактор.
Я, как разработчик, тщательней проверяю код и принимаю более взвешенные проектные решения, зная, что меня проверят другие разработчики.
Это уже профессиональная этика или даже гордость за свой труд, что я сделал хорошо и мне не стыдно это показать.
И наоборот, самый плохой код, который я встречал и встречаю – код, который ни кто не смотрел, кроме самого разработчика.
Даже по себе, сравнивая код, написанный приблизительно в одно и тоже время, один – ни кто кроме меня не смотрел, второй – мне проводили инспекцию. Так вот, догадайтесь, за какой код я испытываю стыд? Отвечу – за первый, который кроме меня ни кто не смотрел. Лучше я три минуты буду выглядеть дураком, чем останусь им Поэтому мой выбор – инспекция.
Честно скажу по себе, когда у нас ещё не было инспекций кода и хотел отправить драйвер для нашей платы в mainline ядра linux, то код писал и проверял очень тщательно, потому что знал – разнесут в пух и прах за плохой код Времени на него потратил на 20% больше, чем на обычный, зато код спокойно поняли и мои коллеги и инспекторы в ядре. +20% за написание качественного кода — это много или мало? Тут выбор каждый делает сам в зависимости от характера проекта.
Имхо, конечно всё.
Комикс ваш? Если нет, можно ссылку на оригинал указать?
Это Cyanide and happiness — сайт оригинального комикса, русские переводы.
Комикс сами смиксовали из разных выпусков комиксов explosm.net, так что ссылки на оригинал нет :)
Чёт не надёжно у вас. Надо так:
for(;;)
Self->Destroy();
А можно у Вас картинку взять себе в одну презентацию? Обещаю указать подпись со ссылкой, какую скажете.
Да берите конечно. Не проблема! Не жалко :) Можно без надписей даже, ну или если хотите можно ссыль на сайт вставить www.ptsecurity.ru, но мы и так не обидимся.
НЛО прилетело и опубликовало эту надпись здесь
Хочется поделиться своим опытом.
CR нужно только на этапе становления, организации, «взросления» — если хотите, команды. Когда есть сомнения в том, что «кто-то» может «фейлить». Тут необходимо объяснить человеку (в идеале — всей команде) почему это «плохо», и как это сделать правильно.
Когда команда «сформирована» (self-containing team), CR уже не имеет смысла, т.к. траты на него не стоят отдачи от следствия. Настает момент «доверия» и уверенности в каждом человеке в команде.
Бывают моменты, когда всеми правдами и неправдами, HR обеспечивает неимоверную «текучку» кадров в команде — в таких случаях этап «становления» практически бесконечен. Мне искренне жаль такие команды. В них, фактически, CR является единственным средством поддерживать код в legacy стиле.
Что-то еще хотел сказать, мысль улетела… может позже напишу…
CR нужно только на этапе становления, организации, «взросления» — если хотите, команды. Когда есть сомнения в том, что «кто-то» может «фейлить». Тут необходимо объяснить человеку (в идеале — всей команде) почему это «плохо», и как это сделать правильно.
Когда команда «сформирована» (self-containing team), CR уже не имеет смысла, т.к. траты на него не стоят отдачи от следствия. Настает момент «доверия» и уверенности в каждом человеке в команде.
Бывают моменты, когда всеми правдами и неправдами, HR обеспечивает неимоверную «текучку» кадров в команде — в таких случаях этап «становления» практически бесконечен. Мне искренне жаль такие команды. В них, фактически, CR является единственным средством поддерживать код в legacy стиле.
Что-то еще хотел сказать, мысль улетела… может позже напишу…
Code review не означает недоверия, мне кажется. Ревью применяется в серьезных компаниях без особой текучки кадров, вроде Google, просто потому что две головы всегда лучше чем одна.
А в проектах вроде софта для авионики вообще каждая строчка обосновывается документами в десятикратном размере.
А в проектах вроде софта для авионики вообще каждая строчка обосновывается документами в десятикратном размере.
Нет, что вы — CR это никак не показатель недоверия! Это один из механизмов тестирования кода!
Наоборот, отсутствие необходимости CR характеризует «качество» команды. Понятное дело, все свести к минимуму нереально, но минимизировать затраты на «тестирование» (привет Automated testing) позволит рациональнее утилизировать свободные ресурсы.
Наоборот, отсутствие необходимости CR характеризует «качество» команды. Понятное дело, все свести к минимуму нереально, но минимизировать затраты на «тестирование» (привет Automated testing) позволит рациональнее утилизировать свободные ресурсы.
Кроме градации «плохо-хорошо» есть «хорошо» и «качественно»
также бывают большие проекты, в которых «команда» не владеет кодом целиком (каждый участник может с ходу поправить любой участок), а над кодом работает много команд и т.п.
Возможно, это предположение верно, если сложность решаемой задачи не растет (например, код просто «поддерживается» и нужно минимизировать ресурсы). Просто впервые слышу о том, чтобы отказывались от code review.
также бывают большие проекты, в которых «команда» не владеет кодом целиком (каждый участник может с ходу поправить любой участок), а над кодом работает много команд и т.п.
Возможно, это предположение верно, если сложность решаемой задачи не растет (например, код просто «поддерживается» и нужно минимизировать ресурсы). Просто впервые слышу о том, чтобы отказывались от code review.
Команда должна нести ответственность за свой код — так формируется дисциплина. Нельзя просить человека из левой команды ревьювнуть мой код — он потратит больше времени на вникание в суть логики, нежели на сам код. Просто листать код без вникания — бессмысленно.
Ну, и, в своей команде я пропагандирую пассивное CR — есть свободная минутка, просмотри последние юзер-стори, глянь чекины. Есть замечания — сели, обсудили, поправили. Т.е., слава богу, команда на уровне автономной — качество кода уже не обсуждается. Качество продукта регулируется тестами — UT, AT, BVT.
Ну, и, в своей команде я пропагандирую пассивное CR — есть свободная минутка, просмотри последние юзер-стори, глянь чекины. Есть замечания — сели, обсудили, поправили. Т.е., слава богу, команда на уровне автономной — качество кода уже не обсуждается. Качество продукта регулируется тестами — UT, AT, BVT.
Есть мнение, что самое лучшее Code Review — это парное программирование, ибо делается оно не ПОСЛЕ написания кода, а ВО ВРЕМЯ. И даже до.
Лично сам я ощущаю так же, лучшая инспекция – парное программирование.
По-моему, не все проекты готовы к такой методике и не для всех она подходит.
Парное программирование плохо прижилось, например, при разработке встраиваемых систем. По-моему, потому что там большое кол-во задач, когда нужно читать документацию на какую-то микросхему или прибор и потом писать по документации код. Читают все с разной скоростью, усваивают так же с разной скоростью и в разных объёмах. Да и вообще, часто нужно с железкой что-то попробовать, поэкпериментировать. Тут второму просто делать нечего. Это лично моё субъективное мнение: почему при разработке встраиваемых систем парное программирование не практикуется или практикуется редко.
Хотя для части кода – лучше именно инспекция. Например, вы портируете драйвер сетевой карты, такой код лучше чтобы проинспектировали ещё и опытные коллеги. Они найдут – где я забыл засинхронизировать доступ к ресурсу или увидят возможность рекурсивного вызова того же обработчика прерывания, а я на такую ситуацию с напарником не заложился :)
По школе помню, что лучше «контролку» проверить, прежде чем её сдать, а то пара обеспечена . А ещё лучше, если её проверит мой сосед :) (мы кстати бывало так делали в школе, проверяли работы друг у друга – находили дефекты :)
Так что, по-моему, инспекция дополняет практику парного программирования.
Инспекция позволяет посмотреть на выполненную работу спокойно и отстранённо, проверить её.
Имхо, конечно всё.
По-моему, не все проекты готовы к такой методике и не для всех она подходит.
Парное программирование плохо прижилось, например, при разработке встраиваемых систем. По-моему, потому что там большое кол-во задач, когда нужно читать документацию на какую-то микросхему или прибор и потом писать по документации код. Читают все с разной скоростью, усваивают так же с разной скоростью и в разных объёмах. Да и вообще, часто нужно с железкой что-то попробовать, поэкпериментировать. Тут второму просто делать нечего. Это лично моё субъективное мнение: почему при разработке встраиваемых систем парное программирование не практикуется или практикуется редко.
Хотя для части кода – лучше именно инспекция. Например, вы портируете драйвер сетевой карты, такой код лучше чтобы проинспектировали ещё и опытные коллеги. Они найдут – где я забыл засинхронизировать доступ к ресурсу или увидят возможность рекурсивного вызова того же обработчика прерывания, а я на такую ситуацию с напарником не заложился :)
По школе помню, что лучше «контролку» проверить, прежде чем её сдать, а то пара обеспечена . А ещё лучше, если её проверит мой сосед :) (мы кстати бывало так делали в школе, проверяли работы друг у друга – находили дефекты :)
Так что, по-моему, инспекция дополняет практику парного программирования.
Инспекция позволяет посмотреть на выполненную работу спокойно и отстранённо, проверить её.
Имхо, конечно всё.
Главное не доводить code review до придирок к ничего не значащим мелочам. Часто наблюдаю картину когда при code review большие и сложные для понимания блоки кода пролистываются, зато начинается хирургия вроде замены «1» + obj на string.Format(«1{0}», obj);
Нельзя допускать чтобы code review приводил к полной унификации всех решений, все-таки в программировании должен быть разумный допуск для творчества.
Нельзя допускать чтобы code review приводил к полной унификации всех решений, все-таки в программировании должен быть разумный допуск для творчества.
Self->Destory();
Вроде на Delphi похоже, но там не оператора ->
Впрочем этот код ВНЕЗАПНО есть в самом VCL в методе TObject.Free()
</занудство>
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Инспекция кода. Итоги