Vou iniciar este post com uma breve visão do que EU entendo sobre os principais XDD para em seguida discutir o motivo pelo qual não os acho relevante. Gostaria também de ressaltar que posso SIM ter uma visão limitada ou equivocada destes XDD’s, porém não vamos minimizar esta discussão com argumentos simplórios como “falta de conhecimento”, “falta de prática” ou coisas do gênero... pois o que será discutido aqui é um pouco mais conceitual e filosófico do que as técnicas/processos em si.
Com isso dito, vamos lá:
Esta técnica (ou processo) que visa obter uma maior qualidade na arquitetura/código, pois guindo o desenvolvimento por testes além de se ter um resultado mais assertivo, você também obtém uma arquitetura desacoplada. Geralmente se aplica este processo (NovoTeste->Falha->Implantação->Sucesso->NovoTeste...) em pequenos ciclos.
Um desenvolvedor realmente precisa de um processo para obter qualidade em seu código?
Este processo estende o TDD criando uma camada adicional/complementar de testes que explorem características comportamentais da aplicação. Geralmente estes testes são escritos em uma linguagem mais natural, para que outros stakeholders possam entendê-los.
Sinceramente acredito que este seja o processo mais dispensável de todos - sua existência comprova a falta de capacidade de desenvolvedores criar APIs de qualidade.
Alguém pode contrapor: ahh mas como criar APIs para algoritmos complexos? Bem se seu stakeholders precisa verificar um algoritmos complexo, ele não precisara dos tipos de testes que BDD propõe, pois ele será tecnicamente capaz de entender/ler código.
Esta “metodologia” ou “guia” ou “coleção de boas práticas” ou qualquer que seja o seu “papel” define, em linhas gerais (sim o livro do Eric Evans é gigante, com vários detalhes e sub-processos - mas aqui vou me concentrar na visão geral) que a aplicação deve ser projetada com um modelo (ontologia?) criado com base em uma linguagem ubíqua entre os envolvidos (desenvolvedores, analistas de negócios, especialistas de domínio, etc..) e com isso diminuir ruídos e acelerar o desenvolvimento. Para isso se prega diversas técnicas, em geral visando minimizar ruídos (camadas excedentes) e facilitar a comunicação e assertividade do resultado final.
Desenvolvedores devem ser capazes de lidar com abstrações E principalmente traduzir suas abstrações em ações de negocio. Um bom profissional vai saber ouvir o analista de negócio/domain expert (ou o q seja) para transformar seus desejos em uma linguagem de domínio. E qualquer elemento que seja necessário ser adicionado (ex. novas camadas) serão adicionais somente se necessário. Mas se não é assim que todo desenvolvedor trabalha, como seria? Bem... aqui é algo para outra discussão...
Ahhh ainda pode-se defender este modelo com o seguinte argumento: “Mas se você não conhece o domínio com profundidade estas técnicas podem ajudar.” - CALMA LÁ: como algum desenvolvedor pode criar uma abstração sobre o que ele não conhece? Se alguém desenvolve um sistema sobre o que não conhece... então isso está MUITO errado.
Antes de mais nada, vou deixar claro aqui nesta “2a parte” deste post, que NÃO sou contra testes, muito pelo contrário -> sou viciado neles! Como todo código que eu escrevo está no github - você pode ir lá e conferir ;). Acho que testes automatizados são uma peça fundamental no desenvolvimento e manutenção do codebase no médio/longo prazo, mas para mim isso nada está relacionado com a qualidade do produto final ou muito menos que eles devem ajudar ou direcionar o desenvolvimento do meu código. E só para deixar claro: para mim código bem testado != de código de qualidade.
Ahhh e não sou “contra” este métodos/guias/técnicas/processos porque eles podem ou não fazer sentido em contexto de um ou outro projeto - dificilmente eu concordo com este tipo de abordagem. Me faz questionar que tipo de profissional (um médico por exemplo) teria como hábito ver se ele deveria ou não fazer o que ele julga (em seu íntimo) ser o melhor, e ainda assim não fazer. Então independente do tamanho ou ciclo de vida do que você está fazendo, faça o que você acredita que deve ser feito, isso é uma postura profissional.
Voltando aos meus questionamentos... Na verdade o que está por trás deles está o fato de que ,em minha opinião pessoal (e até mesmo radical), desenvolvedores devem ser capazes de criar ainda em sua mente uma boa arquitetura (seja de sistema ou apenas de código) antes de executar. Inclusive esta característica coloco como a grande diferença entre um desenvolvedor e um codemonkey.
Inclusive me atrevo a dizer que bons desenvolvedores devem ser capazes de construir uma estrura de código (APIs) que seja legível (“entendível”) por outros desenvolvedores e até mesmo (em certos níveis de abstração) por outros stakeholders (se for o caso).
Neste momento você pode estar pensando: “Ok, bons desenvolvedores podem até conseguir fazer isso sem *dd, mas e os menos experientes? Para os menos experientes o uso de *dd pode ajudar no caminho/evolução deste profissional.” BESTEIRA: Iniciantes não precisam de processos para ajuda-los a melhorar, o que eles precisam é de BONS MESTRES!
Um bom mestre vai ajudar revisando, orientando, demonstrando e ensinando técnicas de codificação/arquitetura/... - processos vão apenas engessar o processo criativo e guiar por um caminho que é considerado mais “seguro” e não muito mais que isso.
E vamos ser honestos, estes *DDs ou até mesmo coisas como testes automatizados são uma algo bastante recente em nossa indústria. E ainda assim muito antes destas metodologias/técnicas/processos/guias existirem, já contávamos com grandes desenvolvedores, ou seja: capacitados a criar abstrações de forma adequado para seus problemas.
Também não acho que estes processos são desprezíveis ou inúteis, o que quero mais uma vez deixar claro é que qualquer processo/guia/metodologia serão dispensáveis para bons desenvolvedores.
Em resumo, na minha visão criar código/arquitetura de qualidade (aqui podemos falar de forma bem ampla mesmo!) é obrigação do profissional e não deveria ser necessário a utilização de qualquer tipo de muleta para tal fim!
Me esforço para ser um craftsman, e é incompatível com esta busca o fato de que um processo/guia/método (qualquer que seja) defina ou até mesmo guie a qualidade do que desejo produzir. Ou seja: Se quiser matar minha arte, me obrigue a seguir processos.
[]s
Alexandre Porcelli
@fmcypriano admiro tanto o @lucabastos que posso aceitar facilmente que fiz uma interpretação errada de seu comentário, porém "capacidade de extrair informações de quem tinha este conhecimento e automatizar via um sistema" é um pouco diferente de "conhecer profundamente o negócio", que eu considero ser mais importante. Ao menos entendo assim.