En el desarrollo de software es fundamental comunicarse de forma eficaz cuando se trabaja en equipo. El desarrollo basado en el comportamiento (BDD) permite que todos los miembros comprendan lo que hace un programa, tengan o no conocimientos técnicos. Si está interesado en utilizar el desarrollo basado en el comportamiento para producir su proyecto, puede aprender los fundamentos y averiguar si es adecuado para usted.
En este artículo, explicamos cómo utilizar el desarrollo basado en el comportamiento en tus proyectos y las ventajas y desventajas de este método.
¿Qué es el desarrollo basado en el comportamiento?
El desarrollo conductual es un método de desarrollo de software que traduce el código a un lenguaje accesible. Los clientes pueden describir los objetivos de comportamiento del programa en un lenguaje que todos entiendan, incluidos los programadores. El BDD se centra en lo que hace el software más que en los detalles del código, y anima a todos los miembros del proyecto a hacer lo mismo. Se utiliza un DSL, o lenguaje específico del dominio, para describir el comportamiento, las consecuencias y el momento de su ocurrencia para cada objetivo que un miembro del proyecto quiera alcanzar. El DSL es un lenguaje de programación que describe el comportamiento del software.
BDD también utiliza elementos de desarrollo dirigido por pruebas (TDD), un método de prueba de código que repite el análisis hasta que el código del proyecto' s es tan mínimo y preciso como sea posible. Al utilizar elementos de código TDD, BDD ayuda a fomentar la comunicación y la programación mínima en todo el proyecto.
Relacionado: Pruebas Cucumber: Qué es y cómo usarlo
Cómo utilizar el desarrollo basado en el comportamiento
Si usted' está considerando utilizar el desarrollo basado en el comportamiento para su proyecto, explore algunos de los siguientes pasos:
1. Discutir el software
Comience por discutir el software con todo su equipo. Aprenda lo que el cliente quiere que el software logre, incluyendo los parámetros que causan el comportamiento de codificación y lo que el comportamiento de codificación hace. Para agilizar el proceso de discusión, considere la posibilidad de utilizar el formato de la plantilla que aparece a continuación:
Dado [Enumera los requisitos básicos para iniciar la conducta de codificación]
Y [Enumera cualquier requisito adicional para iniciar el comportamiento de codificación]
Cuando [Enumere qué parámetros causan el comportamiento de codificación]
Luego [Enumere las causas del comportamiento de codificación].
Un ejemplo de solicitud de un cliente' podría ser:
Dado que el usuario está en la página de inicio.
Y el usuario navega a la página de inicio de sesión.
Cuando el usuario introduce información: nombre de usuario, contraseña
Entonces el usuario está en la página de perfil
Relacionado: Relacionado: 50 tipos de lenguajes de programación y su función
2. Crear objetivos basados en las expectativas de comportamiento
Después de reunir todas las solicitudes del cliente, cree objetivos basados en las solicitudes. Su equipo puede ajustar las peticiones en función de las limitaciones de codificación o finalizar las ideas antes de empezar a codificar. Antes de concluir la reunión, intente documentar el mayor número posible de peticiones. Documentar las ideas puede ayudar a la hora de comunicarse fuera de una reunión. Los clientes pueden ponerse en contacto con los programadores para realizar ajustes, perfeccionar ideas o eliminar comportamientos de la lista de codificación.
3. Traducir los objetivos en DSL
Después de la primera reunión de discusión, los desarrolladores del programa pueden empezar a codificar las peticiones de comportamiento en DSL. Anime a los miembros del equipo a comunicar las actualizaciones del proceso de codificación, los ajustes de comportamiento y cualquier nuevo comportamiento solicitado. Considere la posibilidad de celebrar reuniones adicionales para revisar los resultados del código DSL, probar el producto en funcionamiento y responder a las preguntas entre los miembros del equipo.
4. Probar y documentar comportamientos
Después de que los desarrolladores codifiquen todos los comportamientos en DSL, empiecen a documentar los códigos DSL con los comportamientos del programa. Si los nuevos miembros se unen al proyecto, la documentación de DSL puede ayudarles a entender el estado y los comportamientos del proyecto. Después de programar y documentar todos los comportamientos del código DSL, el equipo de programación puede ahora crear historias de usuario. Una plantilla de una historia de usuario es la siguiente:
Historia: [Un resumen de una línea de todo el comportamiento del código]
Narrativa:
Como [El usuario's nombre]
Quiero [El resultado del comportamiento del código]
Para que pueda [Resumen del comportamiento del código's propósito]
Criterios de aceptación (presentados como escenarios):
Escenario: [Enumera los requisitos básicos para iniciar la conducta de codificación]
Dado que [Enumera cualquier requisito adicional para iniciar la conducta de codificación]
Cuando el [Enumere qué parámetros causan el comportamiento de la codificación]
Luego el [Enumere lo que causa el comportamiento de codificación]
Y el [Enumera qué más provoca el comportamiento de la codificación]
A continuación se muestra un ejemplo de historia de usuario:
Historia: El titular de la cuenta se da de alta
Como titular de una cuenta
Quiero entrar en mi cuenta
Para poder acceder a mi información
Escenario: La cuenta se desbloquea
Dado que el usuario no ha introducido tres intentos fallidos de contraseña
Cuando el propietario de la cuenta introduce el nombre de usuario y la contraseña correctos
A continuación, el propietario de la cuenta se registra en su cuenta
Y el propietario de la cuenta es redirigido a su página de perfil
Ventajas del desarrollo basado en el comportamiento
Algunas de las ventajas del desarrollo basado en el comportamiento son
Mejora la comunicación
El desarrollo orientado al comportamiento fomenta la retroalimentación de todos los miembros del proyecto. Gracias a la accesibilidad de BDD', equipos, departamentos o empresas enteras pueden comunicar nuevas ideas y características del proyecto. Los equipos sin desarrolladores de software pueden crear programación, resolver problemas y proponer nuevas soluciones para ayudar a ahorrar tiempo y mejorar el software. Como BDD utiliza un lenguaje accesible, las partes interesadas pueden entender fácilmente lo que hace el producto actual y elaborar cómo quieren que mejore.
Relacionado: Aprende a codificar en 7 pasos
Reduce los errores de código
Como BDD utiliza TDD en todas las fases del desarrollo, rara vez existen errores de código en el proyecto final. TDD supervisa y prueba constantemente la base de código, incluso cuando ningún miembro del equipo está ajustando el código. Cuando los programadores escriben código nuevo o cambian el código preexistente, TDD reduce la probabilidad de que el código falle en el producto final.
Fomenta la codificación mínima
TDD fomenta la codificación mínima durante sus procesos. Cuando un miembro del proyecto escribe una nueva línea de código, TDD comprueba el código en busca de errores y de una codificación mínima. Algunos programas de TDD cambian automáticamente las líneas de código. Incluso si los miembros del equipo no están trabajando en el código del proyecto, TDD lo abrevia constantemente para ayudar a reducir la densidad de programación.
Desventajas del desarrollo basado en el comportamiento
Algunas desventajas potenciales del desarrollo basado en el comportamiento incluyen:
Requiere la codificación DSL
La codificación del lenguaje accesible de BDD' requiere un paso de programación DSL. Tras conocer las peticiones de los clientes, los programadores de software del equipo crean el código DSL para cada comando que utiliza BDD. Además, los programadores también documentan la programación DSL y sus definiciones para que el equipo la comprenda en su totalidad. Para los equipos grandes, la documentación y la programación pueden no obstaculizar la producción. Los equipos más pequeños pueden encontrar estos dos procesos adicionales como un reto a mantener. Sin embargo, algunas empresas pueden beneficiarse de la mayor accesibilidad que proporciona la documentación adicional.
Relacionado: Aprender a ser programador informático
Se basa en los comentarios de los clientes
La programación BDD requiere la retroalimentación del cliente para desarrollar un producto que funcione. Dado que los equipos desarrollan comportamientos BDD durante las reuniones y la comunicación, cualquier programación posterior a la reunión inicial requiere un debate adicional. Los equipos que utilizan BDD se comunican con frecuencia sobre nuevas características, ampliaciones y decisiones relativas al producto. Dado que BDD requiere codificación DSL para cada nueva acción, la producción puede ralentizarse si los expertos en programación no están disponibles. Sin embargo, esta comunicación frecuente entre clientes y desarrolladores puede garantizar la coherencia de las ideas y los objetivos y ayudar a evitar costosos cambios posteriores a la producción.
Utiliza pruebas constantes
Aunque las pruebas TDD ayudan a evitar errores en el producto final, también pueden ralentizar la producción. A diferencia de otros métodos de codificación, TDD no permite a los programadores escribir código ineficiente. Los estándares del proyecto pueden exigir inicialmente requisitos de TDD, pero si los estándares del proyecto de un equipo cambian, TDD no lo hace. Sin embargo, aunque puede ralentizar el proyecto, las empresas pueden beneficiarse de sus procesos de reducción de errores.