XP, TDD e vibe coding: tradução de trechos da entrevista de Kent Beck ao Programmatic Engineer
(stdy.blog)- Resumo de alguns trechos que mais me impressionaram na entrevista de Kent Beck ao Programmatic Engineer, o pai do XP e do TDD
- Para quem gosta de Kent Beck, recomendo assistir ao vídeo completo
P. Qual é o núcleo do XP?
É fazer as quatro atividades abaixo.
- Entender o que precisa ser feito
- Entender a estrutura que nos permite fazer o item 1
- Implementar o item 1 usando o item 2
- Verificar se o item 3 funciona como esperado
É só isso. E dividir o tempo em pedaços bem pequenos, fazendo um pouco das quatro atividades em cada intervalo, mas fazendo todas elas.
P. Então programação em par não é obrigatória no XP?
Quando eu estava liderando meu primeiro time de XP, fazíamos deploy a cada 3 semanas e, claro, havia bugs.
Quando analisei os padrões dos bugs que eram descobertos depois do deploy, todos eles vinham de código desenvolvido sozinho. Em outras palavras, no código desenvolvido em par não havia defeitos reportados em produção.
P. Então não é obrigatório, mas seria algo fortemente recomendado?
Também não. O ponto é experimentar. Você pode continuar desenvolvendo como sempre desenvolveu. Só que de forma consciente.
Quer obter os benefícios de design contínuo, verificação contínua, implementação contínua, ou interação contínua com o cliente, seja lá o que for? Mas continua fazendo do jeito de sempre e não funciona? Então é preciso mudar a forma de trabalhar.
Se alguém chega para mim e diz: "Kent, eu não faço TDD.", eu respondo assim: "E daí?"
Se você está satisfeito com a densidade de defeitos no seu código atual e com o nível de feedback sobre suas decisões de design, então tudo bem. Mas, se não está satisfeito, tente programação em par, TDD, ou qualquer outra coisa.
P. Já que tocamos no assunto, por que você criou o TDD?
Eu sou uma pessoa muito preocupada e ansiosa, e para mim programar era uma fonte constante de ansiedade. O que foi que eu esqueci? O que foi que eu quebrei?
Mas, quando desenvolvo com TDD, essa ansiedade desaparece. Não consigo pensar em mais nenhum caso de teste que possa falhar? Então posso ter confiança de que meu programa funciona. Apareceu o menor sinal de ansiedade? É só escrever o próximo caso de teste.
Claro, há muitos benefícios técnicos no TDD, como reduzir a densidade de defeitos, obter feedback mais rápido sobre decisões de design e evoluir o design da implementação. Mas, para mim, o mais importante é ter me libertado da ansiedade em relação à programação, o fato de a experiência emocional de programar ter mudado completamente. Foi por isso que eu criei o TDD.
P. O que você pensa sobre a crítica de John Ousterhout de que, com TDD, não sobra espaço para um bom design entrar?
(Nota do tradutor: John Ousterhout é o autor do clássico Philosophy of Software Design e, há alguns meses, apareceu no podcast Programmatic Engineer apresentando uma visão crítica sobre TDD.)
Há um ponto que ele entendeu mal. Isso é simplesmente resultado de uma decisão. Se você tratar TDD apenas como uma repetição de Red-Green, então, é claro, realmente não haverá espaço para design.
Como praticante de TDD, eu estou sempre alternando entre diferentes níveis de abstração. Por exemplo:
- Agora estou no estado Red. Como devo implementar isso para fazer o próximo caso de teste passar, ou seja, ficar Green?
- Isso está difícil. Por que está difícil?
- Como devo mudar o design para tornar mais fácil a implementação necessária para chegar ao Green?
- Quando devo introduzir essa ideia? Agora ou depois?
- Se eu introduzir agora, em que medida? Faço só um pouco, o mínimo possível neste momento, ou em um bloco maior?
Ou seja, antes de escrever o teste, eu sempre tenho um momento de design.
Antes de implementar, tomo decisões sobre a interface, crio um teste Red e, como eu não gosto de ficar em Red, levo para Green o mais rápido possível. Depois que fica Green, a ansiedade some por um momento e eu ganho espaço para pensar. "Hum, isso passa, mas em outros casos não vai funcionar. Preciso generalizar mais a implementação."
Está em Red? Eu levo para Green. Está em Green? Respiro e penso. Esse é o meu ciclo de TDD.
P. Às vezes a implementação me parece tão óbvia que eu implemento primeiro e só depois faço o teste Red-Green. O que você acha dessa abordagem?
Provavelmente porque você está assumindo que "essa forma de implementar está correta" e, quanto mais certa estiver essa suposição, menor será, naturalmente, a vantagem de escrever o teste primeiro.
Mas eu sempre penso assim: "Eu vou continuar aprendendo e ganhando experiência, e este é o momento em que eu sei menos."
Ou seja, eu assumo que vou continuar aprendendo e que a situação vai mudar. Quanto mais eu precisar aprender e quanto mais as circunstâncias mudarem, mais eu quero adiar decisões o máximo possível. Esse é um princípio geral. Vale para encontros, vale para cozinhar, vale para tudo.
Se você consegue prever mais, pode dar saltos maiores. Mas o momento que eu mais amo na programação é quando estou avançando achando que já entendi tudo e, de repente, percebo que havia uma forma muito melhor de implementar aquilo. Eu quero viver esse momento o máximo de vezes possível. É por isso que faço TDD.
Se você tem uma imagem bem clara na cabeça e consegue ter certeza de que certa entrada vai produzir certa saída, então pode simplesmente implementar. Mas, quanto mais você erra, quanto mais aprende e quanto mais o mundo muda de forma imprevisível, mais vantajoso é não se comprometer agora e deixar para depois.
P. Ao programar com IA, você ainda desenvolve com TDD como antes?
Não é fácil responder de forma simples.
Eu uso testes como meio de comunicação com a IA, principalmente como uma forma de dizer à IA no que ela errou. Esse sujeito vive tentando apagar e modificar meus testes, e toda vez eu dou bronca. Meus testes estão certos, então faça direito.
A IA frequentemente toma decisões ruins no longo prazo. Ela também é realmente ruim em reduzir acoplamento e aumentar coesão. Às vezes consegue, se você disser com muita clareza o que precisa ser feito, mas, no geral, é melhor assumir que ela não projeta bem.
Por isso eu preparo uma quantidade enorme de testes. Eu os uso como meio de detectar se a IA está quebrando alguma coisa.
(Nota do tradutor: para ver como Kent Beck usa TDD em vibe coding, consulte este texto.)
P. Parece que seria mais conveniente se regras de agente como “nunca mexa nos testes” e “se os testes não passarem, continue alterando apenas o código de implementação até passarem” se popularizassem. Também dá a sensação de que estamos redescobrindo coisas que eram importantes nos anos 2000. O que você acha?
Temos que continuar experimentando. Precisamos tentar tudo o que for possível. Porque não sabemos o que realmente é melhor neste momento.
O horizonte do que é "barato" e do que é "caro" mudou completamente. Muitas coisas que antes não fazíamos por serem caras ou difíceis ficaram absurdamente baratas.
Se, de repente, carros passassem a ser grátis de um dia para o outro, o que você acha que aconteceria? É óbvio que alguma coisa mudaria, mas quais seriam as mudanças de segunda e terceira ordem? Ninguém consegue prever. Então, por enquanto, não há alternativa além de tentar várias coisas.
P. Você disse que, mesmo depois de mais de 50 anos programando, está se divertindo mais agora do que nunca. O que isso quer dizer?
Tornar reais as minhas grandes ideias ficou mais fácil do que em qualquer outro momento. Observar se a IA consegue implementar essa ideia, e ajustar o processo de como ela vai implementá-la, é incrivelmente viciante. Como nunca se sabe direito quando vai dar certo, e quando dá certo parece mágica, é parecido com uma caça-níquel. Estou sempre tomado pela tentação de deixar pelo menos um prompt antes de sair para caminhar ou almoçar, só para não deixar esse sujeito parado.
Dois anos atrás, eu publiquei o seguinte tweet: "Eu estava relutante em experimentar o ChatGPT, mas hoje superei essa relutância. Agora entendo por que eu estava relutante. 90% das minhas habilidades agora valem $0. E a alavancagem dos 10% restantes aumentou 1000x. Está na hora de me recalibrar."
I've been reluctant to try ChatGPT. Today I got over that reluctance. Now I understand why I was reluctant.
The value of 90% of my skills just dropped to $0. The leverage for the remaining 10% went up 1000x. I need to recalibrate.
-- Kent Beck 🌻 (@KentBeck) April 18, 2023
(Nota do tradutor: quando esse tweet repercutiu, Kent também publicou um texto um pouco mais longo.)
Na época, eu dizia que ainda estava explorando o que eram esses 90% e esses 10%, mas agora já consigo responder em certa medida. A capacidade de ter uma visão ousada, definir marcos rumo a essa visão, continuar ajustando o design enquanto avança e controlar a complexidade. Isso é muito, muito mais importante do que conhecimento da sintaxe de uma linguagem específica, como saber onde colocar &, * ou [ em Rust.
Ainda não há comentários.