Методология Agile-разработки предлагает множество отличных
эффективных идей и практик:
- разбиение проектов на небольшие релизы (Small Releases) для управления рисками и обеспечения быстрой обратной связи;
- таймбоксинг для ограничения WIP (одновременно выполняемых работ);
- работающее ПО как критерий успеха;
- простая оценка и скорость (velocity) для определения производительности команды;
- сотрудничество с клиентами;
- постоянная интеграция - и постоянные релизы - для обеспечения стабильной работы кода.
Но существуют другие - менее важные - методы: если им не
следовать, с вами и вашим проектом не произойдет ничего плохого. А есть такие,
о которых лучше забыть.
Разработка через тестирование (TDD)
Команды, пытающиеся ускорить процесс работы, должны
располагать эффективной системой тестирования. Test First Development
(разработка по принципу "сначала тест") и разработка через
тестирование делают акцент на написание тестов - в конце концов, прежде чем
написать код, пишется заведомо неуспешный тест.
Вы получаете набор работающих автоматизированных тестов,
чтобы обеспечить высокий уровень покрытия кода и регрессионной защиты.
TDD не только гарантирует тестирование кода. Ее позиционируют как метод проектирования,
который позволяет добиться улучшения качества кода и простого дизайна.
Исследования команд в Microsoft и IBM (которые использовали TDD для повышения качества)
показали, что хотя TDD увеличивала предварительные затраты на разработку на
15-35% (TDD требует изменений в способах работы и мышления, что тормозит - по
крайней мере, сначала - процесс разработки), в то же время позволяла снизить
плотность ошибок на 40% (IBM) или даже на 60-90% (Microsoft) по сравнению с
командами, которые не проводили систематического модульного тестирования.
Однако, в 12-м разделе книги "Идеальная разработка
ПО" ("Making Software") -
"Насколько эффективной является разработка через тестирование" -
исследователи во главе с Бураком Турханом
пришли к выводу, что TDD улучшает внешнее качество (о чем свидетельствуют
пройденные тестовые сценарии, количество дефектов, плотность ошибок, количество
ошибок за один тест, меры, необходимые для исправления ошибок, плотность
изменений и % превентивных изменений) и качество тестов (меньше ошибок в
тестах; тесты проще сопровождать), но не приводит к стабильному улучшению
качества проектирования.
TDD уменьшает сложность кода и упрощает его повторное
использование, а с другой стороны - негативно отображается на связности и
связанности.
Даже если вы не ярый поборник методики TDD, следует помнить,
что в некоторых случаях принято в первую очередь писать работающий тест.
Например, если вам нужно решить конкретную проблему конкретным способом или вы
исправляете ошибку, когда заведомо неуспешный тестовый сценарий уже создан.
Главное то, что вы пишите много тестов, обновляете их и регулярно прогоняете.
Время написания отходит на второй план.
Комментариев нет:
Отправить комментарий