Um Craftsman precisa de processos?

gistfile1.md

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

My two cents ...

Quem praticou/pratica porém crê que o valor gerado não agrega muito ao seu dia-a-dia, eu respeito(Porcelli, Lucas como bons exemplos). Quem critica e não sabe se quer argumentar prós e contras do uso pois simplesmente é relaxado e não usa testes (TDD por exemplo) ... bom para este camarada não tem argumentação. Fazendo um paralelo aqui é como discutir gramática com uma pessoa que sabe no máximo "desenhar" seu nome no papel.

Congrats Porcelli.

Sobre esse trecho na resposta do Luca Bastos:
"Para começar, um comentário em relação a frase:
"Se alguém desenvolve um sistema sobre o que não conhece... então isso está MUITO errado."

Acho que perdi a conta na minha vida dos sistemas que desenvolvi em áreas em que não tinha o menor conhecimento."

Acho essa atitude do Luca um tremendo erro. Eu também já fui contratado para trabalhar em vários sistemas onde não tinha conhecimento, porém penso ser obrigatório eu buscar conhecimento para retornar o melhor valor ao contratante.

Atualmente estou trabalhando diretamente com SPED, e considero normal conversar de igual com contadores dos clientes. Durante esse tempo fui em mais eventos/treinamentos sobre SPED do que sobre desenvolvimento.

Considero obrigação de um desenvolvedor um pleno conhecimento no negócio em que está atuando.

Gostei bastante do texto e também do que o Luca comentou.

Hoje não utilizo desses técnicas mas já estudei e ainda continuo estudando. Em meu ponto de vista há casos e casos para se aplicar ou não cada um dos itens discutidos acima pois sinto que não sejam completamente dispensáveis.

Sobre a parte que o Luca comenta "Acho que perdi a conta na minha vida dos sistemas que desenvolvi em áreas em que não tinha o menor conhecimento." concordo com a visão que ele passa e se não fosse assim não existiriam desenvolvedores. Existiriam apenas administradores que sabem uma linguagem ou outra, bancários que também sabem codar, vendedores que no fim de semana otimizam sua loja virtual entre tantas outras áreas em que atuamos.
Somos movidos a desafios e se eles não existirem certamente não existiremos tb. Eu particularmente acho mais difícil conhecer o ramo do que as linguagens e isso pra mim é o maior desafio e o que motiva.
Somos contratados pois sabemos a parte que os profissionais do ramo não sabem. Se tivéssemos a obrigação de conhecer o ramo seria mais fácil contratar um administrador/agricultor/vendedor/etc e ensinar ele a programar.
Mas esse é apenas o meu simples ponto de vista não querendo discordar do que já foi falado nos outros comments.

Eu tb acho que fazer código bom é obrigação de todo desenvolvedor. E penso que os fundamentos disso são coisas absurdamente negligenciadas, como saber criar boas APIs, saber inventar bons nomes para as classes, saber entender bem o problema (não necessariamente o sistema todo de uma vez, mas pelo menos a parte que vc vai fazer), saber usar uma folha de papel para te ajudar no entendimento... Eu vejo pouquíssimas pessoas falando desses assuntos e na faculdade eu não aprendi quase nada disso, e no entanto considero como as coisas que mais te ajudam a ser um bom desenvolvedor.

Estou usando xDD pela primeira vez, mais especificamente, BDD com o Jasmine.js, no projeto em que estou trabalhando. Fui eu que comecei o projeto, há uma semana, e estamos usando BDD desde o zero. Estou adorando! Me ajudou em muitas coisas, inclusive definir os métodos pras minhas classes, coisa que estava um pouco difícil enquanto eu estava somente analisando o problema.

Deu certo pra mim. Assim, estou gostando de usar BDD. Isso faz toda a diferença. Está funfando bem no meu projeto? Ótimo, vamos usar! Não singifica que tenha que ser assim sempre. Dizer "agora é só xDD" é uma visão tão limitada quanto "agora é só Java / agora é só C / agora é só celular / agora é só web" e tantos outros "agora é só XYZ" que a gente já ouviu na vida.

Sobre o comentário do @ederign, confesso que, no fundo no fundo, eu penso igual ao Dijkstra :)... Deveríamos ser capazes de fazer programas sem falhas e não achar isso nenhum absurdo ou surrealidade.

Numa postura mas filosófica o que realmente importa é resolver o problema do cliente, nenhuma dessas ferramentas fazem sentido sem essa premissa básica.

Acredito que escrever bons testes é tão complexo como escrever bons códigos.
O detalhe mais importante é que o conceito de bom é muito subjetivo e vai variar de projeto, cliente etc

Concordo plenamente com o @dannluciano! E vivam as premissas básicas...

@lucabastos clap clap clap

@martinusso acho que o que o @lucabastos falou sobre desenvolver sem conhecer a área é exatamente a mesma coisa que você fez. Entrou sem saber e se aprofundou para resolver os problemas. E não o contrário como parece no seu texto.

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

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

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

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

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!