Neste artigo abordo assuntos ligados à migração de software sob a ótica do fornecedor, também conhecido como fábricas de software.

Ao longo do artigo vou usar o termo “migrar o software” com frequência, por isso, toda vez que você ler “migrar o software”, peço que entenda “atualizar a versão da linguagem” ou “adotar nova tecnologia” ou “migrar a base de código para uma nova arquitetura” ou qualquer outra alteração mais abrangente no software que possa levar a sua reescrita total ou parcial.

Agora vamos a pergunta que não quer calar:

Por que eu preciso migrar o software?

Esta não deve ser uma pergunta fácil de responder e tão pouco os motivos devem ser frívolos. O capital investido nesta decisão, seja financeiro ou humano, é grande. Por isso, quando a oportunidade bater na porta ou aquela vontade nascer no travesseiro – depois de uma noite em claro por conta de manutenção ou build quebrado – pense bem. Eu vou discorrer sobre aqueles que eu julgo serem os três principais motivos que nos levam a migrar o software. Ainda assim, tenho certeza que você poderá encontrar outros. Os três grandes motivos que nos levam a migrar o software são: Humano, a stack de desenvolvimento e o nosso próprio software. Vamos falar sobre eles.

O motivo é: Os humanos!

Software ainda não se faz sozinho. E por isso os responsáveis por ele precisam estar atentos a disponibilidade de mão de obra. Faculdades, cursos técnicos, grandes empresas tendem a criar “bolsões”, formando majoritariamente profissionais para uma determinada tecnologia. Esse movimento, entretanto, é instável e inúmeras razões podem levar o mercado para outros rumos, mudando também o perfil da pessoa desenvolvedora. Se a empresa já tem uma política de home-office bem estabelecida, talvez os impactos dessas mudanças não sejam tão imediatos. O problema é quando o profissional começa a ficar escasso no país. E quando isso acontece, a lei da demanda x procura é quem define o valor da mão de obra.

Se o software não se faz sozinho, muito menos um desenvolvedor. Por isso as empresas precisam voltar os seus olhos para a comunidade e não para indivíduos. As comunidades de software serão as primeiras a perceberem essas mudanças. Somente o fato de existir uma comunidade pressupõe a existência de mão de obra. Você pode querer manter um software escrito em FoxPro. Mas qual a recorrência de mão de obra para esta linguagem? Qual será o custo de um projeto em que a maioria dos desenvolvedores tem alto nível de senioridade?

A comunidade também pressupõe diversidade. Existem comunidades específicas de uma linguagem (como PHP Ingá e Delphi Ingá, cujo nome já entregam o tema) e outras mais diversas, abertas para stacks diferentes (como a BEMUG, que fala de backend independente da linguagem). A troca de experiências e conhecimentos técnicos que acontecem nesses meios, favorece a criatividade na medida em que faz crescer o repertório de soluções da pessoa desenvolvedora. Estratégias adotadas em C#, por exemplo, podem ser adotadas em Delphi, ou PHP.

Na equipe em que trabalho, temos uma pessoa com daltonismo. Não foram poucas as vezes em que adotamos soluções visuais e essa pessoa, em tom jocoso, porém verdadeiro, sinalizou: “Pra mim é tudo cinza. Não consigo entender o que vocês estão querendo comunicar”. Quando falamos em diversidade e inclusão, também falamos sobre quem vai utilizar o nosso produto. E se alguém não consegue usá-lo, é um cliente a menos que atendemos. Quanto vale um cliente para você? Uma equipe diversa ajuda você a não perder – e eu diria até captar novos – clientes.

Se as pessoas não são um problema para você, talvez esse outro motivo pese um pouquinho na sua opinião:

O motivo é: Stack de desenvolvimento

Quando eu falo stack de desenvolvimento (ou somente stack), me refiro a todo o ecossistema. Desde a IDE de desenvolvimento até o deploy no cliente. A stack é muito importante no ciclo de vida do software. Afinal, a maior parte do seu tempo de vida vai ser ali: debugando, codificando, buildando e deployando. Mas quando a stack é um problema?

Quando ela é pouco produtiva. IDE’s de desenvolvimento podem ser pouco produtivas. Elas travam, elas não têm um editor com as facilidades que todos nós gostamos. Mas hoje existem várias alternativas de editores de código que, geralmente, sanam essas dificuldades. Mas nada pode ser feito quando o problema é a linguagem. Uma máxima do desenvolvimento é: Mais código, mais bugs. Menos códigos, menos bugs. Algumas linguagens podem estar paradas no tempo, sem atualizações, e por isso são extremamente verbosas e sem soluções que auxiliem o desenvolvimento da aplicação.

A stack também é um problema quando ela não é adequada para o seu modelo de negócio ou não proporciona soluções simples para os seus problemas cotidianos. A stack que sustenta um projeto simples, baseado em LAN e poucos acessos simultâneos é bem diferente da stack de um projeto mais complexo, baseando em WAN e milhares de acessos simultâneos. Se você precisa de portabilidade, escalabilidade e elasticidade no software, mas a sua stack transforma isso numa enorme dor de cabeça e uma pilha de gambiarras, talvez você esteja apertando parafuso com uma faca. Vai funcionar, mas talvez você perca a faca. E no mercado, quando se perde o fio da navalha, é para sempre. Tá aí o Orkut que não nos deixa mentir.

Algumas vezes, para não perder o Time to Market, é preciso atualizar alguns elementos da stack ou até mesmo ela toda. Quando essa atualização é financeiramente dispendiosa, você tem um problema. Existem soluções gratuitas que são mantidas por empresas privadas ou até mesmo pela comunidade.

Por isso é quase inadmissível desembolsar vinte e cinco mil por desenvolvedor, apenas para entregar o software em uma nova versão do sistema operacional. Essas alterações de stack, pode acreditar, não serão raras. Pelo contrário, tendem a ser mais constantes, quer você programe para web ou mobile ou Win32. A TI está em constante mudança e mais coisa vem por aí. Você está preparado?

Até aqui, os motivos que apontei foram de caráter externo, causados pelo “universo”, por assim dizer. Chegou a hora, portanto, de olharmos para o nosso próprio umbigo.

O motivo é: o meu software

Softwares mudam. Eles crescem conforme crescem os clientes e a base de usuários. Crescem conforme mudam as leis. Crescem conforme mudam as necessidades. Esses movimentos de crescimento não devem ser motivo de dor de cabeça para a equipe. Pelo contrário, são oportunidades de incrementar o faturamento. Mas nem todo software permite isso. Ou se permite, o custo não é baixo.

Assim, um dos motivos que nos levam a migrar o software é o alto custo de qualquer alteração, cuja recuperação se dará apenas em longo prazo. Este custo não pode ser medido apenas nas horas de trabalho orçadas. Nesta conta precisam entrar a introdução de novos erros, retrabalho, a dificuldade em executar a pirâmide de testes (se é possível executá-la), o desgaste para arquitetar uma solução que não quebre tudo (algo comum em projetos com alto acoplamento e pouca coesão). O que é mais preocupante ainda é que, além da existência desses percalços, dependendo de como é a sua stack, é virtualmente impossível prever o tamanho e o impacto deles na entrega final.

Quando a base de cliente aumenta, a arquitetura do software também precisa atender a demanda. E é neste momento em que escalabilidade e elasticidade se tornam valores imprescindíveis. Quando a nuvem se torna o destino certo do seu software, é necessário quebrar o monolito em pedrinhas menores. Se a arquitetura dele não permite isso, ou inviabiliza financeiramente a nuvem, é o momento de voltar à prancheta e reescrever em serviços.

E uma vez na nuvem, novas oportunidades e necessidades surgem também. Surge a possibilidade de explorar novas interfaces: web, bots, assistentes, B2B. Surgem também outros detalhes técnicos e necessidades não funcionais: pipelines de CI/CD, multitenacy, responsividade, extração de métricas, data mining entre outros.

Alguns desses requisitos serão futuramente solicitados pelo cliente (ou oferecidos pela concorrência), outros serão necessários para que você entregue software com menor custo e maior qualidade. Se o seu software hoje não suportar esses novos requisitos, é hora de dizer adeus.

E agora? Como vou migrar o meu software?

“Parte da jornada é o fim” e o velho guerreiro vai deixar saudade e histórias das noites viradas, regadas a código, refrigerante e pizza. Mas o remanescente mais rico que permanece após a partida do software é o humano.

Pessoas que possuem bem consolidadas as regras de negócio, que sabem o que funciona e o que não funciona e que precisam saber onde erraram e onde acertaram na versão anterior do produto.

Por isso, a migração é um processo que começa nas mãos e mentes daqueles responsáveis pelo produto. Todas as pessoas envolvidas no ALM do projeto precisam estar alinhadas com os novos valores arquiteturais e o que se deseja para o produto nos próximos anos.

Um dos piores e mais recorrentes erros que já presenciei em migrações foi justamente reescrever totalmente o software, incluindo os mesmos vícios e erros. Se houver a decisão de migrar, que seja feito do jeito certo.

Outra falha comum na migração de software é de cunho estratégico. Geralmente não há estratégia; reescreve-se tudo do zero, incluindo o menu. Esta estratégia não é boa porque não permite errar rápido, atrasando o aprendizado e a percepção do comportamento do software e do cliente nessa nova versão.

Uma boa estratégia é a de migrar, por módulos, de maneira parcial. Na DevParaná Conference de 2019, o palestrante Emmanuel Neri apresentou a Arquitetura Reativa como uma solução para os microserviços.

Na sua palestra também abordou uma linha do tempo que serve como estratégia para a migração. Partindo do monolito até uma aplicação de respostas assíncronas e totalmente independente. Em outra oportunidade podemos aprofundar mais esses conceitos.

A migração do software abre uma janela de oportunidades e melhorias. É possível alcançar, com um novo software, novos clientes, diminuir custos, melhorar indicadores, entregar mais valor para o seu cliente. Tudo isso como fruto de uma base de código melhor e mais flexível, adotando as melhores práticas e processos de desenvolvimento.