Почитал тут книжку о TDD, и подумал о его ценности и вообще зачем он нужен.
Как известно, технологии пр-ва ПО — ни сколько не наука, а набор ремесленнических навыков, припудренный толстым слоем ничем не подтверждённых хайпа и маркетинга.
В данном случае меня привлёк тезис о том, что TDD создан не столько для тестирования, сколько для инкрементального создания дизайна, лаконичного, понятного и простого для дальнейших изменений в любой момент разработки.
А юнит-тесты создаются как побочный эффект, полезный бонус.
Но если посмотреть на те примеры, которые приводятся как иллюстрация процесса с использованием TDD, все архитектурные изменения, вносимые в код в процессе рефакторинга на каждом цикле TDD, можно с таким же успехом выполнять без всякого TDD просто рисуя диаграммы на бумаге, обдумывая недостатки той или иной архитектуры, и внося в неё изменения в соотв. с вышеназванными принципами (лаконичность, простота изменения, самодокументированность).
Т.е. для любой последовательности изменений в рамках TDD существует последовательность изменений в рамках традиционных диаграмм в стиле UML. Только в случае с UML в результате получается проектная документация, а не юнит-тесты.

А т.к. применение TDD абсолютно не заменяет применение лучших практик (паттерны, проверенные на практике приемы реализации ООП-систем на конкретном языке), становится не понятно, почему TDD преподносится как замена традиционному подходу в проектировании ПО? Ну типа "сейчас уже никто не рисует диаграммы, а модно аджайл и TDD".

Если мне не изменяет память, то у Кента Бека в книге "Экстремальное программирование. Разработка через тестирование" все не совсем так, а даже совсем не так. Разработка через тестирование (aka TDD) выполняется в 2 шага: на первом шаге пишет спецификацию в виде теста и заставляем выполниться тест самым простым и естественным образом, на втором шаге — делаем рефакторинг. Рефаткоринг именно с применением шаблонов, т.е. разделять тут проектирование и TDD неверно. TDD в данном случае, на мой взгляд, скорее поддержка и защита от дурака (чтобы быстро не наговнокодить и не сделать работу "на отвяжись"). Также не стоит забывать что хорошо спроектированнная система — хорошо и легко тестируется (это должно быть одной из фичей программного продукта), а написание тестов и позволяет держать кодовую базу в состоянии "хорошей" тестируемости.

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

__> не понятно, почему TDD преподносится как замена традиционному подходу в проектировании ПО? Ну типа "сейчас уже никто не рисует диаграммы, а модно аджайл и TDD".
Потому, что в наше время всё новое (или выкопанное из сундуков старое) всегда преподносится тем, кто придумал или выкопал, как революция, изменяющая мир.
А уж тем более, такими мощными маркетологами, как Бек, Сазерленд и т.п. Не обращайте внимания.
TDD — это просто один из инструментов, который в каких-то случаях подходит хорошо, в каких-то плохо.
Для создания архитектуры, в частности, он плох в большей части случаев.
А для упрощения поддержки и обеспечения большей свободы при модификации кода — чаще всего как раз подходит хорошо.

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

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

V>TDD — это просто один из инструментов, который в каких-то случаях подходит хорошо, в каких-то плохо.
V>Для создания архитектуры, в частности, он плох в большей части случаев.
V>А для упрощения поддержки и обеспечения большей свободы при модификации кода — чаще всего как раз подходит хорошо.
У меня такое ощущение, что больше всего TDD подходит для очень маленьких команд, в идеале с одним единственным разрабом.
Я не могу себе представить, как можно организовать работу нескольких человек, когда стадии циклов TDD так тесно зависимы друг от друга.

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

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

__>> не понятно, почему TDD преподносится как замена традиционному подходу в проектировании ПО? Ну типа "сейчас уже никто не рисует диаграммы, а модно аджайл и TDD".
V>Потому, что в наше время всё новое (или выкопанное из сундуков старое) всегда преподносится тем, кто придумал или выкопал, как революция, изменяющая мир.
V>А уж тем более, такими мощными маркетологами, как Бек, Сазерленд и т.п. Не обращайте внимания.
V>TDD — это просто один из инструментов, который в каких-то случаях подходит хорошо, в каких-то плохо.
V>Для создания архитектуры, в частности, он плох в большей части случаев.
V>А для упрощения поддержки и обеспечения большей свободы при модификации кода — чаще всего как раз подходит хорошо.

TDD это ещё и другой способ взаимодействия с заказчиком. Классический TDD подразумевает постоянное и тесное взаимодействие с заказчиком во время всего периода разработки. В идеале — представитель заказчика есть часть команды. Целью является установка доверительных отношений, что бы не было такого: "Они там всего одну новую кнопку добавили, а цена взлетела на 1000$" Здесь заказчик видит как реализуется проект и какие издержки несёт исполнитель.

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

__>Т.е. для любой последовательности изменений в рамках TDD существует последовательность изменений в рамках традиционных диаграмм в стиле UML. Только в случае с UML в результате получается проектная документация, а не юнит-тесты.
Как там говорилось?.. Популярность UML стала падать после того, как некоторые осознали, что неправильные диаграммы дают неправильный код.
Во-первых, с проектной документацией и диаграммами на бумаге есть серьёзная проблема: не существует способа проверить соответствие кода и документации. В документации может говориться одно, а работать оно может совершенно по-другому. Что делает ценность такой документации отрицательной — тратишь время на изучение, а потом выясняется что на самом деле всё не так. Набор тестов это по сути и есть проектная документация — но гарантированно правильная документация — формально проверяемая.
Во-вторых, диаграммы на бумаге очень плохо переживают изменение требований, что является необходимым в реалиях современной разработки ПО.
В-третьих, TDD не запрещает рисовать диаграммы — рисуй, если это действительно привносит какую-то ценность в проект. Обычно так и делают, но такие диаграммы требуются только на достаточно высоком уровне описания проекта, а юнит-тесты, например, могут описывать конкретную реализацию мельчайших модулей, под которую бумаги не хватит всё описывать.

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

V>>Для создания архитектуры, в частности, он плох в большей части случаев.
V>>А для упрощения поддержки и обеспечения большей свободы при модификации кода — чаще всего как раз подходит хорошо.
__>У меня такое ощущение, что больше всего TDD подходит для очень маленьких команд, в идеале с одним единственным разрабом.
__>Я не могу себе представить, как можно организовать работу нескольких человек, когда стадии циклов TDD так тесно зависимы друг от друга.
Каждый делает часть проекта и тесты для неё. Ничего специально организовывать не надо. Ну, разве что, используемые фреймворки и архитектуру интеграционных тестов, если они есть.

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


Q>TDD это ещё и другой способ взаимодействия с заказчиком. Классический TDD подразумевает постоянное и тесное взаимодействие с заказчиком во время всего периода разработки. В идеале — представитель заказчика есть часть команды.
Ага, я про этот "идеал" в каждой второй книжке вижу про аджайл и всё такое. Только вот одна проблема: это не работает. По крайней мере, в аутсорсинге (в продуктовой компании может сраюотать).
Не для того заказчик нанимал команду, чтобы с ней плотно работать, а для того, чтобы ему всё сделали
А передача знаний ещё и через "представителя", которого назначают от балды — вообще кошмар. Мы вместо этого бизнес-аналитиков используем, гораздо удобнее.

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

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


Q>>TDD это ещё и другой способ взаимодействия с заказчиком. Классический TDD подразумевает постоянное и тесное взаимодействие с заказчиком во время всего периода разработки. В идеале — представитель заказчика есть часть команды.
V>Ага, я про этот "идеал" в каждой второй книжке вижу про аджайл и всё такое. Только вот одна проблема: это не работает. По крайней мере, в аутсорсинге (в продуктовой компании может сраюотать).
V>Не для того заказчик нанимал команду, чтобы с ней плотно работать, а для того, чтобы ему всё сделали
V>А передача знаний ещё и через "представителя", которого назначают от балды — вообще кошмар. Мы вместо этого бизнес-аналитиков используем, гораздо удобнее.

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

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

__>Почитал тут книжку о TDD, и подумал о его ценности и вообще зачем он нужен.
__>Как известно, технологии пр-ва ПО — ни сколько не наука, а набор ремесленнических навыков, припудренный толстым слоем ничем не подтверждённых хайпа и маркетинга.
Ты так говоришь, как-будто "набор ремесленнических навыков" — это плохо.

__>Но если посмотреть на те примеры, которые приводятся как иллюстрация процесса с использованием TDD, все архитектурные изменения, вносимые в код в процессе рефакторинга на каждом цикле TDD, можно с таким же успехом выполнять без всякого TDD просто рисуя диаграммы на бумаге, обдумывая недостатки той или иной архитектуры, и внося в неё изменения в соотв. с вышеназванными принципами (лаконичность, простота изменения, самодокументированность).

Теоретически можно писать код сразу без багов, но на практике то трудно и зачем-то придумали статический анализ кода, который автоматически ловит некоторые баги. С TDD также, он автоматически ловит некоторые баги дизайна.

Здравствуйте, vmpire, Вы писали:
V>Каждый делает часть проекта и тесты для неё. Ничего специально организовывать не надо. Ну, разве что, используемые фреймворки и архитектуру интеграционных тестов, если они есть.
Чтобы иметь части проекта, надо сначала определиться с архитектурой. А её в начале нет, если она создаётся в процессе ТДД.
Или в общих чертах архитектура есть, но она на столько концептуальна и эфемерна, что на орактике бесполезна, и не позволяет приступить к непосредственной реализации.

А процесс ТДД не понятно как распараллелить. Вот три стадии цикла ТДД:

1) написание теста, который заведомо не выполнится успешно (другие в ТДД не комильфо, потому что каждый новый тест должен предварять соотв. ему изменения в коде);
2) исправления в коде по принципу наименьшего сопротивления;
3) рефакторинг кода по результатам 2), если он нужен.

При выполнении п.2) каждого цикла, архиектура кода потенциально может измениться. И, даже если дизайн ООП системы не меняется в конкретном цикле, нужно делать рефакторинг или нет — зависит от результатов п.1) и п.2).
И не важно, на сколько малы изменения — суть зависимости это не меняет.
Т.о., мало того, что вполнение каждого последующего цикла зависит от результата предыдущего, стадии внутри цикла тоже зависят друг от друга.

Здравствуйте, mrTwister, Вы писали:
T>Ты так говоришь, как-будто "набор ремесленнических навыков" — это плохо.
Нет, я не говорю, что это плохо. Просто теорией здесь и не пахнет — только набор советов, разной степени полезности, с отсутствием повторяемости на однотипных проектах.
Впрочем, как и во всём, что включает человеческий фактор.
T>Теоретически можно писать код сразу без багов, но на практике то трудно и зачем-то придумали статический анализ кода, который автоматически ловит некоторые баги. С TDD также, он автоматически ловит некоторые баги дизайна.
Написание кода здесь ни при чём, речь о дизайне. С моделями в общем случае работать проще, чем с самой системой, пусть даже на простых системах это не так.

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

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

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


__>Написание кода здесь ни при чём, речь о дизайне.
Написание кода здесь при том, что это пример того, что человек ошибается и использует инструменты обнаружения ошибок. TDD — это такой же инструмент поиска ошибок в дизайне, как компилятор в синтаксисе.

__>С моделями в общем случае работать проще, чем с самой системой, пусть даже на простых системах это не так.
С некоторыми проще, с некоторыми сложнее, но в данном контексте это не важно, так как TDD не запрещает рисовать диаграммы, если есть желание.

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

____>А процесс ТДД не понятно как распараллелить. Вот три стадии цикла ТДД:

__>1) написание теста, который заведомо не выполнится успешно (другие в ТДД не комильфо, потому что каждый новый тест должен предварять соотв. ему изменения в коде);
__>2) исправления в коде по принципу наименьшего сопротивления;
__>3) рефакторинг кода по результатам 2), если он нужен.

__>При выполнении п.2) каждого цикла, архиектура кода потенциально может измениться. И, даже если дизайн ООП системы не меняется в конкретном цикле, нужно делать рефакторинг или нет — зависит от результатов п.1) и п.2).
__>И не важно, на сколько малы изменения — суть зависимости это не меняет.
__>Т.о., мало того, что вполнение каждого последующего цикла зависит от результата предыдущего, стадии внутри цикла тоже зависят друг от друга.
Если рассматривать ситуацию сугубо теоретически — то да, любой новый код (даже безотносительно TDD) может поменять архитектуру всей системы и результаты работы остальных членов команды станут нерелевантными.
Но практика говорит, что 99% работы программистов — локальные и не влияют на другие части системы.
Касательно TDD — если каждый цикл TDD (или даже каждый десятый) приводит к изменению архитектуры системы — значит команду нужно разогнать и нанять нормальных опытных разработчиков.
Потому, что если они через TDD пытаются создать архитектуру сложной системы, не уделяя внимания системному проектированию, то навыки данной команды для данного проекта недостаточны.

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

__>Почитал тут книжку о TDD, и подумал о его ценности и вообще зачем он нужен.

http://geepawhill.org/five-underplayed-premises-of-tdd-2/

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

__>У меня такое ощущение, что больше всего TDD подходит для очень маленьких команд, в идеале с одним единственным разрабом.
__>Я не могу себе представить, как можно организовать работу нескольких человек, когда стадии циклов TDD так тесно зависимы друг от друга.

Проект хромиум — обсыпан огромным количеством тестов со всех сторон. И каждая правка сопровождается добавлением новых тестов.
Возможно, на ранней стадии там была боль и унижение при организации работы, а сейчас отлично всё организовано.

__>Как известно, технологии пр-ва ПО — ни сколько не наука, а набор ремесленнических навыков, припудренный толстым слоем ничем не подтверждённых хайпа и маркетинга.
Не надо грязи. Это инженерная дисциплина, а хайп и маркетинг вещи отдельные и липнут ко всему от науки до религии.

__>А т.к. применение TDD абсолютно не заменяет применение лучших практик (паттерны, проверенные на практике приемы реализации ООП-систем на конкретном языке), становится не понятно, почему TDD преподносится как замена традиционному подходу в проектировании ПО?
Да, не заменяет. ТДД был в моде году эдак в 2004, тогда ходили шутки про архитекторов от космонавтики, проектирующих чудовищные иерархии-всемогутеры.
И каждый 2й программист мнил себя таким
На фоне этого разврата ТДД _мог_ давать здоровый минимализм.

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

__>Почитал тут книжку о TDD, и подумал о его ценности и вообще зачем он нужен.
__>Как известно, технологии пр-ва ПО — ни сколько не наука, а набор ремесленнических навыков, припудренный толстым слоем ничем не подтверждённых хайпа и маркетинга.

Разработка ПО — это очень сложная инженерная дисциплина.
Во всех сложных инженерных отраслях юнит-тестирование применяется в обязательном порядке. Категорически без исключений. И TDD, кстати, тоже встречается нередко, и чем сложнее проект, тем больше вероятность увидеть применение TDD.

__>Т.е. для любой последовательности изменений в рамках TDD существует последовательность изменений в рамках традиционных диаграмм в стиле UML. Только в случае с UML в результате получается проектная документация, а не юнит-тесты.

"В случае с UML" почему-то норовит получиться проектная документация к какому-то другому проекту. Потому что поддержание ее в актуальном состоянии в определенный момент усложняется до уровня "а ну его нафиг".
Да и не заменяет проектная документация тесты. Более того, актуальный UML нынче тупо доксигеном генерируется. Не нужен он обычно никому.

__>А т.к. применение TDD абсолютно не заменяет применение лучших практик (паттерны, проверенные на практике приемы реализации ООП-систем на конкретном языке), становится не понятно, почему TDD преподносится как замена традиционному подходу в проектировании ПО?

"Традиционный подход к проектированию ПО"? А что это? Это когда 10 месяцев "уже почти все готово", на 11 вдруг вспоминается, что "нихрена же не работает" и "нужно полностью переписать архитектуру"?