Quem faz a manutenção do seu sistema?

Saiu um artigo sobre manutenção de software na Communications of the ACM de Novembro. Manutenção é um dos meus assuntos favoritos, porque é bem mais difícil cuidar de sistemas existentes do que criar sistemas novos.

Só pra definir e situar todo mundo, manutenção de software é o nome que se dá para a fase do ciclo de vida de um sistema que começa no instante em que o sistema é colocado em funcionamento. É comum se classificar em três os diferentes tipos de manutenção. O primeiro tipo é a manutenção corretiva, ou seja, corrigir bugs. O segundo tipo é a manutenção evolutiva, ou seja, acrescentar novas funcionalidades. O último tipo é a manutenção adaptativa, que significa mudar o sistema para se adaptar a mudanças no ambiente em que ele funciona - por exemplo, porque saiu o Internet Explorer 9 e seu sistema ficou todo quebrado.

Não gostei do artigo. Os problemas que os autores usam para motivar seus argumentos não são reais. O artigo até seria bom se tivesse sido escrito em 1989, mas vinte anos depois as coisas são diferentes. Na era da internet, todo software é software em evolução. Não existe mais o conceito de software que não é criado com a evolução e manutenção em mente. Nunca trabalhei em uma empresa que não achasse isso importante e não tentasse planejar de acordo.

É claro que existem problemas interessantes envolvendo a manutenção de software. Hoje vou falar sobre um deles: quem deve fazer a manutenção. Na semana que vem falarei sobre outros.

Primeiro, preciso fazer uma confissão. Eu adoro fazer manutenção. Corrigir bugs então, nem se fale. Posso passar dias, principalmente bugs em código que eu não escrevi. Não, eu não estou sendo irônico, eu sei que a maioria dos programadores detesta isso. Pois pra mim não tem nada mais divertido. Quando estou procurando bugs em código que eu não conheço, eu me sinto um detetive investigando um mistério. Preciso tentar descobrir o que o código faz, por que faz o que faz, o que estava passando pela cabeça do programador que o escreveu. E no final tem um prêmio concreto: remover o bug! Bom demais.

Também gosto muito de fazer a evolução de código que eu não escrevi. Gosto de olhar para o design do sistema e tentar pensar em um design mais adequado à mudança que eu quero fazer. Não tenho a mesma motivação para mudar código que eu mesmo fiz. Eu olho para aquilo e penso no trabalho que já deu pra escrever, e não quero mudar tudo de novo. Quando o código não é meu, não tenho esse bloqueio.

Bom, voltando ao assunto. É comum entregar a manutenção de sistemas existentes aos desenvolvedores menos experientes, deixando os programadores que tem super-poderes livres para trabalharem nas novas idéias que vão render um trilhão de dólares. Para mim, isso é um erro. Deixar a evolução nas mãos de pessoas que não conhecem bem os motivos por trás das decisões que levaram o sistema a ser como é leva inevitavelmente à degradação acelerada da qualidade do código. O desenvolvedor que faz mudanças pontuais sem levar em consideração o design geral do sistema torna o código cada vez menos estruturado.

Quando projetamos um sistema novo, temos um grau elevado de liberdade para tomar decisões técnicas. Existe um número quase infinito de caminhos corretos que vão levar ao sistema que queremos construir. Fazer manutenção, por outro lado, implica em trabalhar com muitas restrições. Existem muitas maneiras de se fazer o que precisa ser feito, mas poucas maneiras corretas.

A não ser que seu objetivo seja abandonar o sistema a curto prazo em prol de um novo sistema que está sendo desenvolvido, deixe que os melhores programadores cuidem dele. Assim ele vai crescer com saúde e alegria.

Ah, tem uma exceção: eu acho que corrigir bugs é a melhor forma de introduzir um novo desenvolvedor a um sistema existente. É uma tarefa concreta que exige que o programador aprenda muito sobre as entranhas do código e sobre o design dos componentes. É só garantir que todas as mudanças serão revisadas por um desenvolvedor experiente para que o exercício não vire um problema depois.