Trabalhando bem com sustentação de software

A sustentação (ou manutenção) de um sistema é a fase pós implantação, onde o cliente já faz uso do software. Esta é a fase mais longa no ciclo de vida de um software, e também uma das fases mais importantes. 

Neste artigo vamos falar sobre a importância da manutenção e manutenibilidade do código. Como você pode já ter ouvido em milhares de outros artigos, padrão de código, clean-code e tratamento de code smells aumentam a taxa de manutenibilidade do seu software, que nada mais é do que a facilidade de manutenção de seu sistema. É justamente este ponto que eu quero tratar hoje . 

As etapas de trabalho abaixo não são a receita perfeita e nem funcionarão para todos os tipos de defeitos, mas com pequenos ajustes, espero que seja possível resolver um grande percentual dos defeitos que lhe forem designados. 

Avaliação do defeito 

Um dos pontos mais importantes a ser avaliado quando se assume um defeito novo para corrigir é verificar se realmente trata-se de um defeito ou não. 

Um chamado aberto como defeito nem sempre será solucionado por uma codificação. Pode ser uma orientação ao solicitante, pois tratava-se apenas de uma configuração incorreta ou um entendimento equivocado da funcionalidade; ou uma alteração onde está sendo proposta uma mudança na funcionalidade que foi criada, que neste caso é uma manutenção evolutiva. 

As manutenções evolutivas demandam mais tempo para serem feitas, e também precisam ter os documentos de requisitos alterados, onde constarão as novas regras criadas. 

Uma vez classificado como um defeito realmente, vamos ao próximo passo. 

Localização do ponto defeituoso 

Este ponto é basicamente uma investigação que vai despertar o seu Sherlock Holmes interior.  

Lógico que a experiência no sistema ou módulo onde será investigado o defeito facilita bastante esta parte do trabalho, mas mesmo sem muita experiência, é possível conseguir um resultado satisfatório. 

• Reprodução do defeito: Tente reproduzir o defeito, utilizando uma base de desenvolvimento. Atente-se bem aos passos seguidos, pois detalhes fazem a diferença na hora de reproduzir o defeito. Caso não consiga, outros desenvolvedores mais experientes ou os analistas de testes podem ser grandes aliados neste momento. 
• Redução cenário: Depois de reproduzido o erro, tente diminuir os passos para a reprodução deste erro. Deixe o cenário o mais curto possível para diminuir a perda do foco na hora de debugar, quanto menor melhor. 
• Localização do código: Este item costuma ser o de maior complexidade, dependendo da arquitetura existente. Arquiteturas que dependem muito de heranças de classes, costumam dificultar a atividade de debug, que é a técnica usada para achar o ponto exato onde o problema ocorre. Ferramentas de pesquisa textual costumam ajudar a localizar ocorrências de mensagens no código, o que já facilita um pouco este trabalho. Por exemplo, se você sabe que o erro ocorre logo após uma mensagem de validação, procure por esta mensagem no código, e comece seu debug a partir deste ponto. 
• Breakpoint e callstack: use e abuse destes 2 itens para facilitar a localização do problema. Quando ocorre alguma exception, o callstack é a melhor ferramenta, pois lhe dará o ponto exato da exception, a partir da descoberta do ponto com problema é só debugar e descobrir porque está ocorrendo o erro. Nos casos onde o problema não gera exception, a luta é mais difícil, mas não impossível. Comece do nível mais alto, e vá aprofundando o nível durante o debug, isole o método que está causando o erro, debugue este método, e dentro dele, localize onde está o defeito, e vá cavando cada vez mais fundo no seu código para chegar até o defeito propriamente dito.  

• Estipule timebox: Importante ferramenta para não perder tempo demais em defeitos. Compartilhe sua situação e sua dificuldade com os demais desenvolvedores do seu time, alguém pode ter passado por uma situação semelhante que lhe dará informações importantes e úteis. Seu time também é uma ferramenta que você deve utilizar na solução de defeitos. 

Uma vez identificado a origem do defeito, vamos pensar em como resolver isso. 

Corrigindo o problema 

O primeiro passo aqui é descobrir se sempre foi assim, ou se “começou agora”. São informações simples, mas que ajudam, pois se começou agora, basta comparar os códigos da versão atual e de uma versão anterior. Veja se este defeito foi inserido por um código novo ou por outra correção. Isso elimina algumas horas de pensamento sobre o motivo do erro. 

No tocante à tratativa que deve ser dada, é necessário ser muito criterioso, pois uma alteração grande aumentará muito os pontos impactados pela sua correção, e consequentemente, os testes serão mais extensos. Uma alteração muito minimalista pode ser imprecisa, cobrindo apenas parte das possibilidades de erros, e você será agraciado novamente com um novo defeito neste mesmo ponto. 

Então, avaliar bem o motivo do problema é o segredo, pois a partir daí, será possível pensar na solução ideal para o caso. 

Caso sua aplicação já possua testes unitários, você estará garantido que as suas correções não inseriram novos erros na área testada. Se o ponto ainda não tiver testes, e for possível testar antes da correção, seria o ideal, mas caso não seja, tenha o dobro do cuidado ao fazer a sua alteração. 

Se for possível, ao final da codificação, implemente o teste, pois assim o débito técnico vai sendo pago. 

Testando o defeito 

O teste de um defeito deve ser realizado além do cenário indicado na descrição do defeito, pois existem cenários alternativos, e menos comuns, que podem também ter sido afetados pela sua correção.  

Novamente, caso tenha testes automatizados para o cenário, é importante executá-los, caso não tenha, mas seja possível testar antes da sua modificação, faça-o. Depois, faça a sua correção com a tranquilidade de que a sua correção não afetou o restante do funcionamento da aplicação. 

Conclusão 

Trabalhar com sustentação de software não é tão complicado quanto aparenta, basta que você tenha as ferramentas necessárias para facilitar o seu trabalho. Nada impede que você inclua novas etapas ou ferramentas no seu ambiente de trabalho. Adapte isso a sua realidade e trabalhe bem com sustentação. 

Lembre-se, a sustentação é tão importante quanto a evolução de um software. 

Sobre o autor

Pio Lollato Neto é formado em Processamento de dados pela UNOPAR, e pós-graduado em Arquitetura de Software pela UEL. Possui mais de 20 anos de experiência em desenvolvimento e análise de sistemas.

Como desenvolvedor de software, Pio preza pela qualidade do que é desenvolvido, pensando sempre no futuro do código que é escrito. Possui vasta experiência com código legado, e grande massa de dados. Considera o desenvolvimento de software uma arte e como toda arte, precisa de inspiração. Procura sua motivação nos desafios de um código complexo, ou na realização de uma nova codificação com práticas melhores sempre.