Quem nunca fez uma burrada no código simplesmente porque não pensou no que ia fazer antes de começar a fazer?

Temos uma tendência enorme a simplesmente começar a fazer a coisa sem pensar exatamente em como que aquilo vai ser feito. Não é incomum você sentar na frente do computador e sair digitando código e ir tentando, e descobrindo o que fazer (descobrir detalhes on-the-fly é normal, o anormal é não ter nem direção certa).

Sabemos que isso é verdade, mas como evitar? No meu ponto de vista, individualmente, a única solução é primeiro pensar e depois codificar, não tem para onde correr! Porém, acredito que algumas técnicas que trazem outros benefícios, também ajudam a resolver esse problema específico de cuspir código sem pensar. Queria falar especificamente de duas técnicas, que sairam do eXtreme Programming. A primeira delas é Pair Programming, e a segunda delas é o TDD. Irei em breve escrever um post mais detalhado sobre as duas técnicas, mas por hora gostaria somente de apontar o que são, e como ajudam nessa questão de primeiro raciocinar pra depois codificar.

Pair programming é a prática de programar a 4 mãos… ou melhor, a 2 cabeças pensantes, mas somente 2 mãos. A idéia é sentar em pares em um único computador, e os dois codificarem juntos. Obviamente os benefícios disso são muitos: a atenção sobre o que está sendo feito é dobrada, um precisa estar dizendo ao outro o que está fazendo, ou pensando em fazer (e com isso já pensamos antes de fazer), funciona como uma revisão de código instantânea (pois ainda não está nem terminado e o seu par já identifica pontos que podem ser diferentes ou melhores), etc, etc….

TDD ( test driven development) por sua vez, trata de sempre testar o que você quer fazer antes mesmo de ter feito. A idéia mais uma vez é pensar no que vai fazer, antes de fazer. Nesse caso é necessário pensar em como você vai testar o código que ainda vai ser construído (por você) e nesse processo de pensar em como vai testar, você provavelmente vai descrobrir como vai codificar. É claro que além desse benefício, você tem outros ainda mais importantes que é a questão de todo o seu código desenvolvido ter teste (automatizado/unitário) que testa aquele código, garantindo ainda mais sua qualidade. E, tendo essa suíte de testes que garantem que meu código está realmente fazendo o que tem que ser feito, eu posso mudar meu código mais tranquilamente meu código pois sei que meus testes unitários (criados utilizando a técnica do TDD) vão atestar minha mudança. Isso dá subsídio para outras práticas (MUITO)importantes como Design Evolutivo e Refactoring.