tag:blogger.com,1999:blog-6346131298481535631.post5166699653907869257..comments2023-05-18T15:33:51.966+03:00Comments on Чудес не бывает или я ошибаюсь?: Software-Engineering Myth Busters (покрытие кода тестами, TDD, организация и распределенные команды)Maxim Shulga (aka MaxBeard12)http://www.blogger.com/profile/05615743910272666556noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-6346131298481535631.post-77247371747611333652015-04-18T12:12:48.927+03:002015-04-18T12:12:48.927+03:00Роман, спасибо. Я тоже, мягко говоря, не фанат мет...Роман, спасибо. Я тоже, мягко говоря, не фанат метрик. Но интересно когда они используются подобным образом - просто как дополнительные цифры для тех кто их любит. Меня часто спрашивают, а в чем польза автоматических тестов. Многим подобные факты с цифрами нравятся. Максим Шульга (Maxim Shulga)http://maxshulga.ru/noreply@blogger.comtag:blogger.com,1999:blog-6346131298481535631.post-5841992312469446272015-04-18T11:15:59.210+03:002015-04-18T11:15:59.210+03:00Спасибо автору за интересные материалы и хороший п...Спасибо автору за интересные материалы и хороший пост! Заставили меня задуматься о метриках, которые мы используем. Метрики - дело тонкое, и часто их используют с прицелом на подтверждение какой-то гипотезы. В данном случае гипотезой может быть: "TDD (или другая практика) позитивно сказывается на качестве продукта". Каждая практика может быть полезной, но попытки рассчитать ее полезность или оценить затраты/выгоду - это почти всегда примерные и субъективные расчеты. Возможно я просто негативно отношусь к метрикам, которые очень часто используются неправильно.Roman Sheykonoreply@blogger.comtag:blogger.com,1999:blog-6346131298481535631.post-24811691338339526602015-04-17T22:02:05.908+03:002015-04-17T22:02:05.908+03:00Если я правильно понял, то смотрелось время до рел...Если я правильно понял, то смотрелось время до релиза (с учетом того, что в качестве критерия брались баги после релиза, но без поддержки и доработок). И скорее всего это правдоподобно - выгода (в т.ч. и в ускорении) проявляется не в первый релиз, а в последующие и как раз при поддержке для фиксов. У меня так обычно было. <br />Хотя в доке не указан какой релиз подряд они TDD юзают.<br />Но можешь еще раз pdf перечитать, может я ошибаюсь :)Максим Шульга (Maxim Shulga)http://maxshulga.ru/noreply@blogger.comtag:blogger.com,1999:blog-6346131298481535631.post-58254434161824994802015-04-17T21:34:35.454+03:002015-04-17T21:34:35.454+03:00"Но, при этом время на разработку увеличивало..."Но, при этом время на разработку увеличивалось на 15-30%." - тут учитывались только голое время на разработку или суммарное время на разработку, тестирование, багфикс, поддержку и доработку? По второму критерию TDD по-любому быстрее. А если оценивали по первому критерию, то это шулерство.Andrei Solntsevnoreply@blogger.comtag:blogger.com,1999:blog-6346131298481535631.post-50775125031144101012015-04-17T16:23:51.292+03:002015-04-17T16:23:51.292+03:00Ну там есть как раз качественная разница: количест...Ну там есть как раз качественная разница: количество пост-релизных багов с TDD на 60-90% меньше. Можно это считать за качественную разницу? Ты же не считаешь, что в тех командах, где не было TDD не было и тестирования :)Максим Шульга (Maxim Shulga)http://maxshulga.ru/noreply@blogger.comtag:blogger.com,1999:blog-6346131298481535631.post-41846853999117595212015-04-17T15:39:03.809+03:002015-04-17T15:39:03.809+03:00Мне кажется что у каждого более менее жесткого под...Мне кажется что у каждого более менее жесткого подхода (TDD, SpecByExample) который ограничивает и явно задает условия проверки в начале есть свойство удлинения сроков. Свойство это видно внешнему наблюдателю - менеджеру, например. <br /><br />Другое дело что это же свойство в более расхлябанных процессах проявляется как затягивание сроков тестирования. <br /><br /><br />То есть если ты как менеджер понимаешь количественный размер бедствия (удлинение сроков на разработку на 15-30% или удлинение сроков тестирования и уже не факт что на 15-30% ) то в принципе нет никакой количественной разницы.<br /><br /><br /><br /><br />Другое дело разница качественная, да вот беда - как ее померять ?papa minosnoreply@blogger.comtag:blogger.com,1999:blog-6346131298481535631.post-34864333799208098932015-04-17T10:28:29.389+03:002015-04-17T10:28:29.389+03:00:) даже не знаю, что и ответить. То есть ты думаеш...:) даже не знаю, что и ответить. То есть ты думаешь, что используя TDD можно писать и качественней, и быстрее? <br />Согласен, интересный момент, медленнее "сейчас" или "быстрее" потом (в следующих релизах, фиксах и тп). Поэтому они и пишут про "these are decisions that managers have to make—where should they take the hit? But now, they actually have quantified data for making those decisions."Максим Шульга (Maxim Shulga)http://maxshulga.ru/noreply@blogger.comtag:blogger.com,1999:blog-6346131298481535631.post-35271454686965443662015-04-17T10:21:04.393+03:002015-04-17T10:21:04.393+03:00>>Получились такие цифры: команды с TDD писа...>>Получились такие цифры: команды с TDD писали на 60-90% лучше, чем те которые игнорировали эту практику. Но, при этом время на разработку увеличивалось на 15-30%.<br /><br />Сколько опечаток в словосочетании "нехорошо спланировали разработку" :).papa minosnoreply@blogger.com