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

No dia que eu tiver metade do talento de um Alexandre Porcelli eu deixo de fazer meu TDD ;)
Até lá não corro os riscos e vou modelando meu domain com passinhos de bebê e deixando desacoplado por meio de testes que me garantem que cada linha que escrevo pelo menos não desgraça o que já fiz.

"I TDD my Spikes Solutions" by Ron Jeffries

Primeiramente sem ofensa pessoal ao Porcelli que é um cara que eu admiro muito o trabalho. É somente para estimular o debate:

Seria este outra razão para a crítica ao *DD ?

Excerto do [EW28][http://www.cs.utexas.edu/~EWD/transcriptions/EWD02xx/EWD288.html]

"Let me start with a well-established fact: by and large the programming community displays a very ambivalent attitude towards the problem of program correctness. A major part of the average programmer's activity is devoted to debugging, and from this observation we may conclude that the correctness of his programs —or should we say: their patent incorrectness?— is for him a matter of considerable concern. I claim that a programmer has only done a decent job when his program is flawless and not when his program is functioning properly only most of the time. But I have had plenty of opportunity to observe that this suggestion is repulsive to many professional programmers: they object to it violently! Apparently, many programmers derive the major part of their intellectual satisfaction and professional excitement from not quite understanding what they are doing. In this streamlined age, one of our most under-nourished psychological needs is the craving for Black Magic, and apparently the automatic computer can satisfy this need for the professional software engineers, who are secretly enthralled by the gigantic risks they take in their daring irresponsibility. They revel in the puzzles posed by the task of debugging. They defend —by appealing to all sorts of supposed Laws of Nature— the right of existence of their program bugs, because they are so attached to them: without the bugs, they feel, programming would no longer be what is used to be! (In the latter feeling I think —if I may say so— that they are quite correct.)"

Edsger W.Dijkstra

Pelo visto, tudo se resume à como o desenvolvedor se sente usando, ou não, tais técnicas.

Só tenho mais experiência com o TDD, então vou falar só sobre ele.

Enxergo o TDD não como "um processo que deve ser imposto a todos os desenvolvedores e morte àqueles que não o seguirem!". Para mim, TDD é uma técnica que ajuda o programador a fazer isso tudo que você bem falou que um desenvolvedor deve saber fazer: criar abstrações, definir APIs etc. Você não é obrigado a fazer dessa forma mas, conforme já foi comprovado por estudos científicos, ele ajuda em alguns pontos.

Se seu código já sai bom sem você seguir TDD, muito bom! Mas, se esse não for o caso, o TDD pode te ajudar a enxergar pontos de melhoria.

TDD também não vai fazer milagre! Não é o TDD que vai te ensinar o negócio do cliente ou vai te ensinar a programar direito. Para essas coisas, você precisa de mentores. Mas TDD, seguido corretamente, levando em conta refatoração e feedback dos testes (como o @mauricioaniche fala bastante), pode te ajudar a errar menos.

Obs.: não considero programação uma arte, mas sim um artesanato. É diferente.

Excelente, Porcelli.

Também estou viciado em testes e por mais que eu não tenha um histórico grande de projetos testados eu não curto tanto algo que seja sem testes automatizados.

Na minha opinião, TDD, BDD e DDD são processos sugeridos para uma adaptação e para auxiliar na escolha das ferramentas que se devem utilizar. Mas assim como metodologias ágeis (XP, scrum, kanban, etc) após uma equipe atingir um certo nível de conforto o processo, não só pode, como deve ser mudado (mesmo que isso tire a identidade do processo) para uma adaptação ao que melhor diz respeito à comunicação da equipe.

Além disso, vejo mais um fenômeno que acontece em BDD, especificamente é a tentativa frustrada de tornar testes automatizados em especificação de projeto. Isso é uma das características mais 'pointless' desse processo, uma vez que testes não substituem e nem ao menos complementam uma especificação e vice versa. Acredito que há artigos pela internet falando sobre isso, apenas não lembro de um para citar neste momento em que escrevo.

Por acaso, esse tema levantado em seu gist abrange boa parte da apresentação que vou fazer no #BrazilJS sobre testes em FrontEnd e vou aproveitar o texto para usar como inspiração assim como a discussão boa que deve vir por aí.

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

Claro q vc pode escrever um bom código sem isso, mas vc vai deixar de usar porq?!
Essas técnicas não são muletas para ajudar quem não consegue desenvolver direito, mas ferramentas q vão ajudar qualquer um a programar melhor, da mesma forma q um bom editor de código vai ajudar.

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

A questão do DDD é vc ter um código q representa o seu dominio de negocios... então quanto mais proximo o seu codigo estiver do dominio.. mas proximo vc vai estar do DDD e sua comunicação será melhor com quem sabe o dominio. Não vejo porq não fazer...

"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!"

A questão é q essas técnicas não são muletas... é o mesmo q falar q bons corredores não deveriam usar tênis... mas sapatos porq se eles forem bons corredores não precisaram do tênis.

Porcelli, BDD não tem quase nada a ver com criar algoritmos. Vou responder lá no post do Elemar...

@ericvieira: sobre o seu primeiro parágrafo, entenda que o comentário foi questionando a necessidade do processo, e não sobre a ferramenta em si.

Processos /?DD/ não são infalíveis, assim como não são obrigações. Padrões não são necessariamente regras, muitas vezes podemos definir eles como identificação de repetições similares. Como exemplo é possível citar algo bem simples como as ondas de uma frequência, elas seguem um padrão.

Sobre o DDD, é a mesma questão que falei sobre BDD, ou seja, IMO, testes automatizados não são lugar de especificação de projeto, em casos assim, um impede o outro de se tornar 100% completo, eficaz e prático.

Disclaimer: Tl,dr;

Já que abriu a discussão...

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.

É exatamente isto o que se aprendia a fazer nos antigos cursos de análise de sistemas (que eu não fiz mas aprendi nos livros).

Quando desenvolvi um sistema completo de gestão, eu não conhecia nada de gestão de empresa. Mal sabia o que era uma duplicata. Não tinha a menor ideia do que deveria ir para um livro fiscal. Fui contratado justamente porque alguém confiou na minha capacidade de extrair informações de quem tinha este conhecimento e automatizar via um sistema.

Repeti e repito até hoje esta experiência de sistematizar resolução de problemas sobre os quais algumas vezes nem sabia que existiam.

Sobre DDD...

Sobre DDD, que inclui diversos conceitos, alguns até um pouco óbvios, acho que vale mais por uma questão de ordenar o raciocínio ou clarear as idéias. É assim que entendo as questões de estratégia. A visão de domínios, sub domínios, os bounded contexts e outras coisas mais. Isto justamente ajuda a não ter camadas desnecessárias, ao contrário que o texto do Porcelli deixa transparecer.

Uma outra coisa óbvia mas ao meu ver super importante é justamente o conceito de linguagem ubícua. No último projeto em que participei codando, a equipe (de railers) nunca tinha ouvido falar nisto e simplesmente repetiu o erro de usar vários nomes para a mesma coisa. A gente tinha que olhar um diagrama e fazer traduções mentais entre o linguajar do cliente e o que ia para o código. Na época muito me surpreendeu ver tanta gente que nunca tinha ouvido falar de DDD.

Sobre TDD (e BDD que acho razoavelmente bom em algumas circunstâncias e com algumas linguagens)

Sobre TDD e BDD concordo que é verdade que muitos softwares que uso ou usei não foram feitos assim. Dizem que o código do OSX nem tem testes.

E eu mesmo já fiz muitos sistemas bem complexos sem teste algum (além dos "passei por aqui"). Para quem não sabe, eu participei do desenvolvimento de sistemas de CAE e CAD. E quem conhece um tiquinho desta área sabe que são milhares de vezes mais complexos do que 99,9999% das aplicações web. Não foi a toa que um destes sistemas levou 5 anos para ser desenvolvido e custou mais de 5 milhões de dólares (antes de ser jogado no lixo).

Porém, são justamente os sisteminhas web que mais precisam de testes, de TDD e de BDD. Vou separar BDD porque só senti necessidade com Ruby. Com Java acho desnecessário.

O modo de desenvolver fazendo o teste antes na verdade posso dizer que desde sempre fiz assim. Toda vez que ia desenvolver uma algoritmo muito complexo, muitas e muitas vezes fazia pequenas partes do sistema totalmente independentes só para testar os algoritmos. Se alguém acha que isto não é TDD, ainda insisto dizendo que fazia isto também em diversos segmentos do sistema como prova de conceito antes de escrever a proposta comercial de desenvolvimento de algum software. Então escrever o teste antes não é nenhuma novidade.

A prática de testes unitários também é coisa bem antiga, muito antes da criação dos xUnits. Só que dava um pouco mais de trabalho e exigia programar de forma bem modular (a tal metodologia de programação modular como recomendava o velho Niklaus Wirth, o criador do Pascal).

Enfim... finalizando...

Entendo tudo isso como ferramentas. Não são pernas engessadas. Não são processos restritivos. A criatividade está nos algoritmos e o que fazemos para eles darem certo. Como disse, testar separadamente os algoritmos sempre fez parte da minha habilidade artesanal ou da minha arte de fazê-los funcionar.

Uma coisa eu sempre disse. E já dizia desde quando dei aulas de linguagem de programação ainda nos anos 70. Um bom programador se reconhece por sua caixa de ferramentas. Estas ferramentas podem ser o tanto que ele conhece de estruturas de dados ou de quantas APIs ele sabe usar. Sempre me considerei um proxi entre os livros que lia e os problemas que resolvia para os clientes. Dizia que pelo menos sabia onde buscar o conhecimento para asfaltar o caminho até a solução. E chamava isto de minha caixa de ferramentas.

Quer um exemplo? Com muito esforço desenvolvi em Fortran (totalmente imprópria para lidar com textos), uma linguagem para entrada de dados de sistemas de cálculo estrutural. Na época não sabia nada de parsers (fora os conceitos da notação BNF trazidos pelo Algol). Mas usando IFs e GOTOs, a minha linguagem funcionava direitinho e os engenheiros que usavam meu sistema podiam entrar os dados como se escrevessem um arquivo texto em formato livre. Ah se tivesse um Antlr na minha caixa de ferramentas...

Saber usar TDD, (BDD para linguagens que exigem muitos testes como Ruby), conhecer DDD, entender de SEO, saber como carregar as páginas de forma rápida, saber como ter certeza de que o sistema está pronto para sair do desenvolvimento para a produção em menos tempo (aqui brilham testes, integração continua e deploy automatizado), saber como conversar com o cliente e entender o que ele quer, (ponha aqui um monte de qualidades pessoais que muitos nerds não tem, não se esforçam para ter e por isso não passam de code monkeys), etc.. Tudo isto são muletas ou tênis amortecidos como brilhantemente comparou o Eric Vieira.

É isso. Nem sempre todas são necessárias. Mas é bom saber que elas existem e que podem nos ajudar em algum momento.

PS: Metodologias sempre foram importantes. É bom conhecer um pouco da história e ver como evoluiram. Praticamente ditaram a evolução das linguagens de programação. Programação estruturada, programação modular, orientação a objeto são metodologias antigas que até hoje alguns insistem em não adotar mesmo usando linguagens orientadas a objeto. Eu sempre optei por ficar de olhos abertos quando surgia alguma novidade

Abraços

ERRATA:

Suprimir o fim da frase em que está escrito "ao contrário que o texto do Porcelli deixa transparecer." porque justamente o texto do Porcelli diz ao contrário na frase "em geral visando minimizar ruídos (camadas excedentes) e facilitar a comunicação e assertividade do resultado final."

Importante esta correção porque ficou como uma coisa sem ter nada a ver com o texto original.

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!