Skip to content

Instantly share code, notes, and snippets.

@porcelli
Created July 20, 2012 19:43
Show Gist options
  • Save porcelli/3152802 to your computer and use it in GitHub Desktop.
Save porcelli/3152802 to your computer and use it in GitHub Desktop.
Um Craftsman precisa de processos?

Intro

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á:

TDD (Test-driven development)

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.

Meu ponto de vista:

Um desenvolvedor realmente precisa de um processo para obter qualidade em seu código?

BDD (Behavior-driven development):

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.

Meu ponto de vista:

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.

DDD (Domain-driven design):

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.

Meu ponto de vista:

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.

Discussão

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!

TL;DR:

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

@martinusso
Copy link

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

@fcy
Copy link

fcy commented Jul 21, 2012

@martinusso agora entendi melhor o que você quis dizer. Eu prefiro a capacidade de extrair informação de quem tem o profundo conhecimento. Não acho viável conhecer todas as áreas. Isso, claro, para quem trabalha fazendo vários sistemas. Se é um único produto ou área, ai o conhecimento do negócio vale mais.

@lucabastos
Copy link

@martinusso

O que eu quiz dizer á simples: nos sabemos desenvolver. Quem não sabe nos contrata.

E não falo de emprego. Falo dos meus tempos de empreendedor em que minha empresa tinha que dar um orçamento para desenvolver um sistema sobre algo que não tinha a menor noção. Fiz isto muitas vezes. E em algumas me estrepei.

No caso do sistema de gestão que citei, me dei tão bem que tive esta empresa como cliente por muitos anos sempre me dando novos serviços. É claro que depois que fiz a análise, entrevistei usuários, filtrei informações desconexas dadas por gente que temia perder emprego para o computador, conversei com os que sentiam na carne os problemas da falta de automação, passei a entender do negócio e cheguei a ser capaz de dar sugestões que foram aceitas.

@jorgediz
Copy link

@porcelli
Seu artigo me fez refletir: parte do resultado dessa reflexão coloquei aqui http://jorgediz.wordpress.com/2012/07/22/dedes/

@lucabastos
Muitas e muitas vezes entrei num projeto e precisei aprender o domínio do negócio, a cultura do cliente e a tecnologia enquanto fazia o trabalho. Faz parte do ofício. Há profissionais que se especializam em um domínio de negócios, e há os que transitam entre domínios. Ficar num domínio só é apenas um dos possíveis perfis profissionais.

Em geral, acho que nós, como categoria profissional, colocamos a abstração num patamar inadequado.
Não somos matemáticos, apesar de utilizar formalismos lógicos. Precisamos aprender a entender as limites
de sua utilidade e olhar para nossas próprias limitações ao construir e comunicar essas abstrações.

@lucascaton
Copy link

Fala @porcelli!

Cara, pensei em tudo que você escreveu, mas no final das contas eu discordo.

Eu reconheço que você é um programador muito bom (pelas coisas que você faz e pelo pouco que já conversamos pessoalmente), mas isso não muda o fato de que uma hora você vai precisar atualizar versões de frameworks ou plugins JS ou qualquer outra ferramenta. Nesse momento, você precisará testar tudo novamente, só que de forma manual. E com certeza alguma coisa passará despercebido, por menor que seja o sistema (agora imagine um grande).
`
Existe outro fator relevante que são os outros programadores. Quem garante que você quem manterá o projeto pra sempre? Quem vai ensinar TODAS as regras de negócios para esses novos programadores? É impossível: ou eles não vão aprender tudo de uma vez (nem mesmo fazendo anotações), ou você vai esquecer de explicar porque alguma coisa foi feita de determinada maneira.

E aí caimos em outro ponto interessante dos testes automatizados: ele é a melhor documentação que você vai ter! E isso é um fato! Só entende isso quem já trocou a papelada burocratica por algo melhor. :-)

Abraços!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment