Wikipedia говорит, что Bug Driven Development (BDD) - это антипаттерн. Raja Shankar Kolluru отлично объясняет, почему. Однако Florian Rappl аргументирует, что это не так. Ben Winding считает, что это лучше, чем TDD. Простыми словами, BDD - это как пытаться строить самолет во время полета, опираясь на жалобы пассажиров. Никто не строит самолеты таким образом (ну, может быть Boeing и Airbus). Однако команда разработчиков, которая практикует BDD, может продемонстрировать более высокую производительность.
Команда разработчиков использует BDD, если придерживается одного простого принципа: каждая задача формулируется как жалоба.
Это началось в 2002 году, в Mozilla:
Если вы слушаете советы Mozilla, у вас не будет запросов на функции, вопросов или задач в вашей системе отслеживания проблем. Только отчеты об ошибках. Они могут звучать как “Крыло горит!” - идеальная жалоба - или “В самолете нет джакузи!” - идеальный запрос на функцию в форме жалобы. Вопросы также могут выглядеть как жалобы: “Неясно, как пристегнуть ремень.” Будь то от тестировщиков или клиентов, формат один и тот же: “Мне это не нравится.”
Основное преимущество, которое BDD может принести проекту, - это уменьшение шума. Я могу предложить две причины для этого:
- Точно так же программистам нужно убедить жалующегося, что проблема решена. Они не могут закрыть заявку только текстовым ответом. Они должны продемонстрировать достаточно значительный вклад в кодовую базу. Никакого шума.
Хорошая жалоба выявляет недостаток в чем-то материальном. Хорошее разрешение хорошей жалобы - это патч для этого материального объекта. Очевидно, что в программном проекте исходный код является материальным объектом.
В дисциплинированной команде каждый тикет - это отчет об ошибке, который адресует недостаток в исходном коде. Каждый отчет об ошибке приводит к патчу - вкладу в исходный код. Нет лишнего шума. Команда сосредоточена и демонстрирует максимальную продуктивность.
BDD также имеет серьезный недостаток. Может быть сложно обучить команду его использованию. Принятие BDD может потребовать изменения их мировоззрения. Они должны переключиться от производителей шума к обнаружителям недостатков.
Джефф Этвуд, в своем блоге о разработке, основанной на жалобах, объясняет это с бизнес-точки зрения. Он предлагает, вместо того чтобы реализовывать то, во что вы верите, лучше дать своим клиентам черновой вариант и позволить им жаловаться. Вы чаще всего ошибаетесь в том, на что они действительно будут жаловаться. Чем больше они жалуются, тем лучше вы слушаете, тем больше ценности вы предоставляете.
Translated by ChatGPT gpt-3.5-turbo/42 on 2025-05-25 at 13:28
