Al revisar los artículos sobre diseño de software, me encontré constantemente con una nube de abreviaturas sin precedentes y prácticas de desarrollo mencionadas casualmente.

• TDD : bueno, todos lo saben, primero escribimos pruebas y luego el resto del código.
• BDD es algo familiar, algo así como pruebas también, pero especiales.
• TDD - ¿Otra vez? Entonces, detente, aquí no se trata de pruebas en absoluto. ¿Pero por qué se llama igual?
• DDD : contextos vinculados, lenguaje ubicuo, dominio ...
• Fdd
• MDD : ¿en serio, basado en gráficos?
• PDD - ...

Los enfoques de desarrollo se dividen por complejidad, áreas de aplicación y objetivos.
Creo que ha llegado el momento de descubrir por qué son necesarios, por qué hay tantos y cómo pueden sernos útiles.

Comenzaremos a familiarizarnos con ellos desde los más simples hasta los más complejos, considere ejemplos de uso y las ventajas y desventajas de cada uno de ellos.

TDD - Desarrollo guiado por pruebas

TDD es una metodología de desarrollo de software que se basa en repetir ciclos cortos de desarrollo: inicialmente se escribe una prueba que cubre el cambio deseado, luego se escribe el código del programa que implementa el comportamiento deseado del sistema y le permite pasar la prueba escrita. Luego, el código escrito se refactoriza con pruebas constantes de las pruebas.

Suena simple y claro. Muchos están familiarizados con este enfoque del desarrollo, e incluso el propio tío Bob lo está promoviendo activamente.

TDD se considera una forma de construcción de aplicación adecuada. La filosofía de desarrollo basada en pruebas es que sus pruebas son una especificación de cómo debe comportarse su programa. Si considera que su conjunto de pruebas es una parte obligatoria del proceso de compilación, si sus pruebas fallan, el programa no se compila porque es incorrecto. Por supuesto, la limitación es que la exactitud de su programa solo se define como la integridad de sus pruebas. Sin embargo, los estudios han demostrado que el desarrollo basado en pruebas puede reducir los errores en un 40-80% en la producción.

Cuando comience a usar TDD, puede sentir que está corriendo más lento de lo normal. Esto se debe a que trabajará fuera de la "zona de confort", y esto es bastante normal.

Una vez que siente que escribir pruebas se ha convertido en una parte simple y natural del flujo de trabajo, que ya no necesita pensar en usar TDD cuando trabaja en un proyecto, se da cuenta de que TDD ha entrado en su trabajo.

Esta metodología nos permite lograr la creación de una aplicación adecuada para las pruebas automáticas y una muy buena cobertura del código con las pruebas, ya que TK se traduce al lenguaje de las pruebas automáticas, es decir, se comprueba todo lo que el programa debe hacer. TDD a menudo también simplifica la implementación de software: se elimina la redundancia de implementación; si un componente pasa la prueba, entonces se considera listo.

La arquitectura de los productos de software desarrollados de esta manera suele ser mejor (en aplicaciones que son adecuadas para pruebas automáticas, la responsabilidad entre los componentes suele estar muy bien distribuida y los procedimientos complejos que se realizan se descomponen en muchos simples). La estabilidad de la aplicación desarrollada a través de las pruebas es mayor debido al hecho de que todas las funcionalidades básicas del programa están cubiertas por las pruebas y su rendimiento se verifica constantemente. El acompañamiento de proyectos en los que se prueba todo o casi todo es muy alto: los desarrolladores pueden no tener miedo de hacer cambios en el código, si algo sale mal, los resultados de las pruebas automáticas informarán sobre esto.

Puede obtener más información sobre los principios de TDD leyendo el libro de Kent Beck Programación extrema Desarrollo a través de pruebas.

TDD - Desarrollo dirigido por tipo

Type Driven Development se abrevia, así como el desarrollo a través de pruebas, por lo que generalmente se escribe el nombre completo.

Cuando se desarrolla sobre la base de tipos, sus tipos de datos y firmas de tipos son una especificación del programa. Los tipos también sirven como una forma de documentación que se garantiza que se actualizará.

Los tipos son pequeños puntos de control, gracias a los cuales obtenemos muchas mini pruebas en toda nuestra aplicación. Además, los costos de crear tipos son mínimos y no es necesario actualizarlos, ya que son parte de la base del código.

El desarrollo por tipo es otro buen método para construir una aplicación. Al igual que con el desarrollo basado en pruebas, el desarrollo basado en tipos puede aumentar su confianza en su código y ahorrarle tiempo al realizar cambios en una base de código grande.

De las desventajas, solo la creciente complejidad de los idiomas con tipeo dinámico. Por ejemplo, para JavaScript, este enfoque es más difícil de aplicar que para TypeScript.

En un habr hay un excelente artículo sobre mecanografía.

BDD - Desarrollo impulsado por el comportamiento

Debido a algunas similitudes metodológicas, TDD (Test Driven Development) y BDD (Behavior Driven Development) a menudo se confunden incluso por profesionales. Cual es la diferencia Los conceptos de ambos enfoques son similares, se llevan a cabo las primeras pruebas y solo luego comienza el desarrollo, pero su propósito es completamente diferente. TDD tiene más que ver con la programación y las pruebas en el nivel de implementación técnica del producto, cuando las pruebas son creadas por los propios desarrolladores. BDD involucra a un probador o analista que describe scripts definidos por el usuario en un lenguaje natural , si puedo decirlo, en el lenguaje de los negocios.

BDD: el desarrollo basado en el comportamiento es un desarrollo basado en el comportamiento. Cierta persona (o personas) escribe descripciones del formulario "como usuario que quiero cuando se presiona el botón de inicio y luego se muestra el menú como en la imagen" (hay palabras clave especialmente resaltadas). Los programadores han escrito durante mucho tiempo herramientas especiales que traducen tales descripciones en pruebas (a veces completamente transparentes para el programador). Y luego el desarrollo clásico con pruebas.

Si registra los nombres de las pruebas en forma de oraciones y utiliza el vocabulario del dominio comercial para escribir los nombres de los métodos, la documentación creada queda clara para los clientes, analistas y evaluadores.

Los textos del guión se escriben en una forma específica.

Tener (aprox. Dado - dado) algún contexto,

Cuando (tenga en cuenta cuándo) se produce un evento,

Luego (aprox. Entonces) verifique el resultado.

Algo como esto podría suceder:

O otro ejemplo en ruso:

Escenario 1: hay dinero en la cuenta +

Tener una cuenta con dinero

Y una tarjeta válida

Y un cajero automático con efectivo

Cuando un cliente solicita efectivo

Luego, asegúrese de que la cuenta haya sido cargada

Y asegúrese de que se emita efectivo

Y asegúrese de devolver la tarjeta

El enfoque BDD, junto con las prácticas de ingeniería, nos permitió abandonar la documentación heredada que contiene información irrelevante y recibir nueva documentación sobre la marcha, almacenarla con el proyecto, lo que acercó a los analistas y probadores al código.

BDD es más bien un proceso cuyo objetivo es reducir el costo de implementar nuevas características. Incluso al comienzo del desarrollo, obtenemos artefactos importantes. Por ejemplo, documentación que sea comprensible para soportar. Esta documentación brinda una oportunidad para que todas las partes interesadas comprendan el producto y los escenarios de comportamiento del usuario que deben implementarse durante las iteraciones de desarrollo. Con el enfoque BDD, también bajamos el umbral para que nuevos miembros ingresen al proyecto.

¿Cuál es la ventaja de BDD?

• Pruebas legibles para no programadores.
• Son fáciles de cambiar. A menudo se escriben en inglés casi puro.
• Pueden ser escritos por el propietario del producto u otras partes interesadas.
• Los resultados de la prueba son más humanos.
• Las pruebas son independientes del lenguaje de programación de destino. La migración a otro idioma se simplifica enormemente.

Contras:

Pero este enfoque tiene sus inconvenientes: es largo y costoso. BDD es inconveniente incluso si requiere la participación de especialistas en pruebas que ya están en la etapa de desarrollo de requisitos, y esto alarga el ciclo de desarrollo.

La solución a esta situación puede ser la elección de un marco BDD adecuado y procesos de desarrollo adecuadamente construidos.

Lea más sobre BDD aquí .

Muchos han entendido durante mucho tiempo que las pruebas son una especie de panacea para todas las enfermedades, pero ¿es realmente así? Por supuesto, el código probado a fondo funciona de manera más estable y predecible, pero las pruebas no nos salvan de problemas y errores en la etapa de diseño y configuración de tareas. Los siguientes enfoques de desarrollo pueden ayudarlo con esto.

DDD - Diseño impulsado por dominio

El diseño orientado a temas no es una tecnología o metodología específica. DDD es un conjunto de reglas que le permiten tomar las decisiones de diseño correctas. Este enfoque puede acelerar significativamente el proceso de diseño de software en un dominio desconocido.

El diseño orientado a temas (con menos frecuencia orientado a problemas, inglés. Diseño impulsado por dominios, DDD) es un conjunto de principios y esquemas destinados a crear sistemas óptimos de objetos. El proceso de desarrollo se reduce a la creación de abstracciones de software, que se denominan modelos de dominio. Estos modelos incluyen lógica de negocios que establece una relación entre las condiciones reales del área de aplicación del producto y el código.

El enfoque DDD es especialmente útil en situaciones donde el desarrollador no es un especialista en el campo del producto desarrollado. Por ejemplo: un programador no puede conocer todas las áreas en las que se requiere crear software, pero con la ayuda de una representación correcta de la estructura, a través de un enfoque orientado a temas, puede diseñar fácilmente una aplicación basada en puntos clave y el conocimiento del espacio de trabajo.

En este artículo, trato de transmitir la esencia de cada enfoque para el desarrollo de software, pero sobre DDD puedes escribir más de un artículo y cubrir todos los matices en varios párrafos, no funcionará para mí. Por lo tanto, al explicar, proporcionaré enlaces explicativos a las fuentes más valiosas.

El objetivo principal del diseño impulsado por dominio es combatir la complejidad de los procesos comerciales, su automatización e implementación en código. "Dominio" se traduce como "dominio", y el desarrollo y el diseño dentro del marco de este enfoque se alejan del dominio.

El concepto clave en DDD es el lenguaje ubicuo. El lenguaje ubicuo promueve la comunicación transparente entre los participantes del proyecto. Él no es uno en el sentido de que es uno para todas las ocasiones. Justo lo contrario. Todos los participantes se comunican en él, toda la discusión se lleva a cabo en términos de un solo idioma, y ​​todos los artefactos deben presentarse en términos de un solo idioma, es decir, comenzando por TK y terminando con un código.

El siguiente concepto es el "modelo de dominio". Este modelo es un glosario de términos del lenguaje ubicuo. Tanto el modelo de dominio como el lenguaje ubicuo están limitados por el contexto que Domain-Driven Design llama contexto acotado. Restringe el modelo de dominio de tal manera que todos los conceptos dentro de él no sean ambiguos y todos entiendan lo que está en juego.

Ejemplo: tome la entidad "persona" y colóquela en el contexto de "hablar en público". En este contexto, según DDD, se convierte en un orador o orador. Y en el contexto de la "familia": un esposo o hermano.

Ahora sobre el código. Es importante que su código se lea como un libro, que sea simple y comprensible para cualquiera que hable un lenguaje de proyecto común. A que me refiero

Si en el lenguaje del proyecto usa la expresión "el producto ha sido agregado", entonces la siguiente opción no es DDD:

producto var = producto nuevo ('manzana')

product.save ()

Por qué El código dice que creamos el producto de una manera extraña y lo guardamos. ¿Cómo agregar un producto de todos modos? Necesito agregarlo . Aquí está el código DDD:

Producto :: add ('manzana');

Arquitectura:

Desde el punto de vista del diseño impulsado por dominio, realmente no importa qué arquitectura elija. El diseño dirigido por el dominio no se trata de eso; el diseño dirigido por el dominio se trata del lenguaje y la comunicación.

Pero DDD es casi imposible sin una arquitectura de proyecto limpia, porque al agregar una nueva funcionalidad o cambiar la antigua, debe intentar mantener la flexibilidad y la transparencia de la base del código. Puede leer sobre puertos, adaptadores y arquitectura de cebolla en un excelente artículo . La imagen de arriba es solo de ella.

También hay artículos sobre DDD que recomiendo leer detenidamente, aquí y aquí .

¿Qué nos da esto al final?

• casi todos los miembros del equipo pueden leer el código del proyecto;
• la declaración de tareas se vuelve más explícita;
• los errores en la lógica de negocios se vuelven más fáciles de buscar;
• Es mucho más fácil para los especialistas en control de calidad escanear el código y encontrar errores lógicos y errores.

Contras:

• Se requieren desarrolladores altamente calificados, especialmente al comienzo del proyecto;
• No todos los clientes están dispuestos a hacer tales costos, DDD debe ser estudiado por todos los participantes en el proceso de desarrollo.

FDD - Desarrollo dirigido por características

FDD: esta metodología (denominada brevemente FDD) fue desarrollada por Jeff De Luca y reconocido gurú en el campo de las tecnologías orientadas a objetos, Peter Coad. FDD es un intento de combinar las técnicas más reconocidas en la industria del desarrollo de software que toman como base la importante funcionalidad (propiedades) del software desarrollado para el cliente. El objetivo principal de esta metodología es desarrollar software real y de trabajo sistemáticamente, a tiempo.

Al igual que otras metodologías adaptativas, se enfoca en iteraciones cortas, cada una de las cuales sirve para desarrollar una cierta parte de la funcionalidad del sistema. Según el FDD, una iteración dura dos semanas. FDD tiene cinco procesos. Los tres primeros se relacionan con el inicio del proyecto:

• desarrollo de un modelo común;
• compilar una lista de propiedades del sistema requeridas;
• planificación del trabajo en cada propiedad;
• diseño de cada propiedad;
• construcción de cada propiedad.

Los dos últimos pasos deben realizarse durante cada iteración. Además, cada proceso se divide en tareas y tiene criterios de verificación.

Detengámonos en cada artículo con más detalle.

Desarrollo de un modelo común.

El desarrollo comienza con un análisis de la amplitud de la gama existente de tareas y el contexto del sistema. Además, para cada área simulada, se realiza un análisis más detallado. Las descripciones preliminares se compilan en pequeños grupos y se envían para su posterior discusión y evaluación experta. Después de uno de los modelos propuestos o su combinación se convierte en un modelo para un área específica. Los modelos de cada área de tareas se combinan en un modelo final común, que puede cambiar durante el trabajo.

Características de listado

La información recopilada durante la construcción del modelo general se utiliza para compilar una lista de funciones. Las funciones se combinan en los llamados "dominios" (dominio inglés) y, a su vez, se dividen en subregiones (áreas temáticas en inglés) de acuerdo con un atributo funcional.

Cada subdominio corresponde a un proceso comercial específico, y sus pasos se convierten en una lista de funciones (propiedades). Las funciones se presentan en la forma "acción - resultado - objeto", por ejemplo, "verificar contraseña de usuario". El desarrollo de cada función no debería demorar más de 2 semanas; de lo contrario, la tarea debe descomponerse en iteraciones más pequeñas. La lista de propiedades en FDD es la misma que la acumulación de productos en SCRUM.

Plan de propiedades (funciones)

La siguiente etapa es la distribución de funciones entre los principales programadores o equipos.

Diseño de funciones

Se crea un paquete de diseño para cada propiedad. El programador principal describe un pequeño grupo de propiedades para el desarrollo en dos semanas. Después de eso, quedan diagramas de secuencia detallados para cada propiedad, especificando el modelo general. A continuación se encuentran escritos "trozos" de clases y métodos. En este punto, debemos centrarnos en el diseño del producto de software.

Implementación de funciones

Escribimos el código, eliminamos los trozos, probamos.

Una vez que la propiedad ha sido probada e incorporada al producto, tomamos la siguiente propiedad prioritaria y repetimos el ciclo de diseño / implementación.

Total, como resultado, obtenemos:

• documentación de propiedades del sistema;
• diseño cuidadoso;
• más fácil de evaluar tareas pequeñas;
• las pruebas se centran en tareas comerciales;
• sofisticado proceso de creación de productos;
• Los ciclos de desarrollo iterativos cortos le permiten aumentar rápidamente la funcionalidad y reducir los errores.

Contras:

• FDD es más adecuado para grandes proyectos. Los pequeños equipos de desarrollo no podrán experimentar todos los beneficios de este enfoque;
• costos significativos de implementación y capacitación.

MDD - Desarrollo guiado por modelos

Recientemente, se ha prestado mucha atención en publicaciones al tema de la arquitectura y el desarrollo basados ​​en los modelos MDA (Model Driven Architecture) y MDD (Model Driven Development). Sin entrar en detalles, destacamos solo los puntos clave.

El desarrollo basado en modelos es un estilo de desarrollo de software en el que los modelos se convierten en los principales artefactos de desarrollo a partir de los cuales se generan código y otros artefactos.

, , .

MDD — , . - .

. . , , . MDD — , , .

«», . ( ).

MDD ‑ . , , . MDD-, . Unified Modeling Language – UML 2.0.

Object Management Group (OMG) :

• c , ;
• - ;
• , .

MDD, , — . .

:

• (Minimum Viable Product) ;
• : , , ;
• ;
• .

:

• MMD , Rational Software Architect, Simulink Sirius;
• ;
• .

PDD — Panic Driven Development

agile , PDD. , .

.

, , . . , ? , .

, , .

. . UX . ? , . , .

.

, , , . , . . , .

.

— . . . . . .

.

, , , — , . . , , , .

, .

, . . , , .

:

• ;
• ;
• , - .

:

• .

PDD , , , .

Conclusión

agile . , , .

Espero que muchos de ustedes hayan aprendido algo nuevo sobre las prácticas de Desarrollo Dirigido, y ahora, al encontrarse cara a cara con las abreviaturas DDD, BDD, MDD, no experimentarán confusión, o tal vez incluso quieran probarlas en la práctica.