Examinando artigos sobre design de software, encontrei constantemente uma nuvem de abreviações sem precedentes e práticas de desenvolvimento mencionadas casualmente.

• TDD - bem, todo mundo sabe disso, primeiro escrevemos testes e depois o resto do código.
• O BDD é algo familiar, como testes também, mas especiais.
• TDD - Novamente? Então, pare, aqui não se trata de testes. Mas por que é chamado o mesmo?
• DDD - contextos ligados, linguagem onipresente, domínio ...
• FDD - Sim, quanto é possível?
• MDD - Sério, baseado em gráficos?
• PDD - ...

As abordagens de desenvolvimento são divididas por complexidade, áreas de aplicação e objetivos.
Acho que chegou a hora de descobrir por que eles são necessários, por que existem tantos deles e como eles podem ser úteis para nós.

Começaremos a familiarizá-los do mais simples ao mais complexo, considerar exemplos de uso e os prós e contras de cada um deles.

TDD - Desenvolvimento Orientado a Testes

TDD é uma metodologia de desenvolvimento de software que se baseia na repetição de ciclos curtos de desenvolvimento: inicialmente um teste é gravado cobrindo a alteração desejada e, em seguida, é gravado o código do programa que implementa o comportamento desejado do sistema e permite que você passe no teste escrito. Em seguida, o código escrito é refatorado com testes constantes dos testes.

Parece simples e claro. Muitos estão familiarizados com essa abordagem do desenvolvimento, e até o próprio tio Bob a está promovendo ativamente.

O TDD é considerado uma forma de construção apropriada do aplicativo. A filosofia de desenvolvimento orientada a testes é que seus testes são uma especificação de como seu programa deve se comportar. Se você considerar seu conjunto de testes uma parte obrigatória do processo de compilação, se seus testes falharem, o programa não será compilado porque está incorreto. Obviamente, a limitação é que a correção do seu programa é definida apenas como a integridade dos seus testes. No entanto, estudos mostraram que o desenvolvimento baseado em testes pode reduzir os erros em 40 a 80% na produção.

Ao começar a usar o TDD, você pode sentir que está executando mais devagar que o normal. Isso ocorre porque você estará trabalhando fora da “zona de conforto”, e isso é bastante normal.

Depois de sentir que escrever testes se tornou uma parte simples e natural do fluxo de trabalho, que você não precisa mais pensar em usar o TDD ao trabalhar em um projeto, percebe que o TDD fluiu para o seu trabalho.

Essa metodologia permite obter a criação de um aplicativo adequado para testes automáticos e uma cobertura muito boa do código com testes, uma vez que o TK é traduzido para o idioma dos testes automáticos, ou seja, tudo o que o programa deve fazer é verificado. O TDD também frequentemente simplifica a implementação do software: a redundância da implementação é eliminada - se um componente passa no teste, ele é considerado pronto.

A arquitetura dos produtos de software desenvolvidos dessa maneira geralmente é melhor (em aplicativos adequados para testes automáticos, a responsabilidade entre os componentes geralmente é muito bem distribuída e os procedimentos complexos que são executados são decompostos em muitos simples). A estabilidade do aplicativo desenvolvido por meio de testes é maior devido ao fato de que todas as funcionalidades básicas do programa são cobertas por testes e seu desempenho é constantemente verificado. Acompanhar projetos nos quais tudo ou quase tudo é testado é muito alto - os desenvolvedores podem não ter medo de fazer alterações no código; se algo der errado, os resultados dos testes automáticos informarão sobre isso.

Você pode aprender mais sobre os princípios de TDD lendo o livro Extreme Programming, de Kent Beck. Desenvolvimento através de testes.

TDD - Desenvolvimento Orientado a Tipo

O desenvolvimento orientado a tipo é abreviado, assim como o desenvolvimento por meio de testes; portanto, geralmente o nome completo é escrito.

Ao desenvolver com base em tipos, seus tipos de dados e assinaturas de tipo são uma especificação do programa. Os tipos também servem como uma forma de documentação que garante a atualização.

Os tipos são pequenos pontos de controle, graças aos quais recebemos muitos mini-testes em toda a nossa aplicação. Além disso, os custos de criação de tipos são mínimos e a atualização deles não é necessária, pois eles fazem parte da base de código.

O desenvolvimento por tipo é outro bom método para criar um aplicativo. Como no desenvolvimento baseado em teste, o desenvolvimento baseado em tipo pode aumentar sua confiança em seu código e economizar tempo ao fazer alterações em uma grande base de código.

Das desvantagens, apenas a crescente complexidade de idiomas com digitação dinâmica. Por exemplo, para JavaScript, essa abordagem é mais difícil de aplicar do que para TypeScript.

Em um habr, há um excelente artigo sobre digitação.

BDD - Desenvolvimento Orientado a Comportamentos

Devido a algumas semelhanças metodológicas, TDD (Test Driven Development) e BDD (Behavior Driven Development) são frequentemente confundidos até mesmo por profissionais. Qual a diferença? Os conceitos de ambas as abordagens são semelhantes, os primeiros testes são realizados e somente então o desenvolvimento começa, mas seu objetivo é completamente diferente. O TDD é mais sobre programação e teste no nível de implementação técnica do produto, quando os testes são criados pelos próprios desenvolvedores. O BDD envolve um testador ou analista que descreve scripts definidos pelo usuário em uma linguagem natural - se assim posso dizer, na linguagem dos negócios.

BDD - desenvolvimento orientado a comportamento é um desenvolvimento baseado em comportamento. Uma determinada pessoa (ou pessoas) escreve descrições do formulário "como usuário que eu quero quando o botão Iniciar é pressionado e o menu é exibido como na figura" (existem palavras-chave especialmente destacadas). Os programadores há muito tempo escrevem ferramentas especiais que convertem essas descrições em testes (às vezes completamente transparentes para o programador). E então o desenvolvimento clássico com testes.

Se você gravar os nomes dos testes na forma de frases e usar o vocabulário do domínio comercial para escrever os nomes dos métodos, a documentação criada ficará clara para os clientes, analistas e testadores.

Os textos dos scripts são escritos de uma forma específica.

Tendo (aproximadamente. Dado - dado) algum contexto,

Quando (observe quando) um evento ocorre,

Então (aprox. Então) verifique o resultado.

Algo como isso pode acontecer:

Ou outro exemplo em russo:

Cenário 1: há dinheiro na conta +

Ter uma conta com dinheiro

E um cartão válido

E um caixa eletrônico com dinheiro

Quando um cliente solicita dinheiro

Em seguida, verifique se a conta foi debitada

E verifique se o dinheiro é emitido

E verifique se o cartão foi devolvido

A abordagem do BDD, juntamente com as práticas de engenharia, nos permitiu abandonar a documentação legada que contém informações irrelevantes e receber nova documentação em tempo real, armazená-la no projeto, o que aproximou analistas e testadores do código.

O BDD é um processo cujo objetivo é reduzir o custo da implementação de novos recursos. Mesmo no início do desenvolvimento, obtemos artefatos importantes. Por exemplo, documentação compreensível para oferecer suporte. Esta documentação fornece uma oportunidade para todas as partes interessadas formarem seu entendimento dos cenários de comportamento do produto e do usuário que devem ser implementados durante as iterações de desenvolvimento. Com a abordagem do BDD, também reduzimos o limite para novos membros entrarem no projeto.

Qual é a vantagem do BDD?

• Testes legíveis para não programadores.
• Eles são fáceis de mudar. Eles são frequentemente escritos em inglês quase puro.
• Eles podem ser escritos pelo proprietário do produto ou por outras partes interessadas.
• Os resultados do teste são mais humanos.
• Os testes são independentes da linguagem de programação de destino. A migração para outro idioma é bastante simplificada.

Contras:

Mas essa abordagem tem suas desvantagens - é longa e cara. O BDD é inconveniente, mesmo que exija o envolvimento de especialistas em testes já no estágio de desenvolvimento de requisitos, e isso prolonga o ciclo de desenvolvimento.

A saída dessa situação pode ser a escolha de uma estrutura BDD adequada e de processos de desenvolvimento adequadamente construídos.

Leia mais sobre o BDD aqui .

Muitos há muito entendem que o teste é um tipo de panacéia para todas as doenças, mas é realmente assim? Obviamente, o código completamente testado funciona de maneira mais estável e previsível, mas os testes não nos salvam de problemas e erros no estágio de design e configuração de tarefas. As seguintes abordagens de desenvolvimento podem ajudá-lo com isso.

DDD - Design Orientado a Domínio

O design orientado ao assunto não é uma tecnologia ou metodologia específica. DDD é um conjunto de regras que permitem que você tome as decisões corretas de design. Essa abordagem pode acelerar significativamente o processo de criação de software em um domínio desconhecido.

Design orientado ao assunto (menos frequentemente, orientado a problemas, inglês. Design orientado a domínio, DDD) é um conjunto de princípios e esquemas destinados a criar sistemas ideais de objetos. O processo de desenvolvimento se resume à criação de abstrações de software, chamadas de modelos de domínio. Esses modelos incluem lógica de negócios que estabelece um relacionamento entre as condições reais da área de aplicação do produto e o código.

A abordagem DDD é especialmente útil em situações em que o desenvolvedor não é um especialista no campo do produto desenvolvido. Por exemplo: um programador não pode conhecer todas as áreas em que é necessário criar software, mas com a ajuda de uma representação correta da estrutura, por meio de uma abordagem orientada ao assunto, ele pode facilmente projetar um aplicativo com base em pontos-chave e conhecimento do espaço de trabalho.

Neste artigo, tento transmitir a essência de cada abordagem ao desenvolvimento de software, mas sobre o DDD você pode escrever mais de um artigo e cobrir todas as nuances em vários parágrafos, não vai funcionar para mim. Portanto, ao explicar, fornecerei links explicativos para as fontes mais dignas.

O principal objetivo do Design Orientado a Domínio é combater a complexidade dos processos de negócios, sua automação e implementação em código. "Domínio" é traduzido como "domínio", e o desenvolvimento e o design, dentro da estrutura dessa abordagem, são afastados do domínio.

O conceito-chave no DDD é a linguagem onipresente. Linguagem onipresente promove comunicação transparente entre os participantes do projeto. Ele não é um no sentido de ser um para todas as ocasiões. Exatamente o oposto. Todos os participantes se comunicam, toda a discussão ocorre em termos de um único idioma e todos os artefatos devem ser apresentados em termos de um único idioma, ou seja, iniciando no TK e terminando com um código.

O próximo conceito é o "modelo de domínio". Este modelo é um glossário de termos de linguagem onipresente. O modelo de domínio e a linguagem onipresente são limitados pelo contexto que o Design Orientado a Domínio chama de contexto limitado. Ele restringe o modelo de domínio de forma que todos os conceitos contidos nele sejam inequívocos e todos entendam o que está em jogo.

Exemplo: pegue a entidade "pessoa" e coloque-a no contexto de "falar em público". Nesse contexto, de acordo com DDD, ele se torna um orador ou orador. E no contexto de "família" - um marido ou irmão.

Agora sobre o código. É importante que seu código seja lido como um livro, que seja simples e compreensível para quem fala uma linguagem comum de projeto. O que eu quero dizer?

Se no idioma do projeto você usar a expressão "o produto foi adicionado", a opção a seguir não será DDD:

var product = new Product ('apple')

product.save ()

Porque O código diz que criamos o produto de uma maneira estranha e o salvamos. Como adicionar um produto da mesma forma? Precisa adicioná-lo . Aqui está o código DDD:

Produto :: add ('apple');

Arquitetura:

Do ponto de vista do Design Orientado a Domínio, não importa realmente qual arquitetura você escolher. Design Orientado a Domínio não é sobre isso; Design Orientado a Domínio é sobre linguagem e comunicação.

Mas o DDD é quase impossível sem uma arquitetura de projeto limpa, porque ao adicionar novas funcionalidades ou alterar as antigas, você precisa tentar manter a flexibilidade e a transparência da base de código. Você pode ler sobre portas, adaptadores e arquitetura de cebola em um ótimo artigo . A imagem acima é apenas dele.

Também existem artigos sobre DDD que recomendo a leitura cuidadosa - aqui e aqui .

O que isso nos dá no final:

• quase todos os membros da equipe podem ler o código do projeto;
• declaração de tarefas se torna mais explícita;
• erros na lógica de negócios tornam-se mais fáceis de procurar;
• É muito mais fácil para os especialistas em controle de qualidade verificar o código e encontrar erros e erros lógicos.

Contras:

• Desenvolvedores altamente qualificados são necessários, especialmente no início do projeto;
• nem todos os clientes estão dispostos a fazer esses custos, o DDD precisa ser estudado por todos os participantes do processo de desenvolvimento.

FDD - Desenvolvimento Orientado a Recursos

FDD - Essa metodologia (referida brevemente como FDD) foi desenvolvida por Jeff De Luca e reconhecido guru no campo das tecnologias orientadas a objetos, Peter Coad. O FDD é uma tentativa de combinar as técnicas mais reconhecidas no setor de desenvolvimento de software que baseiam as importantes funcionalidades (propriedades) do software desenvolvido para o cliente. O principal objetivo dessa metodologia é desenvolver software real e de trabalho sistematicamente, dentro do prazo.

Como outras metodologias adaptativas, ele se concentra em iterações curtas, cada uma das quais serve para determinar uma certa parte da funcionalidade do sistema. Segundo o FDD, uma iteração dura duas semanas. O FDD possui cinco processos. Os três primeiros estão relacionados ao início do projeto:

• desenvolvimento de um modelo comum;
• compilar uma lista de propriedades do sistema necessárias;
• planejamento de trabalho em cada propriedade;
• desenho de cada propriedade;
• construção de cada propriedade.

As duas últimas etapas devem ser realizadas durante cada iteração. Além disso, cada processo é dividido em tarefas e possui critérios de verificação.

Vamos abordar cada item com mais detalhes.

Desenvolvimento de um modelo comum.

O desenvolvimento começa com uma análise da amplitude do conjunto de tarefas existente e do contexto do sistema. Além disso, para cada área simulada, é feita uma análise mais detalhada. As descrições preliminares são compiladas em pequenos grupos e enviadas para discussão adicional e avaliação de especialistas. Após um dos modelos propostos ou sua combinação se tornar um modelo para uma área específica. Os modelos de cada área de tarefa são combinados em um modelo final comum, que pode mudar durante o trabalho.

Recursos de Listagem

As informações coletadas durante a construção do modelo geral são usadas para compilar uma lista de funções. As funções são combinadas nos chamados "domínios" (domínio em inglês) e, por sua vez, são divididas em sub-regiões (áreas de assunto em inglês) de acordo com um atributo funcional.

Cada subdomínio corresponde a um processo de negócios específico e suas etapas se tornam uma lista de funções (propriedades). As funções são apresentadas no formato "ação - resultado - objeto", por exemplo, "verificar senha do usuário". O desenvolvimento de cada função não deve demorar mais de 2 semanas, caso contrário, a tarefa deve ser decomposta em iterações menores. A lista de propriedades no FDD é igual à lista de pendências do produto no SCRUM.

Plano de propriedades (funções)

O próximo estágio é a distribuição de funções entre os principais programadores ou equipes.

Design de Recursos

Um pacote de design é criado para cada propriedade. O programador principal descreve um pequeno grupo de propriedades para desenvolvimento dentro de duas semanas. Depois disso, são deixados diagramas de sequência detalhados para cada propriedade, especificando o modelo geral. A seguir, são escritos "stubs" de classes e métodos. Neste ponto, devemos nos concentrar no design do produto de software.

Implementação da função

Nós escrevemos o código, removemos os stubs, testamos.

Após a propriedade ter sido testada e inserida no produto, assumimos a próxima propriedade prioritária, repita o ciclo de design / implementação.

Total, como resultado, obtemos:

• documentação de propriedades do sistema;
• design cuidadoso;
• mais fácil avaliar pequenas tarefas;
• os testes são focados em tarefas de negócios;
• processo sofisticado de criação de produtos;
• Ciclos de desenvolvimento iterativo curtos permitem aumentar rapidamente a funcionalidade e reduzir erros.

Contras:

• O FDD é mais adequado para grandes projetos. Pequenas equipes de desenvolvimento não poderão experimentar todos os benefícios dessa abordagem;
• custos significativos de implementação e treinamento.

MDD - Desenvolvimento Orientado a Modelos

Recentemente, muita atenção foi dada em publicações ao tópico de arquitetura e desenvolvimento baseado nos modelos MDA (Model Driven Architecture) e MDD (Model Driven Development). Sem entrar em detalhes, destacamos apenas os principais pontos.

Desenvolvimento orientado a modelo é um estilo de desenvolvimento de software em que os modelos se tornam os principais artefatos de desenvolvimento a partir dos quais o código e outros artefatos são gerados.

, , .

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 , , , .

Conclusão

agile . , , .

Espero que muitos de vocês tenham aprendido algo novo sobre as práticas de Desenvolvimento Dirigido e, agora, encontrando-se frente a frente com as abreviaturas DDD, BDD, MDD, você não sinta confusão ou tente testá-las na prática.