Engenharia de Software é uma profissão nova, já dizia um professor. Enquanto a medicina e arquitetura tem suas origens lá na antiguidade, o desenvolvimento de software (apesar do ábaco, como marco inicial da computação) é algo recente, do século passado. Isso significa que existe muita coisa para aprimorar em nossa profissão. Paradigmas de programação, padrões e gestão de projetos são práticas aprimoradas de (e que auxilia o) desenvolvimento de software, e que resolveram muitos dos problemas da programação.
Entretanto, ainda há algo que assusta os programadores atuais: a manutenção de software. “É melhor começar um projeto do zero, do que dá manutenção no sistema atual.” – é o principal frase ouvida do programador ao ser alocado a um projeto de manutenção. Mas, por que isso acontece? Por que é tão difícil manter um software? Por que é tão custoso? Não tenho a solução, mas quero convidar a refletir juntamente comigo (fique a vontade nos comentários).
Um projeto de software possui um ciclo de vida, onde é concebido, evolue e chega a um ponto que morre. Seja em RUP ou algum método ágil, os sistemas vivem neste ciclo. E a manutenibilidade determinará quanto tempo ele vai continuar vivendo ou evoluindo. Porém, muitos trabalhos são (ou não são) projetados sem levar em consideração tal aspecto. Hoje em dia, desenvolver um sistema sem um mínimo de planejamento, significa mais trabalho em futuras manutenções. O analista ou projetista deve ter em mente que a arquitetura do software vai determinar o rumo de sua evolução. É o alicerce do projeto. Um software mal modelado, sem flexibilidade em sua concepção, está fadada a elevados custos para se manter.
Engana-se quem pensa que todo o problema de manutenção de software está em sua análise ou arquitetura. Ainda que com um papel importante, o projetista pode ter feito seu trabalho excelente, mas há um outro ponto de vulnerabilidade, quando se trata de qualidade de código: o programador. Ser um bom programador não basta saber todos os macetes da linguagem, ter anos de experiências ou certificação. E isso certamente influencia nos aspectos qualitativos do sistema. Legibilidade e documentação são primordiais para que o sistema siga com alta manutenibilidade. Existe convenções e manuais de boas práticas para que os programadores possam manter o código legível, limpo e organizado. O programador não pode ter o foco apenas na funcionalidade em si, mas também nos aspectos necessários para o projeto, tal como desempenho, segurança, etc.
Mas, ainda que projetistas e programadores se esforcem para manter um código bem arquitetado e programado, manutenção em sistema parece ser o terror para os novos desenvolvedores alocados ao projeto. Ao que percebi (posso estar enganado ou com visão parcial), dois motivos são bastantes comuns para tal fato: (1) Dar manutenção em código alheio, requer tempo para se familiarizar com a arquitetura do sistema e com a domínio da aplicação. Para muitos, isso é tedioso. (2) Ainda que o código esteja limpo e organizado, em modo geral, certamente haverá soluções paliativas (leia-se POG) para problemas que necessitaram de correção em 5 minutos! E todos nós sabemos o qual cabuloso é resolver problema causada por esta metodologia de desenvolvimento (os professores de Engenharia de Software resmungaram agora!) .
Apesar de toda a situação da manutenção em software, sabemos que este é um “mal necessário”. Não existe possibilidade de refazer todo o sistema por N motivos. Ao programador, dedique-se em ser um bom programador, principalmente em clareza e documentação dos códigos. Afinal, um dia é você quem pode estar engajado na manutenção de um sistema. 
Fique a vontade para compartilhar sua experiência com manutenção nos comentários. Até mais!
Vinicius Cruz é formado em Ciências da Computação (2008) e desenvolvedor desde 2004. Atualmente cursa pós-graduação em Arquitetura de Software e Convergência de Mídia.