Comments 9
TDD в целом хорошо, но дорого и геморно.
Во-первых. в любых тестах надо следить за консистеностью тестовых данных - что боль для разработчика, ибо работа превращается в бесконечное нудное выверение экселек (json, xml, ... - на выбор). Поменял логику на одно ветвление - побежал три дня править бесконечные простыни датасетов, после чего хочется убивать.
Во-вторых, нужны детально прописаные требования, причем финализированные - иначе адище вам гарантирован. Где мы в последний раз видели красивые точные финальные требования? Вот-вот, редкий зверь. В среднем же, пока ты пишешь тесты, требования немного меняют, и начинай сначала... В итоге разработка хелловорлда затягивается на годы.
Да ничего подобного. Опять стандартный набор отговорок тех, кто не умеет или не хочет в тесты. При выборе методики TDD вы должны продумывать архитектуру. Если невозможно написать тест, значит есть изъян в архитектуре. А по поводу данных - это все спокойно решается моками в соответствии с контрактом
нужны детально прописаные требования, причем финализированные - иначе адище вам гарантирован
А если TDD не использовать, то без ясных требований прямая дорога в рай? ;D
Ясные требования нужны в любом случае. И TDD заставит их прояснить. Без TDD — да, можно какое-то время изображать деятельность.
К тому же, TDD даст возможность прояснять требования постепенно, двигаясь маленькими быстрыми шагами — это позволяет часто выдавать новые версии, использовать их на практике и получать быструю обратную связь: правильно поняли очередной "кусок" или нет. На вопрос, как без TDD кто-то умудряется организовать "agile-" разработку, я ни разу не получил вменяемого ответа. Впрочем, я и вменяемого agile-процесса на практкие, к сожалению, до сих пор не видел, одни scrum-ные потёмкинские деревни.
А про бесплатную(!) страховочную сеть в виде тестов, которая позволяет спокойно вносить любые изменения в существующую систему, пишут даже те, кто TDD не понимает.
Canon TDD
Долго думал, при чём здесь фирма Canon.
+100500
@kmoseenk , в чём была сложность с переводом слова "каноничный"? ;)
Перевод:
Первый момент недопонимания заключается в том, что люди, похоже, объединяют всю архитектуру вместе.
Оригинал:
The first misunderstanding is that folks seem to lump all design together.
Design — это не архитектура! Design — это дизайн! Можно перевести как "замысел", "конструкция". Даже "проект" уже не надо — будет путать читателя. Но переводя как "архитектура", вы радикально меняете смысл, так как термин "архитектура" всегда нес иную смысловую нагрузку, а сейчас, когда под "архитектурой" стало модно понимать вообще нечто чуть ли не ортогональное основной функциональности программной системы, и подавно.
Да, под дизайном в России чаще понимают всякие там "украшательства". Но даже "заимствовать" (хотя это никакое не заимствование) слово из совершенно другой области человеческой деятельности будет гораздо лучше, чем нагрузить другим смыслом уже занятый термин из той же области. То, что под словом "дизайн" в этой статье понимается совсем не цвет кнопочек и размер шрифта, будет очевидно из контекста. А вот то, что речь идёт про дизайн (конструкцию) программной системы, а не про её архитектуру — поди ещё догагдайся.
Не знаю, откуда пошла традиция переводить "design" как "архитектура" — от DDD Evans-а в редакции Бродового, или ещё раньше, но с этим надо как-то заканчивать.
Переводчики несут львиную долю ответственности за непонимание и неверную трактовку русскоязычным IT-сообществом многих понятий. Взять то же TDD — это не "Разработка через тестирование"! Тестирование — абсолютно отдельный вид деятельности, принципиально отличающий от разработки. Там просто напросто цели другие. Написание автоматического теста — ещё не тестирование. Зато у нас с момент выхода перевода TDD by Example эта методология трактуется как способ покрыть код тестами. И уже скоро 20 лет как это перебороть никто не может.
Каноничный TDD