Olá Habr!
Trago a sua atenção uma tradução do artigo "
Simple Hickey ", de Robert C. Martin (tio Bob).
Rich Hickey proferiu uma excelente palestra sobre Strange Loop, intitulada Simples, Fácil. Eu recomendo que você gaste uma hora ouvindo. Esse desempenho vale cada segundo.
Haverá algumas coisas nesta palestra com as quais você não concorda. Quando isso acontece, pare e pense - pense seriamente - você realmente discorda. Talvez você não deva pensar que é assim.
Por exemplo, Rich diz algumas coisas aparentemente desdenhosas sobre TDD e Agile and Refactoring, as vacas sagradas da Comunidade Agile. Se você está comprometido com esta comunidade, pode reagir negativamente. Não precisa. Rich não negligencia a prática. Ele negligencia a religião - imprudência - frivolidade.
Rich compara testes de unidade com trilhos de segurança. Então ele faz um argumento muito bom. Ele diz que quando você tem um erro, esse erro passa nos testes. E agora o que? Agora você deve encontrar o erro. E se o sistema não for simples, não será fácil. (Observe que usei as palavras aqui de maneira simples e fácil. O início do discurso de Rich está conectado a diferentes definições que essas palavras têm. Sugiro que você pare neste local e ouça os dez primeiros minutos do discurso e depois volte a este parágrafo.)
Rich enfatiza que os velocistas correm rápido, mas não por muito tempo. Ele então diz que o Agile "resolveu" esse problema simplesmente disparando a pistola de partida várias vezes em rápida sucessão. Ele sorri e a platéia ri. Ele então continua dizendo que o sprint contínuo não necessariamente torna os sistemas simples, e a simplicidade é a chave da velocidade.
Claro que ele está certo. Martin Fowler falou sobre isso em seu artigo "Flaccid Scrum". E é isso que muitos de nós da comunidade Agile expressamos. Essas iterações curtas, sem boas práticas técnicas, não levam ao desenvolvimento rápido. Pelo contrário, leva a uma bagunça.
Rich ri da idéia de que um conjunto de testes permitirá que você altere o código. Ele diz que os testes são uma rede de segurança, nada mais. Nós, TDD, sabemos que um conjunto de testes é necessário se quisermos alterar o código sem medo. Mas Rich está certo sobre a rede de segurança. Um sistema de segurança pode ajudá-lo a simplificar seu sistema, se ele já é simples. Mas um sistema de segurança sob uma grande quantidade de terra terá pouca ajuda para desvendar a bagunça. Oh, não me interpretem mal. Eu preciso desses testes! Mas o trabalho não será fácil. (novamente esta palavra).
Aqui está outra palestra de Rich: Hammock Driven Development, na qual ele nos encoraja a pensar, e não apenas escrever partes e partes de código.
Então aqui está. Rich está preocupado, e com razão, que tenhamos uma cultura complexa. Quando uma tarefa é definida para os programadores, eles avançam e escrevem muitos códigos confusos, usando estruturas e ferramentas "simples", sem dar significado adequado ao problema. O que confundimos leveza com simplicidade. (Por exemplo, o Rails é fácil, mas não é fácil.) Sua reclamação sobre os testes é que os usamos para substituir pensamentos. O que é bom para nós, porque escrevemos os testes, mas na verdade não gastamos tempo suficiente com o problema que ele merece. Não simplificamos o problema. Acabamos de fazer o que foi fácil.
Portanto, na verdade, a comunidade Agile e toda a comunidade de software estão infectadas com esta doença. Muitas vezes fazemos o que é fácil, devido ao que é simples. E assim fazemos uma bagunça. Mas esse não é o valor da agilidade agora e nunca será. E isso, é claro, não é o valor do domínio do software! De fato, fazer o que é simples, ao contrário do que é fácil, é uma das características definidoras de um assistente de software.
No final, acho que a percepção de TDD de Rich é distorcida pelo que ele vê no setor. Sinceramente, acho que ele perdeu alguns detalhes. E acho que ele entenderia que essa prática seria tão útil para ele quanto para mim. Não como uma maneira de evitar pensar e se jogar numa bagunça, mas como uma maneira disciplinada de ser detalhado, cuidadoso e atencioso.
Agora pergunte a si mesmo o que TDD significa para você. O TDD é a disciplina que você usa para facilitar as coisas? Ou é uma disciplina que você usa para ser atencioso, cuidadoso e não complicar?