Cuidado com Projetos Técnicos
Esse post foi traduzido automaticamente do inglês. Se você encontrar algum erro, por favor entre em contato.
Depois de trabalhar em TI por um tempo, uma coisa que percebi é que existe muito código legado por aí. Algumas empresas lidam melhor com isso do que outras, mas existem muitas razões pelas quais código se torna antigo e muito difícil de manter, tornando a tarefa de manter a base de código de uma organização atualizada bastante difícil.
Como todo problema precisa de uma solução, código legado vem de mãos dadas com projetos “técnicos”, onde o principal objetivo é reescrever uma aplicação (ou parte dela) em uma nova tecnologia, ou de uma forma “melhor.”
Existem diferentes razões para isso. Às vezes a empresa tradicionalmente desenvolveu coisas em uma tecnologia específica e desde então evoluiu, deixando para trás alguns sistemas que nunca foram atualizados. Às vezes o código original foi desenvolvido sem aspirações de longo prazo e se tornou mais útil do que o esperado, sobrevivendo anos rodando em produção, mas também com altos custos de manutenção e falta de eficiência.
Só deixando claro, eu concordo com a necessidade de aposentar código legado. Acredito que é melhor não criá-lo em primeiro lugar, mas uma vez que ele existe, algo precisa ser feito. No entanto, esse tipo de projeto vem com mais riscos do que o normal, e como o John uma vez me disse:
Qualquer projeto que começa com uma lista de tarefas técnicas não é um bom projeto.
Primeiro, como você sabe o que precisa ser entregue? Se algo chegou ao ponto de ser chamado de código legado, você pode ter certeza de que ficou alguns meses (ou anos!) sem ser devidamente mantido e evoluído. Nos tempos atuais, quaisquer necessidades de clientes que estavam sendo atendidas há alguns anos muito provavelmente não são mais atuais. Em outras palavras, se você está reescrevendo a mesma coisa novamente, definitivamente está escrevendo a coisa errada.
Além das questões de negócio, qualquer código legado que esteve presente em uma organização por um tempo razoável viveu na imaginação da maioria dos desenvolvedores por tempo suficiente para que todos tenham certeza de que sabem o que é necessário para desenvolvê-lo perfeitamente desta vez. E como em qualquer solução técnica que não tem objetivos de cliente no final, os times acabam girando em círculos e polindo a base de código repetidamente, até alcançarem a perfeição ou o dinheiro acabar (o que, infelizmente, geralmente acontece primeiro).
Mas como abordar isso sem focar nos problemas a serem resolvidos? Volte à origem e descubra qual problema você está tentando resolver. Depois encontre os clientes que se importam com ele e comece por aí. Não há nada de diferente de qualquer outro projeto voltado ao cliente que organizações entregam.
Cada linha de código deveria existir e ser mantida por uma razão, e se nenhuma razão puder ser encontrada, então ela pode muito bem ser deletada.