Alexandre Valente's Blog

Hoje passei grande parte do dia conversando com clientes e parceiros sobre o processo de desenvolvimento em sistemas onde a maior parte do código é legado. Feliz ou infelizmente este é o caso da White Fox, onde o maior volume de esforço é feito em sistemas que já possuem muitos (alguns mais de 10) anos de existência (vieram por herança da empresa de onde a White Fox foi spin-off). Se por um lado isto demonstra um certo grau de satisfação do cliente por ter mantido o desenvolvimento conosco este tempo todo; por outro significa uma maior complexidade para manter e evoluir o sistemas.

Um ponto interessante que muitas pessoas parecem não compreender é que um sistema “envelhece”. Um argumento comum é “se funcionou até hoje, porque iria parar de funcionar?”. O que este argumento não leva em consideração é que todo sistema tem partes mutáveis. Sejam os dados que mudam de forma ou de volume, seja a plataforma que tem que ser evoluída por obsolescência de hardware ou software. E quanto menos se mexe, mais este processo é visível; tivemos um caso recente em que vulnerabilidades no IIS 6.0 fizeram-nos mudar para o IIS 7.0, porém componentes feitos para rodar no IIS antigo não funcionavam mais no novo e para completar, o fabricante do componente nem existia mais, o que impedia o seu simples upgrade. Acho que a comparação é como a da manutenção de um carro: é possível rodar sem manutenção até um ponto onde componentes começam a parar ou apresentar defeito…. Mas quanto mais se demora para se fazer as manutenções iniciais, mais caro vai ser quando elas se tornarem inevitáveis.

Outro ponto interessante comumente visto é a concepção errônea de que um modelo waterfall seria menos propenso a erros em um processo de manutenção. Definitivamente não é verdade, o que um modelo waterfall normalmente define é um tempo alocado explicitamente para planejamento de migração de legado, testes e garantia. Porém, isto acontece a um custo bem mais elevado do que em uma metodologia ágil. Em uma metodologia ágil também seria possível planejar e gerar testes caso isto traga valor para o cliente. A único questão é quantificar este valor para que a relação custo/benefício faça sentido e estas tarefas sejam adequadamente priorizadas, de forma tão ou mais importante do que as novas funcionalidades.

E interessante que a maior parte da literatura para o desenvolvimento de software trate de novos projetos, existindo pouca coisa específica para o processo de manutenção. Metodologias como o Scrum nem sequer se aplicam a processos de manutenção. Isto me deixa intrigado pois, a meu ver, a maior parte do esforço mundial de desenvolvimento deveria ser em manutenção; não faz sentido nem é sempre economicamente viável reescrever um sistema do zero a cada grande mudança. E nas metodologias ágeis há um dilema já logo no início, pois todas pregam a preparação de um sprint com aquelas tarefas que geram maior valor para o cliente. Ora, evoluir algo que já funciona dificilmente vai ter mais valor para o cliente do que qualquer nova funcionalidade, por menor que seja. Assim, evoluções acabam sempre ficando para segundo plano até o ponto onde acontece um problema grave com uma funcionalidade antiga e aí é um deus-nos-acuda para portar a mesma à toque de caixa ou achar um guru que ainda consiga mexer no legado de uma forma relativamente segura.

Há algum tempo atrás escrevi um post sobre a necessidade de refatoração de grandes sistemas. Hoje vou mais adiante, acho que além da refatoração, é necessário um esforço constante de migração e evolução dos sistemas e componentes legado. Isto deve ser feito enquanto o conhecimento de negócio e técnico ainda está disponível na empresa, para que o custo de atualização fique em um patamar viável. Neste aspecto, a existência de testes unitários e de integração são de grande valia, pois o tempo gasto na geração deste tipo de artefato acaba também se pagando na hora de uma eventual atividade de evolução. Toda a questão é como vender este tipo de atividade para um cliente. O que temos feito recentemente é tentar definir um percentual fixo das horas de desenvolvimento exclusivamente para serem gastas na evolução de partes antigas do sistema. Claro que estas tarefas também estão sujeitas a uma priorização entre si, usando como critério as funcionalidades que são mais críticas para o negócio do cliente e o grau de obsolescência das mesmas.

Outro ponto crítico na questão da manutenção é o procedimento de deploy. Em um sistema novo, fazer deploy é sempre algo trivial (acabamos de encerrar um sistema, por exemplo, onde o deploy é uma simples cópia de arquivos e uma pequena configuração do IIS; daqui a 3 anos duvido que este processo seja tão simples se a aplicação não for evoluída). E o esforço para se manter atualizado uma documentação de deploy para cada Service Pack ou alteração de infra-estrutura não é trivial e convencer o cliente de que isto é algo prioritário e que deve ser feito durante algum sprint é também algo extremamente complicado. De novo o grande motivador é a ocorrência de um erro mais grave, porém aí tudo já vai ser feito sob uma considerável quantidade de stress.

Ainda não sei qual é a melhor maneira de lidar com estas situações. Na White Fox estamos trabalhando com alguns clientes no sentido mitigar estes problemas e trabalhar ativamente na migração de legado. Os sistemas são tão grandes, no entanto, que é necessário um bom trabalho de priorização e um critério rígido de limites para que este esforço não consuma todo o previsto de uma deterimada sprint. Estamos tendo sucesso em alguns casos, porém ainda temos muito a melhorar e acredito também que algumas ferramentas poderiam ser de grande valia na avaliação dos resultados de determinada linha de ação.