|
Почему TDD работает?
Приготовьтесь покинуть галактику. Пред положите на секунд у, что
TDD
помогает
команд ам
разработчиков
созд авать
хорошо
спроектированные, уд обные в сопровожд ении системы с чрезвычайно
низким уровнем д ефектов. (Я не утвержд аю, что это происход ит на
кажд ом шагу, я про сто хочу, чтобы вы немножко помечтали.) Как такое
может происход ить?
Отчасти этот эффект связан с уменьшением количества д ефектов.
Чем раньше вы найд ете и устраните д ефект, тем д ешевле это вам
обойд ется. Иногд а разница в затратах огромна (спро сите у «Марс-
ленд ера»
[30]
). Снижение количества д ефектов вызывает множество
вторичных психологических и социальных эффектов. По сле того как я
начал работать в стиле TDD, программирование стало д ля меня
значительно менее нервным занятием. Когд а я работаю в стиле TDD, мне
не над о беспокоиться о множестве вещей. Вначале я могу заставить
работать только од ин тест, потом – все о стальные. Уровень стресса
существенно снизился. Взаимоотношения с партнерами по команд е
стали более позитивными. Разработанный мною код перестал быть
причиной сбоев, люд и стали в большей степени рассчитывать на него. У
заказчиков тоже повысило сь настроение. Теперь выпуск очеред ной
версии системы означает новую функционально сть, а не набор новых
д ефектов, которые д обавляются к уже существующим.
Уменьшение количества д ефектов. Имею ли я право утвержд ать,
что под обное возможно? Есть ли у меня научное д оказательство?
Нет. На текущий момент не провод ило сь никаких исслед ований,
под твержд ающих преимущества TDD по сравнению с альтернативными
под ход ами в смысле качества, эффективно сти или уд овольствия.
Од нако
эпизод ические
под твержд ения
преимуществ
TDD
многочисленны, а вторичные эффекты очевид ны. При использовании
TDD у программистов д ействительно снижается стресс, в команд ах
д ействительно повышается д оверие, а заказчики д ействительно
начинают смотреть на кажд ую новую версию прод укта с энтузиазмом.
Лично мне не приход ило сь сталкиваться с обратными эффектами.
Од нако ваши наблюд ения могут оказаться иными, вы д олжны
попробовать д ля того, чтобы оценить TDD само стоятельно.
Еще од ним преимуществом метод ики TDD, объясняющим ее
положительные эффекты, является сокращение времени, которое
проход ит межд у принятием проектного решения и проверкой результата
его реализации. В рамках TDD это д о статочно короткий промежуток
времени – несколько секунд или минут. Вы принимаете решение,
реализуете его в код е, запускаете тесты и анализируете полученный
результат. В начале у вас возникает мысль – возможно, API д олжен
выгляд еть так, или, возможно, метафора д олжна быть такой, – затем вы
созд аете самый первый пример – тест, который воплощает вашу мысль в
реально сть. Вместо того чтобы сначала проектировать, а затем в
течение нескольких нед ель или месяцев ожид ать, окажется ваше
решение правильным или нет, вы получаете результат уже через
несколько секунд или минут.
Причуд ливый ответ на вопро с, «Почему TDD работает?», о снован
на бред овом вид ении из области комплексных систем. Непод ражаемый
Флип пишет:
Следует
использовать
программистские
практики,
которые
«притягивают» корректный код как предельную функцию, но не как
абсолютную
величину.
Если
вы
пишете
тесты
для
каждой
присутствующей в системе функциональности, если вы добавляете в
систему новые функции по одной, и только после того, как выполнятся все
тесты, вы создадите то, что математики обозначают термином «точка
притяжения (аттрактор)». Точка притяжения – это точка в
пространстве состояний, к которой сходятся все потоки. Со временем
код с большей вероятностью изменяется в лучшую сторону, а не в
худшую; точка притяжения приближается к корректности, как
предельная функция
.
Это «корректность», которая устраивает всех программистов (за
исключением, конечно же, тех, кто работает над медицинским или
аэрокосмическим программным обеспечением). Я считаю, что важно
быть знакомым с концепцией точки притяжения – ее не следует
отвергать, ею не следует пренебрегать
.
Do'stlaringiz bilan baham: |
