Rodrigo Strauss :: Blog

Minha política para manutenção de programas

Ouço muitos programadores dizendo coisas como "esse código está horrível, vou refazer" ou "não consigo entender nada do que aquele cara escreveu, acho mais fácil fazer de novo". Quanto mais experiência e mais tempo de mercado eu tenho, mais essas frases me soam infantis e pouco profissionais. Eu já disse essas coisas várias vezes e ainda digo as vezes, mas não muda minha visão sobre o assunto.

Quando não se entende o código, na maioria das vezes o programador que tenta entender já faz o serviço com má vontade, e acaba encontrando alguma desculpa para justificar sua proposta: gastar tempo refazendo algo que está pronto e funciona, só porque ele diz que não consegue entender o que foi feito. Nem vou discutir a duvidosa capacidade do programador, mas uma coisa me vem: se você não entende o que está feito, como pode refazer? Você pode até conhecer quais os valores de entrada produzem quais saídas, mas sem entender o que está feito é muito difícil manter a compatibilidade e o comportamento do código anterior. É importante lembrar: o usuário não vê código fonte. Se você gastar um tempão refazendo uma parte do sistema e ela não ficar exatamente igual ou melhor do que o que estava funcionando anteriormente, como você justifica? Agora o fonte está muito melhor e mais legível, mas não funciona como o usuário espera. Não é para ele que o sistema foi feito? Uma coisa que faz muitos programadores suarem frio é, por exemplo, dar manutenção em um código cujo padrão de nomenclatura ele não concorda e não gosta. Concordo que é horrível, mas faz parte do trabalho e é necessário um pouco de profissionalismo nessa hora.

Refazer código não é algo necessariamente ruim, apesar de ser ruim na maioria das vezes (o próprio Joel já falou sobre isso). Você precisa ter um motivo muito bom para mudar algo que está funcionando. O fonte está feio? Não se esqueça que seu estilo de codificação pode ser feio para outras pessoas. Refazer uma parte do programa é uma tarefa custosa em termos financeiros e em termos de estabilidade, já que você troca um coisa feia, horrível e porca mas que funciona por algo lindo, maravilhoso e moderno que nunca foi testado. Eu tenho até um metáfora para isso: Um sistema remendado é como um barco antigo cheio de durepox nos buracos. Ele pode ser um pouco lento e pesado, mas depois de tapar tantos furos, ele navega. Um sistema novo é como um barco novo e bonito. Pode ter seus buracos da mesma forma, mas como nunca foi usado, ele pode ainda rachar no meio a qualquer momento.

Algumas vezes refazer é necessário, mas a parte refeita do sistema é como uma parte nova, precisa ser muito bem testada. Por isso que hoje em dia se fala tanto em refactoring e unit testing, que prega algo como "não jogue fora o que você tem, reorganize e melhore de forma progressiva e garantindo que as melhorias feitas não criarão problemas ou incompatibilidades".

Eu sei que com esse post parece que estou saindo do lado técnico e mudando para o lado gerencial, mas não é isso. Como técnico me compete manter o sistema funcionando, e tudo isso que eu escrevi é sobre análise de risco e sobre a prioridade de manter tudo funcionando. Qualquer mudança no sistema exige uma boa análise de risco, e uma parte refeita mais ainda. Quando você cria um recurso novo no sistema, muitas vezes o usuário não sabe o que esperar, ele sabe que algumas adaptações serão necessárias. Quando você refaz alguma coisa, ele sabe exatamente o que esperar, ele usa isso no dia a dia. Mudando isso você cria aquela situação extremamente irritante de "isso estava funcionando, por que você foi mexer?".

Se você, como todo programador normal, tem vontade de experimentar tecnologias em versão alfa, coisas novíssimas e moderníssimas e refazer coisas, comece um projeto open source. Vai ser melhor para você (liberdade total e talvez mais usuários do que o sistema que você faz na empresa) e para seu projeto (estabilidade).

Em 27/06/2007 19:06, por Rodrigo Strauss

Comentários