Um sistema pode durar 5, 10 ou mesmo 20 anos. Mas a vida de algumas linhas específicas do código muitas vezes é bem mais curta: meses ou dias, ou mesmo minutos, quando você está realizando alterações através de diferentes abordagens para uma mesma solução.

Alguns códigos são mais importante do que outros

Pesquisando a forma como são feitas as alterações de código ao longo do tempo, Michael Feathers identificou uma curva de potência em bases de código. Cada sistema tem seu código, um monte deles, que foram escritos uma vez e nunca foram alterados. Mas uma pequena quantidade de código, incluindo aquele que é mais importante e útil, é alterada uma ou outra vez, reformulada ou reescrita várias vezes.

À medida que você obtém mais experiência com um determinado sistema, com o domínio de um problema ou com a abordagem de arquitetura, deve ficar mais fácil prever qual código vai mudar o tempo todo, e qual código nunca vai mudar: quais códigos são importantes e quais não são.

Devemos tentar escrever o código perfeito?

Sabemos que devemos escrever um código limpo, e é claro que código que é consistente deve ser tão simples quanto possível.

Algumas pessoas levam isso a extremos, e se obrigam a escrever um código tão bonito e elegante, em busca de uma perfeição que pode atingir o extremo da obsessiva refatoração na qual o desenvolvedor agoniza sobre cada detalhe.

Mas se o código só vai ser escrito uma vez e nunca mudou, ou, se no outro extremo, o código está mudando o tempo todo, escrever um código perfeito acaba sendo um desperdício desnecessário (e impossível de conseguir) como tentar escrever requisitos perfeitos ou tentar chegar a um design de tela perfeito?

Você não pode escrever um software perfeito. Isso te feriu? Pois não deveria. Aceite isso como um axioma da vida. Software perfeito não existe. Ninguém na breve história da computação já escreveu um pedaço de software considerado perfeito. É improvável que você seja o primeiro. E a menos que você aceite isso como um fato, vai acabar perdendo tempo e energia perseguindo um sonho impossível. Andrew Hunt, The Pragmatic Programmer.

O código que é escrito uma vez não precisa ser bonito e elegante. Tem que ser correto. Tem que ser compreensível – porque código que nunca foi alterado ainda pode ser lido muitas vezes durante a vida útil do sistema. Ele não tem que ser limpo e lustroso, apenas limpo o suficiente para ser copiado e colado, e outros atalhos nesse código podem ser permitido, pelo menos até certo ponto. Esse é o código que nunca precisará ser polido. Esse é o código que não precisa ser reformulado (ao menos até que você precise mudar isso), mesmo que outro código ao seu redor esteja mudando. Esse é o código que não vale a pena gastar tempo extra tornando-o bonito.

E sobre o código que está sendo modificado o tempo todo? Agonizar sobre estilo de construção do código e procurar uma solução mais elegante é um desperdício de tempo, porque esse código provavelmente será alterado novamente e talvez até reescrito em poucos dias ou semanas. E assim é a obsessiva refatoração de código. Cada vez que você faz uma alteração, faz uma refatoração de código, pensando que ele poderia ser melhor. Código sempre pode ser melhor. Mas isso não é importante.

O que importa é: será que o código faz o que deve fazer – é correto, utilizável e eficiente? Ele pode lidar com erros e dados ruins sem parar de funcionar – ou pelo menos irá deixar de funcionar com segurança? É fácil de depurar? É fácil e seguro de modificar? Estes não são aspectos subjetivos da beleza do código. São medidas práticas que fazem a diferença entre o sucesso e o fracasso.

Programação pragmática e refatoração

A ideia central do Desenvolvimento Lean é: não perca tempo com coisas que não são importantes. Isso deve informar como devemos escrever código e como devemos refatorá-lo, revisá-lo e, por fim, como podemos testá-lo.

Apenas refatorar o que for preciso, a fim de fazer o trabalho que Martin Fowler chama de refatoração oportunista (compreensão, limpeza, regra de Boy Scout etc.) e refatoração preparatória. O suficiente para fazer uma mudança mais fácil e segura, nada mais. Se você não está modificando o código, realmente não importa como ele se parece.

Em revisões de código, concentre-se apenas no que é importante. O código está correto? É seguro?

Esqueça o estilo (a menos que o estilo fique no caminho da compreensibilidade do código). Deixe seu IDE cuidar da formatação. Não há argumentos sobre se o código poderia ser “mais OO”. Não importa se ele segue corretamente este ou aquele padrão, desde que isso faça sentido. Não importa se você gosta ou não. Se poderia ter feito isso de uma maneira mais agradável não é importante – a menos que você esteja ensinando algum novato a utilizar a plataforma e a desenvolver na linguagem, e espera-se que você faça um tipo de análise como parte da revisão de código.

Escreva testes que importam. Os testes que abrangem os principais caminhos e os casos de exceção importantes. Os testes que retornarão o máximo de informação e as mais confiáveis, com a menor quantidade de trabalho.

Não é (apenas) sobre o código

As metáforas de arquitetura e engenharia nunca foram válidas para o software. Não estamos criando pontes ou arranha-céus que vão ficar no mesmo lugar por anos ou gerações. Estamos construindo algo muito mais abstrato e mais efêmero. O código é escrito para ser mudado – é por isso que é chamado de “software”.

“Depois de cinco anos de uso e modificação, a fonte de um programa de software de sucesso estará completamente irreconhecível de sua forma original, enquanto um edifício bem sucedido após cinco anos está praticamente intocado”. Kevin Tate, Desenvolvimento de Software Sustentável

Nós precisamos olhar para o código como um artefato temporário do nosso trabalho:

“…Somos levados a embelezar o código, às vezes às custas de coisas mais importantes. Muitas vezes sofremos sob a ilusão de que a coisa mais valiosa produzida na entrega de um produto é o código, quando se pode realmente ser um entendimento do domínio do problema, o progresso em enigmas design, ou até mesmo o feedback de nossos clientes”. Dan Grover, Código e Destruição criativa

O desenvolvimento iterativo nos ensina a experimentar e analisar os resultados do nosso trabalho – se vamos resolver o problema, se não vamos, o que aprendemos, como podemos melhorar? O software que estamos construindo não é “terminado” nunca. Mesmo que o projeto e o código estejam finalizados, isso durará apenas algum tempo, até que as circunstâncias exijam que tudo seja novamente alterado ou substituído por algo que se encaixe melhor.

Precisamos escrever bons códigos: código que seja compreensível, correto e seguro. Precisamos refatorá-lo, revisá-lo e escrever bons testes, sabendo o tempo todo que alguns trechos desse código, ou talvez todo o código, poderão ser jogados fora em breve. Temos que reconhecer que alguns dos nossos trabalhos serão necessariamente desperdiçados e otimizar nosso tempo pensando nisso. Faça o que precisa ser feito e nada mais. Não perca tempo tentando escrever o código perfeito.

***

Artigo traduzido pela Redação iMasters, com autorização do autor. Publicado originalmente em http://swreflections.blogspot.com.br/2014/11/dont-waste-time-writing-perfect-code.html