Признаю, я был не внимателен и прочитал как «тесты не нужны».
Ошибка выжившего.
Те, кому легче формировать понимание предметной области тестами, используют TDD по факту своей работы. Они бы его использовали, даже если бы такого названия не было.
Тем, кому легче разбираться с предметной областью не через тесты, TDD мешает и они от него отказываются.
Абсолютно согласен, это по сути — моя гипотеза, но иными словами. Ваша формулировка даже более удачная!
На самом деле можно выделить не две, а три модели предметной области:
модель в коде функциональности;
модель в коде тестов;
модель в голове разработчика.
Это отличная цитата из статьи, но не противоречит ли Ваше высказывание Вашей же статье?
Даже если мы признаем утверждение
Тесты — это хороший пример дублирования, метода повышения надёжности за счёт реализации нескольких копий критической части системы. Нюанс заключается в том, что в нашем случае через дублирование контролируется не работа результирующей системы, а точность её формальной модели.
истинным (оно, как минимум, правдоподобно), это, тем не менее, не исключает возможности влияния тестов на качество продукта.
Более того, пропоненты TDD, как раз считают, что смысл TDD не в тестах, а в понимании и точности модели.
При подходе написания скелета, архитектуры, интерфейсов, не делаем ли мы преждевременных предположений? Как быть, если вдруг окажется, что архитектура неэффективна или нереалезуема для конкретного приложения, среды или языка программирования?
Гипотеза о целесообразности написание тестов до кода я думаю формулируется, примерно, так:
При TDD тесты являются формальным описанием (микро)задачи. Таким образом, как только тест становится «passed» мы можем сделать вывод, что (микро) задача выполнена.
Также, при таком подходе исчезает соблазн «подгонять» тесты под код (а то будет как в лабораторных по теории цепей в старом, добром университете — "пофиг что намеряли, пиши что соответствует заданию, а то все поймут что мы цепь хреново сделали")
Согласен, для таких задач Unit-Test слабо применимы. Хотя, есть примеры, когда в таких задача прекрасно работал Test-First подход с BDD фреймворками, например — www.youtube.com/watch?v=bny86gxbUcg
Это отличное замечание! Если честно, я (интуитивно) предполагал, что в языках с сильной и статической типизацией TDD принесет улучшения производительности за счет автоматической генерации кода на основе тестов (как минимум определения классов и методов)
Это отдельная грань проблемы, которую нужно исследовать.
Ваш аргумент отлично работает против ATDD (Acceptance Test-driven development), но не TDD.
В классическом TDD тест — это Unit-test, а тестируемый объект это метод, или даже отдельная ветка исполнения в методе. Готов поспорить, что на этом уровне в любом приложении будут детерминированные результаты.
Вся ваша статья вроде бы о том, что научные обоснования — не обоснования. :)
Не совсем, скорее о том, что у нас нет (пока?) убедительных доказательств любого из утверждений:
1) TDD эффективен
2) TDD не эффективен
3) TDD не оказывает влияния на эффективность
И, соответственно, нужны еще исследования.
Но, насколько я пониманию
Несколько проектов переписывались с нуля несколько раз, всё что создавалось на начальных этапах просто выбрасывалось.
никак не противоречит применимости TDD, т.к. изменение самих тестов является одним из возможных шагов в «цикле» TDD. С учетом того, что фокус Unit Test это метод или даже определенная ветка в методе, наличие Т.З. не должно оказывать существенного влияния.
Это тоже хорошая гипотеза, но я склонен считать, что разработчик является бОльшим фактором. К примеру, на проекте, где тех лид утверждал что TDD не применимо Эиз-за предметной области" — я «на слабо» сделал case study и показал применимость и улучшение качества, но это в тех случаях, когда я был автором кода.
У вас есть какие-нибудь научные обоснования, или это основано на Вашем опыте?
В любом случае — гипотеза принята к рассмотрению, спасибо.
Формализуйте, пожалуйста, понятие exploratory programming? Можно конкретный пример? Я тогда бы учел это в исследовании, у меня, по ходу дела, отличная идея диссертации намечается.
Может есть смысл проверить актуально ли в Германии — в Англии некоторые поставщики электоэнергии могут засчитывать неподтребленное электричество, произведенное солнечными панелями и отправленное в общую сеть. Не знаю точно, как это физически устроенно, но рекламку видел.
А Story Point это не про сложность и временные рамки, а про «размер» стори.
Суть не в том, чтоб начать оценивать стори в сторипойнтах вместо часов, а в том, что б при оценке стори мы отталкивались от некого бейзлайна.
Пример: вот была у нас стори, мы решили что она 1, а эта вот выглядит побольше, но меньше той, что была 3, значит оцениваемая сторя где-то 2
Т.е. чтоб мы перестали оценивать в часах (потому что такие оценки все равно неправда, и пальцем в небо, а также создают ненужную эмоциональную привязку «я ж пообещал к среде..») а сравнивали стори с неким эталоном.
А соотношение сколько «строипойнтов в спринт» — вычисляется эмпирически и позволяет посчитать некую вилку между предполагаемым минимальным количеством сторипойнтов и максимальным.
Краткое содержание: В долгосрочной перспективе trade off между качеством кода и рабочим продуктом невозможен. Этот как взять кредит — можно заплатить немного сейчас, или заплатить много позже.
Архитектура в софте — это то, что сложно или дорого изменить, а потому (в проекте нацеленном на долгосрочную перспективу) лучше таки отсрочить релиз. ИМО, подтвержденное мучительной болью долгосрочных проектов.
Не заострять внимание на качестве кода и дизайна — это пилить сук, на котором сидишь.
Хороший код, архитектура и дизайн нужны как раз для того, чтоб в будущем изменения было легко вносить, и темп "спринт — 2 недели" можно было поддерживать бесконечно долго.
Весь смысл в том, что проект — чаще всего не спринт, а марафон.
А мне интересно, насколько реалистичны (и, соответственно, нужны в природе) «планы на ближайшие 100 дней»? Есть хоть один человек, который с уверенностью скажет, что сколь угодно подробное планирование «на N дней» вместо «роадмапа» на «квартал» там, «год» не было пустой тратой времени?
Абсолютно согласен, это по сути — моя гипотеза, но иными словами. Ваша формулировка даже более удачная!
Это отличная цитата из статьи, но не противоречит ли Ваше высказывание Вашей же статье?
Даже если мы признаем утверждение
истинным (оно, как минимум, правдоподобно), это, тем не менее, не исключает возможности влияния тестов на качество продукта.
Более того, пропоненты TDD, как раз считают, что смысл TDD не в тестах, а в понимании и точности модели.
Ваш ход?
При TDD тесты являются формальным описанием (микро)задачи. Таким образом, как только тест становится «passed» мы можем сделать вывод, что (микро) задача выполнена.
Также, при таком подходе исчезает соблазн «подгонять» тесты под код (а то будет как в лабораторных по теории цепей в старом, добром университете — "пофиг что намеряли, пиши что соответствует заданию, а то все поймут что мы цепь хреново сделали")
Ну, по крайней мере, такая изначальная гипотеза
Это отдельная грань проблемы, которую нужно исследовать.
В классическом TDD тест — это Unit-test, а тестируемый объект это метод, или даже отдельная ветка исполнения в методе. Готов поспорить, что на этом уровне в любом приложении будут детерминированные результаты.
Не совсем, скорее о том, что у нас нет (пока?) убедительных доказательств любого из утверждений:
1) TDD эффективен
2) TDD не эффективен
3) TDD не оказывает влияния на эффективность
И, соответственно, нужны еще исследования.
Но, насколько я пониманию
никак не противоречит применимости TDD, т.к. изменение самих тестов является одним из возможных шагов в «цикле» TDD. С учетом того, что фокус Unit Test это метод или даже определенная ветка в методе, наличие Т.З. не должно оказывать существенного влияния.
Нужно ли лучше формализовать понятие TDD?
Можете пояснить чуть более подробно?
У вас есть какие-нибудь научные обоснования, или это основано на Вашем опыте?
В любом случае — гипотеза принята к рассмотрению, спасибо.
Суть не в том, чтоб начать оценивать стори в сторипойнтах вместо часов, а в том, что б при оценке стори мы отталкивались от некого бейзлайна.
Пример: вот была у нас стори, мы решили что она 1, а эта вот выглядит побольше, но меньше той, что была 3, значит оцениваемая сторя где-то 2
Т.е. чтоб мы перестали оценивать в часах (потому что такие оценки все равно неправда, и пальцем в небо, а также создают ненужную эмоциональную привязку «я ж пообещал к среде..») а сравнивали стори с неким эталоном.
А соотношение сколько «строипойнтов в спринт» — вычисляется эмпирически и позволяет посчитать некую вилку между предполагаемым минимальным количеством сторипойнтов и максимальным.
Вот тут можно почитать подробнее medium.com/@mdalmijn/12-common-mistakes-made-when-using-story-points-f0bb9212d2f7
Краткое содержание: В долгосрочной перспективе trade off между качеством кода и рабочим продуктом невозможен. Этот как взять кредит — можно заплатить немного сейчас, или заплатить много позже.
Архитектура в софте — это то, что сложно или дорого изменить, а потому (в проекте нацеленном на долгосрочную перспективу) лучше таки отсрочить релиз. ИМО, подтвержденное мучительной болью долгосрочных проектов.
Не заострять внимание на качестве кода и дизайна — это пилить сук, на котором сидишь.
Хороший код, архитектура и дизайн нужны как раз для того, чтоб в будущем изменения было легко вносить, и темп "спринт — 2 недели" можно было поддерживать бесконечно долго.
Весь смысл в том, что проект — чаще всего не спринт, а марафон.
А так да, есть много полезной информации.
Это мой эмпирический опыт. Но, думаю, just for fun, было бы классно посчитать статистику.
Может быть, поделитесь Вашим опытом, где эджайл не работал, и почему так (с Вашей точки зрения) вышло?