Você já herdou um código legado? Por que isso é tão traumático? Porque, infelizmente, no mundo corporativo não conseguimos viver no mundo ideal onde todo software foi bem arquitetado antes de começar a ser desenvolvido. Isso pode acontecer por vários motivos mas o principal é a tal falta de tempo. O que nem todo mundo consegue enxergar é que dedicar algumas horas para arquitetar, planejar um software antes de começar a digitar códigos desvairadamente, fazer a modelagem correta e bem pensada, pode diminuir e muito o tempo total de desenvolvimento da aplicação.

Provavelmente você já escutou de algum gerente de projeto que o comercial precisou cortar algumas horas do projeto para que o cliente pudesse fechar o contrato. Bem, a verdade é que essa tal “mágica” extrai um tempo precioso de planejamento e pular essa etapa sempre (sim, sempre!) é prejudicial para o desenvolvimento. “Ah! Você está sendo muito exagerada!”, você deve estar pensando.

Vamos a um exemplo clássico: uma manutenção em Usuário com Endereço. Foi solicitado que fosse desenvolvido um cadastro de Usuário com Endereço. Pulamos a parte de planejamento e metemos a mão na massa (nós, desenvolvedores, temos essa fome de escrever código hehehe). Um pouco mais a frente, verificou-se a necessidade do Usuário ter mais de um endereço. Agora teremos que parar para repensar na modelagem de classes que fizemos, sem contar na gambiarra no Banco de Dados se não tivermos utilizado um ORM ( (Object-Relational Mapping ), que poupa um baita trabalho. Só aí podemos identificar dois pontos que teremos que “perder tempo” para consertar.

Outro exemplo: começamos a codificar e nem lembramos da nossa amiga OOP (Object Oriented Programming). Domínios ricos passaram longe. Aí, um belo dia, precisamos refatorar uma parte do código pois foi verificado que não atende de maneira correta a regra de negócio ou foi necessário alterar a regra de negócio. Agora vamos “perder mais um tempo” para mapearmos todos os lugares em que aquela bendita regra de negócio é utilizada. Bem, conseguimos mapear todos os pontos! Ufa!!! Vamos testar? O analista de testes percebe que as regras de negócio não foram totalmente cobertas e volta o nosso código para o desenvolvimento e percebemos que os pontos que ficaram descobertos poderiam ser mapeados com testes unitários mas não pensamos nisso antes e nossas classes são estáticas. E agora? Bem, agora perderemos um tempão!

Estes são apenas alguns exemplos simples do nosso dia-a-dia mas que mostram a importância de não pularmos a etapa de planejamento de um software. Nada está acima de mudanças, muito menos nosso software e ele precisa estar preparado para isso.

No responses yet

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *