если можешь что-то показать без кодинга то ты молодец и сэкономил кучу времени

Ну так если я выпускаю быстро и маленьким куском, то профит.

Разработчик в обоих случаях "вручную запускает" и дебажит

если можешь что-то показать без кодинга то ты молодец и сэкономил кучу времени

Аксура?)

Не это уже накодил

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

:))

Да наверное я бы согласился, если это не был SPA фронтенд.

Самый простой вариант это моки на аксуре, потом верстка если быстрорукий верстак

Но сейчас вместо планирования, аналитики задач и бесед с заказчиками, я занят 70% времени уговорами, разъяснениями и созданием рабочей атмосферы. Тупо как-то, не продуктивно

Олег, привет! Интересная у вас проблема. Штрафы вряд ли помогут, и вообще здесь быстрые какие-то решения вряд ли есть. То, что начали проводить 1:1 - уже здорово, дальше уже нужно пытаться разобраться с каждым разработчиком отдельно и понять, какие у кого цели, чтобы точечно мотивировать. Если у вас завтра будет время, можно было бы пообщаться голосом - дело в том, что мы работаем сейчас над сервисом, который позволяет структурировать фидбек между сотрудниками и проводить что-то вроде оценки достижения целей. Возможно, я что-то смогу посоветовать. Как минимум, проблему обсудим :)

ну тут да, есть специфика наверное. я в TDD для SPA не силен. пока ))

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

Тогда и появится контекст.

Да, SPA это гемор, там только юниты и селениумчики

Да не гемор это, просто это ДОЛГО.

Фичу выпускаешь за неделю, с тестами за 1,5-2. Через месяц "концепция поменялась", тесты - выкинул.

А долго и гемор это не одно и тоже?))

В программировании можно все, вопрос лишь во времени

И да, тесты выкинул это же касается и юнит тестов, которых неплохо бы процентов 80 покрытия держать

Аналогично и автотесты селениума, тоже поддержка много времени и переписка

выкинул код - выкинул и тесты

Зато этот овердрафт позволит равномерно развивать проект и не зависеть от монструозности проекта

Фичу выпускаешь за неделю, с тестами за 1,5-2. Через месяц "концепция поменялась", тесты - выкинул.

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

А то, что выкинуть код или тесты, мы же аджайл, должны быть готовы каждый спринт менять все нафиг :)

Антон а вот это надо измерять по-другому

выключить TDD на проекте, и смотреть как изменилась пропускная способность в % баги по отношению к бизнес ценности

и сразу будет предметный разговор :))

во! шаришь!

Таг

Приветы всем

о.. подмога подоспела )))

давай Диман, я Славу держать буду, а ты мочи его :)

и сразу будет предметный разговор :))

Хахаха, это универсальный ответ кстати :)) Что делать? Тестировать до после, замерять результат, принимать Решение

Подходит ответ на любой вопрос :)

Вот кстати, надо найти проект с историей по задачам, где было внедрено TDD, и загрузить к нам, и графики посмотреть!

#whois я Дима. Помогаю командам внедрять экстремальное программирование и писать код, за который не стыдно

Ну почему универсальный, мне самому интересно

Вообще вся правда только в статистике, а не в холиварах :))

Только вот выключить tdd не получится, так как tdd это как Agile, в первую очередь майндсеи

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

Так нет, найти какой-нибудь проект, где TDD не было, а потом стало

Вырубая tdd разработчики будут тесты писать на листочках или в голове )

кто готов заплатить 2х цену ради такого эксперимента?

э нет, так не пойдет

TDD на легаси внедрять совсем не то же самое что с нуля

Антон, одинаковых команд не бывает, ты же знаешь )))

Ну там будет J-curve

Вырубая tdd разработчики будут тесты писать на листочках или в голове )

:)

И почему на legacy, можно и не на legacy, нормального кода без тестов чтоли нет? ;)

знаю, потому и троллю )) нужна одна и та же команда и стиралка памяти или машина времени

Нельзя стиралку, ибо победит команда без TDD, ибо TDD долго внедряется, а пока внедряется все медленно и грустно

Парни, вы под TDD по-моему понимаете наличие тестов

Лернинг курв туда сюда

Не, тдд это test-code-refactor-test-code-refactor

надо обученную TDD команду сразу брать. память стирать только про доменные знания по новому проекту

Пока не умрешь))

От TDD ещё куча побочных ништяков

Про ритм работы и декомпозицию тут уже писали

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

Я уже устал смотреть на девелоперов, копящих монструозные комиты

Да, и окупится на проектах от 3 месяцев

Да, ещё любопытно, что боевого кода в единицу времени будет меньше

Кто о чем :)

Вопрос, а вот окупится ли на проектах, которые 3 года писались без TDD? Рефакторинг всего через TDD?)

Не факт, что окупится

скорее всего уже нет

Поэтому и решение принимает бизнес

Да и рефакторинг всего незачем делать

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

А рефакторинг для чего? Обычно такие проекты выкидываются и пишутся заного

Охх

А рефакторинг для чего? Обычно такие проекты выкидываются и пишутся заного

Тоже вариант, но уважаемый Джоел говорит ататата выкидывать код

Цикл там 3-5 лет обычно :) приходит новая команда, говорит "е-мое", и понеслась.

Тут проще все с нуля переписать ? (С)

Так не работает)

Всем привет! Почитала вашу переписку про TDD. Имею опыт работы с системой без него, потом переписывали уже с TDD, так как код стал не поддерживаемым, команда практически в том же составе. Так что я всеми руками за TDD. Особенно если проект на долгосрочную перспективу.

Решение писать по TDD может принять и разработчик, TDD это и персональная дисциплина. Радует как вы тут горой за TDD)

Не согласен

:)))

Решение бизнес принимает )