Como tornar a manutenção em sistemas legados interessante?

[gjrmacedo]

Uma pergunta genérica para reunir o maior número de opiniões, possíveis!

Apenas para que entendam a minha dor:
Temos um sistema legado escrito em ASP Clássico (A verdadeira definição de "código macarronada"), e eventualmente precisamos estar dando manutenção em telas criticas (geralmente resolvidas com outra macarronada e muito jQuery). Obs: Neste momento é totalmente inviável a migração do sistema para uma tecnologia mais atual.

- Como tornar a manutenção em sistemas legados interessante?
- Recomenda algum framework/lib para facilitar a manutenção ou torna-la menos difícil?
- WebComponents encaixaria legal em uma tentativa de tentar "abstrair o legado"?

[renatogalvones]

Obs: Neste momento é totalmente inviável a migração do sistema para uma tecnologia mais atual.

Acho que exatamente aí é que está o pulo do gato. Como mudar esse cenário e passar a utilizar essa tecnologia mais nova.

• Quando vai ser viável e o que precisa ser feito para ser viável?
• É possível dedicar um pedaço da sprint(em caso de scrum, ou de tempo mesmo se não usar) para iniciar esse trabalho?

Aqui na Catho estamos passando por um momento semelhante, montamos um plano à médio/longo prazo e parece que agora o tão doloroso legado vai começar a não ser tão doloroso assim.

[fernahh]

Legal esse assunto. Sistema legado é o que mais existe no mercado, dificilmente você vai encontrar sistemas com uma boa arquitetura de software.

Como tornar a manutenção em sistemas legados interessante?

O primeiro passo é escrever testes automatizados para features legadas. Fazendo isso, o próximo desenvolvedor que for fazer manutenção vai ter mais segurança na hora de programar.

Como fazer isso? Mais ou menos o que o @renatogalvones falou: encaixar o desenvolvimento dos testes nas sprints. Onde eu trabalho existem diversas features legadas, e cada vez que um desenvolvedor vai dar manutenção a um desses pontos, ele precisa criar testes pro enviroment inteiro que ele pode afetar.

Recomenda algum framework/lib para facilitar a manutenção ou torna-la menos difícil?

Acho que nenhum framework vai resolver esse problema, ao menos que você reescreva.

WebComponents encaixaria legal em uma tentativa de tentar "abstrair o legado"?

Não sei se eu entendi bem essa pergunta. Eu não apostaria minhas features nos WebComponents em projetos de longo prazo.

Débitos técnicos

Uma boa forma de justificar a reescrita de features é criando débitos técnicos sempre que você fizer manutenção em código legado. "Logando" todas as vezes que você precisou mexer em código antigo é uma forma de provar para quem toma decisões de negócio que ele pode estar perdendo dinheiro.

[woliveiras]

O primeiro passo é escrever testes automatizados para features legadas.

Excelente dica, @fernahh!

[hugooliveirad]

Sistemas de software precisam ser continuamente mantidos e reescritos, caso suas funcionalidades continuem crescendo.

Existem algumas técnicas de como fazer isso com sistemas muito grandes que já passaram da "data de validade" e não são mais manuteníveis. Uma que eu já usei com sucesso algumas vezes é bem simples: começar pelas pontas.

Imagina seu sistema como uma árvore. O sistema inteiro é a raiz da árvore e cada folha uma funcionalidade. Algumas funcionalidades estão interligadas com outras funcionalidades.

            Sistema      
       +---------------+ <- funcionalidade
       |               |
   +---+---+       +---+---+ <- funcionalidade
   |       |       |       |
 +-+-+   +-+-+   +-+-+   +-+-+
++   +   ++  +  ++   +   +   ++
+         +     +             + <- funcionalidade

É muito difícil reescrever um sistema a partir da raiz dessa árvore. É bem mais fácil começar melhorando/reescrevendo suas folhas. Quanto mais baixo você começar, maior a chance de sucesso do projeto de melhoria.

Alguns padrões de desenvolvimento podem te ajudar. Uma técnica que pode ser utilizada é a Adapter.

O padrão Adapter converte uma interface de uma classe para outra interface que o cliente espera encontrar. O Adaptador permite que classes com interfaces incompatíveis trabalhem juntas.

Mesmo que você não esteja utilizando classes, o conceito continua o mesmo.

Estes adaptadores ajudam você a desenvolver seus módulos pensando na arquitetura ideal e adaptá-los ao sistema legado atual. Posteriormente, você pode se desfazer dos Adapters.

---

Existem uma infinidade de maneiras de resolver este problema. Estude, junte-se com seu time, ganhe a confiança de seus gerentes e estabeleçam um plano de como atacar este problema de negócio. Existem livros exatamente sobre isso, mas não posso recomendar nenhum pois nunca os li.

[RatoX]

Só lembrando que qualquer código sem teste é código legado, Working Effectively with Legacy Code Leitura obrigatória para quem tá virando senior ou já é um(a)!

[phmiranda]

Não sou muito entusiasta de sistemas legados justamente por conta de ter um padrão totalmente problemático, mas como o colega acima citou...começar pelas pontas e implementando tudo a partir dos testes. Não tem a ver só com a versão da tecnologia, mas sim com o monstro e a fuga de padrões que dificultam a execução de demandas dentro do sistema, isso prova uma falha da equipe ao meu ponto de vista, que poderia perder uma média de alguns minutos a uma hora auditando códigos feitos no dia para caso necessário, implantar uma refatoração visando evitar falhas futuras para o usuário final e assim buscando a melhor qualidade de código possível.