Разработка, основанная на поведении: подробное руководство

29 июля 2021 г.

Коммуникация важна при разработке программного обеспечения в команде. Разработка, основанная на поведении (BDD), позволяет всем участникам понять, что делает программный проект, независимо от их технического опыта. Изучение основ разработки, основанной на поведении, может помочь вам определить, может ли этот метод помочь в производстве вашего проекта. В этой статье мы объясним, как использовать разработку, основанную на поведении, в ваших проектах, а также преимущества и недостатки этого метода.

Что такое развитие, основанное на поведении?

Разработка, основанная на поведении, — это метод разработки программного обеспечения, который включает перевод программного кода на доступный язык. Это позволяет клиентам определять поведенческие цели программы в формате, понятном всем, включая разработчиков. BDD призывает всех участников проекта сосредоточиться на том, что они хотят, чтобы программа делала, а не на деталях кода. Каждый участник, который хочет определить цель для программного обеспечения, определяет поведение, когда поведение происходит и какие результаты вызывает поведение на предметно-специфическом языке (DSL). DSL — это язык программирования, ориентированный на конкретное поведение программного обеспечения.

BDD также использует элементы разработки через тестирование (TDD) — метода тестирования кода, который повторяет анализ до тех пор, пока код проекта не станет максимально минимальным и точным. Используя элементы кода TDD, BDD помогает поощрять общение и минимальное программирование на протяжении всего проекта.

Как использовать разработку, основанную на поведении

Если вы планируете использовать разработку, основанную на поведении, для своего проекта, изучите некоторые из следующих шагов:

1. Обсудить программное обеспечение

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

Дано [List the basic requirements to start the coding behavior]

А также [List any additional requirements to start the coding behavior]

Когда [List what parameters cause the coding behavior]

потом [List what the coding behavior causes]

Примером запроса клиента может быть:

Учитывая, что пользователь находится на домашней странице.

И пользователь переходит на страницу входа.

Когда пользователь вводит информацию: имя пользователя, пароль

Затем пользователь находится на странице профиля

2. Ставьте цели на основе поведенческих ожиданий

Собрав все запросы клиентов, создайте цели на основе запросов. Ваша команда может корректировать запросы на ограничения кодирования или дорабатывать идеи до начала кодирования. Прежде чем завершить встречу, постарайтесь задокументировать как можно больше запросов. Документирование идей может помочь при общении за пределами собрания. Клиенты могут связаться с программистами, чтобы внести коррективы, уточнить идеи или удалить поведение из списка кодирования.

3. Преобразуйте цели в DSL

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

4. Тестируйте и документируйте поведение

После того, как разработчики закодируют все поведения в DSL, начните документировать коды DSL с поведением программы. Если к проекту присоединяются новые участники, документация по DSL может помочь им понять статус и поведение проекта. После программирования и документирования всего поведения кода DSL команда программистов теперь может создавать пользовательские истории. Шаблон пользовательской истории выглядит следующим образом:

История: [A one-line summary of the entire code behavior]

Повествование:

Так как [The user’s name]

я бы хотел [The code behavior result]

Так, чтобы я смог [Summary of the code behavior’s purpose]

Критерии приемки (представлены в виде сценариев):

Сценарий: [List the basic requirements to start the coding behavior]

Учитывая, что [List any additional requirements to start the coding behavior]

Когда [List what parameters cause the coding behavior]

Затем [List what the coding behavior causes]

И [List what else the coding behavior causes]

Ниже приведен пример пользовательской истории:

История: Владелец аккаунта входит в аккаунт

Как владелец аккаунта

Я хочу войти в свой аккаунт

Чтобы я мог получить доступ к своей информации

Сценарий: учетная запись разблокирована

Учитывая, что пользователь не ввел три неудачных попытки ввода пароля

Когда владелец учетной записи вводит правильное имя пользователя и пароль

Затем владелец учетной записи входит в свою учетную запись

И владелец аккаунта перенаправляется на страницу своего профиля.

Преимущества развития, ориентированного на поведение

Некоторые преимущества разработки, основанной на поведении, включают:

Улучшает общение

Разработка, основанная на поведении, поощряет обратную связь от каждого участника проекта. Благодаря доступности BDD целые команды, отделы или компании могут сообщать о новых идеях и функциях проектов. Команды без разработчиков программного обеспечения могут создавать программы, устранять неполадки и предлагать новые решения, помогающие сэкономить время и улучшить программное обеспечение. Поскольку BDD использует доступный язык, заинтересованные стороны могут легко понять, что делает текущий продукт, и уточнить, как они хотят его улучшить.

Уменьшает ошибку кода

Поскольку BDD использует TDD на каждом этапе разработки, ошибки кода в конечном проекте встречаются редко. TDD постоянно отслеживает и тестирует кодовую базу, даже когда никто из членов команды не корректирует код. Когда программисты пишут новый код или изменяют уже существующий код, TDD снижает вероятность ошибки кода в конечном продукте.

Поощряет минимальное кодирование

TDD поощряет минимальное кодирование во время своих процессов. Когда участник проекта пишет новую строку кода, TDD проверяет код как на наличие ошибок, так и на минимальное кодирование. Некоторые программы TDD автоматически изменяют строки кода. Даже если члены команды не работают над кодом проекта, TDD постоянно сокращает его, чтобы уменьшить плотность программирования.

Недостатки поведенческого развития

Некоторые потенциальные недостатки разработки, основанной на поведении, включают:

Требуется кодирование DSL

Доступное языковое кодирование BDD требует шага программирования DSL. После подтверждения запросов клиентов программисты в команде создают код DSL для каждой команды, которую использует BDD. Кроме того, программисты также документируют программирование DSL и его определения для всестороннего понимания команды. Для больших команд документация и программирование могут не мешать работе. Для небольших команд эти два дополнительных процесса могут оказаться сложной задачей. Однако некоторые компании могут извлечь выгоду из повышенной доступности, обеспечиваемой дополнительной документацией.

Полагается на отзывы клиентов

Программирование BDD требует отзывов клиентов для разработки рабочего продукта. Поскольку команды развивают поведение BDD во время встреч и общения, любое дальнейшее программирование после первой встречи требует дополнительного обсуждения. Команды, использующие BDD, часто сообщают о новых функциях, расширениях и решениях, касающихся продукта. Поскольку BDD требует кодирования DSL для каждого нового действия, производство может замедлиться, если специалисты по программированию недоступны. Однако такая частая коммуникация между заказчиками и разработчиками может обеспечить согласованность идей и целей и помочь избежать дорогостоящих изменений на этапе постпроизводства.

Использует постоянное тестирование

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