A importância da manutenção

Vejo a manutenção e a implementação como as fases do processo de software mais afetadas pela questão da qualidade. Isso é bem óbvio.

Primeiramente, vou falar da manutenção que, dependendo do tempo de vida da aplicação, é a fase mais longa do processo.

Manutenção, resumidamente, é qualquer procedimento que leve a alteração do código, durante a implementação e após a release final.

O negócio do cliente muda constantemente. O sistema precisa acompanhar este dinamismo. Requisitos nascem, mudam e morrem a todo instante. A aplicação deve se adaptar. Complexidade de implementação vai depender da complexidade do requisito, dessa forma, é relativa. Mas a questão é: seu código não deveria ser uma pedra no caminho.

Já precisei reconstruir uma aplicação inteira, pois ficou impossível adicionar mais requisitos. Era um monstro quase monolítico, em Delphi 6. As units eram enormes e toda a regra de negócio era programada nos eventos. TODA!

Era o tipo de aplicação que se mudasse ou acrescentasse uma vírgula acontecia um desastre. Usando uma expressão do Page-Jones neste livro, era Conascença de Aplicação. Pelo menos o desenvolvedor criou um tipo de conascença.

Expliquei a situação para o dono da empresa que sabia se tratar de uma aplicação crítica. Depois de algumas negociações de prazo, iniciamos o projeto.

Esta situação foi razoavelmente fácil de contornar, pois não havia ninguém (líder, gerente) entre o desenvolvedor e os responsáveis pelo negócio. Compreenderam que a reconstrução era o melhor para o negócio, investiram nela por alguns meses e ainda estão colhendo os frutos. Este fato ocorreu no final de 2005 e a aplicação funciona até hoje, sendo mantida por outra pessoa desde o fim de 2007.

Nem sempre a solução é simples, pois, normalmente, existem pessoas entre o cliente e o desenvolvedor que, muitas vezes, têm interesses que os impedem de pensar na qualidade. O crédito desse parágrafo vai para um diálogo que acabei de ter com Paulo Cereigido, companheiro de embarcação. É um assunto que será abordado em um post futuro.

O ponto é: ficar resmungando com os botões, reclamando do cliente, não resolve nada. Só trará desgostos e mágoa com a profissão. Precisamos fazer algo para mudar esse tipo de mentalidade nociva e imediatista. E é basicamente essa a pretensão deste blog. Buscar caminhos para implantação definitiva da qualidade.

EDIT: Quero deixar claro duas coisas:

1. Estou considerando desenvolvimento = análise + programação + teste unitário;
   
2. Quando falo em qualidade, falo em qualidade de código.