logo
Contato | Sobre...        
rebarba rebarba

Rodrigo Strauss :: Blog

follow us in feedly

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
Israel Aece | website | e-mail | em 27/06/2007 | #
Boas Rodrigo,

Logo quando comecei a programar eu me enquadrava nesta situação. Hoje, eu tento ter uma visão mais profissional, justamente, para não deparar com os problemas que você já citou.

A atitude que você descreveu acima é bastante elegante!
Thiago Brito | website | e-mail | em 27/06/2007 | #
Quando eu vou refazer um código, eu realmente procuro me cercar do maior número de testes possíveis (todos automatizados) e dividir o código em vários pedaços (por função, por classe ou por funcionalidade... quanto menor melhor).

Com testes bem feitos é mais fácil de fazer um bom refactoring e melhorar o código como um todo.

Mas como você mesmo disse, sair mudando tudo que você acha que é "feio" seja pq vc fez o codigo a anos atrás ou pq foi outra pessoa quem criou, é melhor pensar duas vezes e analisar se isso é realmente necessário.

Muito interessante o post.
Francismar A. Silva | website | em 28/06/2007 | #
"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".

Com toda certeza este é caminho.
"Perder" algumas horas entendendo a codificação é melhor que dias e mais dias re-codificando.
Afinal, quem aqui tem tempo para isto? Qual é nosso maior vilão? Prazo!
(:

[ ]'s
Eduardo Miranda | website | em 28/06/2007 | #
Existe uma área cinza entre o que vale a penar refactorar e o que é perda de tempo.

Uma vez ouvi uma história de um RA (Refactor Anônimo) que passava à noite mudando nome de variável, statements, etc, que os colegas tinham escrito durante o dia!

No entanto, em alguns casos a mudança é necessária para a longevidade da aplicação. Para isto é necessário investir tempo em criar uma estrutura de testes e depois partir para o massacre (dependendo do código vai espirrar muito sangue).

É necessário avaliar o quanto aquele código terá que evoluir e quanto você gasta para dar manutenção.

Às vezes por causa da pressa você não faz o que tinha que ser feito ai acaba mais atarefado porque perde mais tempo na manutenção, o que acaba em um ciclo vicioso.
betha | em 10/09/2007 | #
oi adori seus artigos e fiquei muito interresada me add no seu msn pra gente conersar

obrigado des de ja
Algo a dizer?
Nome:


Site:


E-mail:


Escreva o número vinte e seis:


 Não mostre meu e-mail no site, não serve pra nada mesmo...

Comentário





Os comentários devem ser sobre assuntos relativos ao post, eu provavelmente apagarei comentários totalmente offtopic. Se quiser me enviar uma mensagem, use o formulário de contato. E não esqueça: isso é um site pessoal e eu me reservo o direito de apagar qualquer comentário ofensivo ou inapropriado.
rebarba rebarba
  ::::