Como realizar a transição entre um software legado e não legado?

[reinaldorauch]

Como fazer isso, sendo reescrevendo ou reimplementando do zero ou tirando ele da classificação de legado ou algo assim?

[netojoaobatista]

Bom, @reinaldorauch, a primeira coisa que precisa ficar claro, é que existe alguém utilizando esse software.

Muitas empresas, ao desenvolver uma nova tecnologia, continuam mantendo o software legado por conta de uma carteira de clientes que utilizam o software. Reescrever ou reimplementar do zero realmente tira a condição de legado, mas haverá quebra nos clientes que utilizam a versão legada?

Muitos clientes que utilizam determinado software legado possuem uma resistência muito grande para fazer a migração para o novo software. Se o software estável, apesar de legado, está funcionando e resolvendo o problema desses clientes, eles resistirão muito para migrar. E resistirão porque é caro.

É preciso compreender que migrar de um software legado para um novo cria um custo para toda a carteira de clientes. Esses clientes questionarão à empresa desenvolvedora: Por que eu devo migrar?

Essa pergunta motivou a EllisLab a manter o CodeIgniter com tecnologia defasada só para continuar mantendo sua carteira de clientes sem que houvesse quebra.

A migração de um software legado para um não legado envolve uma estratégia comercial muito alinhada com a refatoração do software. É preciso que as mudanças sejam pequenas e contínuas; é preciso que exista uma equipe de suporte para ajudar nas adaptações necessárias nos clientes e, mais importante, é preciso que as mudanças agreguem valor.

Quando a empresa desenvolvedora for questionada sobre custos de migração ou adaptação, a empresa precisa ter bem claro o valor que será agregado ao software. É preciso que o valor supere o custo. Apenas com o valor da migração ou adaptação bem definido, que a empresa diminuirá a resistência de seus clientes.

Basicamente a resistência é assim:

• Clientes pequenos - resistência baixa; esses clientes são super propensos a testar novas tecnologias.
• Clientes de médio porte - resistência moderada/baixa; esses clientes ainda são propensos a testar novas tecnologias, mas devido a complexidades de migração, eles começarão a questionar os porquês de fazê-la.
• Clientes de grande porte - alta resistência; esses clientes normalmente continuam utilizando versões defasadas do software porque o custo de qualquer adaptação, por menor que seja, envolve uma grande complexidade e um grande custo. Esses clientes provavelmente ainda usam Windows XP e preferem negociar suporte estendido em vez de atualizar a versão do sistema.

[iannsp]

@reinaldorauch, sua pergunta é: ao se decidir por atualizar, desenvolvendo um novo ou refactorando o codebase atual, como fazer isso? se for, aqui vai meus vinte centavos.

Eu sempre vou optar em primeira mão pelo refactoring incremental seguindo um mapa bem consistente de ações.

1 - Escolher um dominio de dentro do software(um problema especifico) 2 - Criar um namespace para ele (isolar a nova implementação) 3 - Desenvolver a solução para o problema dentro desse novo namespace utilizando as praticas em que acredito, incluindo tdd e testes. 4 - criar uma camada de adaptação entre o código novo e o código antigo. A interface do código novo não é obrigatóriamente aderente a interace utilizada pelo código anterior, logo, para manter o software funcionando com as mesmas interfaces preciso adicionar um facade, por exemplo. 5 - Criar testes funcionais dos pontos que considero de risco quando utilizo o gateway, assim eu posso testar o comportamento da aplicação e a expectativa de que ele continue o mesmo que anterior. 6 - repetir do 1 ao 5 até me dar por satisfeito.

Esse desenvolvimento me permite uma coisa bem saudavel perante os clientes, que e reescrever a aplicação "de dentro pra fora", logo, meus clientes não são impactados e não precisam decidir em trocar de versão ou não pq isso é transparente para eles.

[ghost]

@reinaldorauch, existem várias técnicas de reengenharia de software para isso, como Fusion/RE e FaPRE/OO. Tem que se levar em consideração qual é o "tamanho do problema", se foi desenvolvido em paradigma procedural ou Orientado a Objeto. Para cada caso é um método específico para ser aplicado. ;)

[netojoaobatista]

O ponto é que não importa muito como você irá refatorar o código, @camilotx. Mais importante é como você fará o cliente migrar para o novo software.

[netojoaobatista]

Se você disser para um grande cliente que apenas a nova versão terá adição de novas features, o grande cliente reclamará. Ele provavelmente dirá: Adicione a nova feature na versão que eu uso, ou troco de fornecedor.

Você, e ninguém provavelmente, quer perder um grande cliente. A refatoração é importante, mas a estratégia comercial para a migração é mais importante.

[ghost]

@netojoaobatista, as técnicas que eu citei não contemplam só a refatoração do código, mas sim como fazer essa "troca" de forma a não causar tanto impacto. Claro que eu concordo com você 100%, o que eu fiz foi dar uma resposta simplista a pergunta, já que você e o @iannsp responderam brilhantemente.

[reinaldorauch]

@netojoaobatista, É o problema que eu vivencio no momento, em que tenho que adicionar funcionalidades em um sistema legado (diga-se de passagem, mal feito). A resposta do @iannsp veio muito a calhar, pois até o momento estava tendo dificuldades em como continuar mantendo o legado sem misturar mais a salada. Então, resumindo, deve-se somente migrar para/criar/sugerir nova versão quando ela efetivamente agregar valor para os stakeholders?