"Test Driven Development" Рефакторинг сложности проектирования

Question

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

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

Спасибо ..

Answer 1

Для базового определения TDD вы пишете провальный тест, пишете минимальный объем кода, который сделает тест успешным, рефакторинг, повтор. Там не так много места для отсрочки рефакторинга. ;)

Я думаю, что это так по многим причинам, главным образом, чтобы люди, подобные моему боссу, не были правы, полагая, что слово «рефакторинг» - это выговорное кодовое слово для переписывания. Насколько проще написать один метод, который, скажем, захватывает некоторую информацию из Интернета. Вы пишете свой тест, заставляете его пройти, затем говорите: «Хорошо, теперь возьмите этот жестко закодированный URL и переместите его в начало класса или файла свойств». Насколько сложнее это сделать после того, как вы закончили свой урок и взвесили несколько сотен или более строк кода.

Там, где появляется проектная часть, это меньше в большом «D» esign, по крайней мере, в моем понимании и использовании TDD, а скорее в передовой практике, которую он поощряет и / или требует. Возвращаясь к моему сценарию использования, хорошо, у меня написан метод для сбора моих данных, теперь мне нужно что-то с ним сделать, могу ли я вернуться и начать добавлять код в мой метод getData? Нет, конечно нет, это "сделано". Я продолжаю и пишу новый метод или три, чтобы сделать что-то с данными. Все методы коротки, по заданию, тестируемы, короче говоря, гораздо лучший дизайн для кода.

Я думаю, что именно здесь возникает путаница. TDD производит лучше разработанный CODE, который, вероятно, будет производить лучшее программное обеспечение, но если общий дизайн SYSTEM не годится, то лучшие методы кодирования во вселенной не собираются создавать хороший продукт / система.

YMMV конечно.

Answer 2

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

Таким образом, изменения основываются на изменениях в ограничениях и требованиях,не из-за технического долга, который смягчается на самых внутренних интерфейсах.Масштаб изменений будет определять степень рефакторинга - если это правда, «основные» рефакторинги ожидаются только при изменении самых верхних интерфейсов.

Вы упомянули запланированные рефакторинги как шаг в долгосрочном развитиицикл.Я думаю, что это хрупкая стратегия, не потому что мы не должны очищать технический долг - мы должны сделать это как можно скорее, и это основа практики TDD, - а потому что это рискованно ,Чтобы проиллюстрировать: как спланировать свой этап рефакторинга, как бы вы оценили размер технического долга?Что, если предполагаемое время рефакторинга недостаточно?Будет ли система здоровой, если вы прекратите рефакторинг, чтобы сделать другие важные вещи?Это важные вопросы, и не единственные, касающиеся технического управления долгом.С точки зрения управления рисками TDD означает лучший контроль.

Answer 3

Я обнаружил, что короткие итерации в сочетании с TDD / непрерывной интеграцией работают лучше всего.

Длинные итерации имеют недостатки:

1) Вы теряете счет того, над чем работаете 2) Трудно оценить, что вы можете сделать за 2 месяца, скажем, за 1 неделю 3) Это дает владельцам бизнеса меньше времени для переориентации задач разработки.

Короткие циклы проще: «Я должен сделать a и b на этой неделе». Вы остаетесь сосредоточенным. У вас короткие встречи. Ваше TDD и постоянная интеграция держат вас в курсе состояния вашего кода.

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

edit - еще один недостаток более продолжительных циклов разработки заключается в том, что люди становятся самодовольными: «э, у меня есть еще 4 недели, я все это сделаю позже ...»