Nesta semana, abordei o tema “Arquitetura Fria – Enfrentando reestruturações tecnológicas sem nenhum conhecimento sobre o negócio”.

Esse assunto é polêmico, principalmente aos olhos dos leitores de manchetes, portanto…já sabe né?!

Vem comigo, que hoje eu vou destravar uma habilidade interessante e útil.

Partindo do pressuposto de que a maioria das reestruturações de projetos ocorre devido a questões técnicas que afetam o cotidiano do negócio, notamos que não há tanta falta de conhecimento sobre o negócio, mas sim a falta de boas práticas técnicas, na maioria absoluta das vezes.

O efeito pêndulo

O efeito pêndulo sugere que um sistema específico precisa estar equilibrado.

Se privilegiamos um aspecto, causamos desequilíbrio no sistema, fazendo com que o pêndulo se mova para uma direção. Quando percebemos o desequilíbrio, empenhamos energia na direção oposta, negligenciando o aspecto que havíamos privilegiado antes.

Esse movimento pode ser percebido ao longo dos anos, e assim percebemos esse efeito nos mais variados lugares. Na política, na economia, nas tecnologias, na forma de aprender e estudar.

Efeito pêndulo: Negócio vs Tecnologia

O efeito pêndulo também é evidente neste desequilíbrio entre negócio e tecnologia. No passado, focávamos mais na parte técnica, negligenciando o negócio. Agora, ocorre o inverso. Dedicamos mais energia ao negócio e negligenciamos a parte técnica.

O fato é que existe um ponto de equilíbrio entre negócio e tecnologia. Nem só aspectos de negócio, nem só aspectos técnicos: ambos merecem atenção.

Em uma época em que o faturamento de muitas empresas está cada vez mais ligado ao desempenho de soluções tecnológicas, entender que esse equilíbrio é necessário pode evitar reestruturações desnecessárias.

O que faz projetos precisarem de restruturação?

Desde 2008, conduzi “algumas” reestruturações e compartilhei na mentoria a estratégia que desenvolvi para lidar com elas.

Do ponto de vista técnico, essas falhas geralmente estão relacionadas a:

• Arquitetura e Design (Arquitetura inadequada, acoplamento, complexidade, incapacidade de evoluir rapidamente)
• Desempenho (performance geral)
• Escalabilidade limitada/comprometida
• Consumo excessivo de infraestrutura/cloud
• Acúmulo de dívida técnica
• Desatualização tecnológica
• …

A lista é extensa, mas, em resumo, são projetos mal projetados e mal-executados.

As habilidades necessárias

Ao enfrentar esse tipo de reestruturação, algumas habilidades fazem muita diferença.

Estilos de modelagem

A primeira é conhecer estilos de modelagem e seus desafios.

• Managers
• Enrichers
• Top-down / Bottom-up

Além de padrões arquiteturais, claro.

Empatia

A segunda é a empatia. Em 21 anos de carreira, não me recordo de casos em que os erros foram cometidos intencionalmente.

Prazo, conhecimento, pressão – todos esses fatores afetam o julgamento e, sob essas forças, erros podem acontecer. Isso ocorre porque a qualidade fica em segundo plano, já que outros aspectos precisam ser privilegiados, como prazos.

Estratégia

A terceira habilidade é a capacidade de criar uma estratégia para conduzir do ponto A ao B, podendo ser necessário passos intermediários para obter o apoio de ferramentas e equipe.

No mundo, há menos pessoas que possuem o conhecimento necessário para migrar um projeto COM+ e ASP Clássico para .NET do que profissionais com conhecimento para refatorar um projeto .NET escritos como se fosse ASP e como se fosse COM+.

Nesse tipo de reestruturação, talvez fosse mais prudente fazer uma migração COM+ para o .NET (trocando apenas de COM+ para WebAPI) para só depois refatorar o projeto .NET, revisitando de fato o design.

Isso implica na primeira etapa manter todas ou quase todas as coisas ruins e velhas, como concatenação de strings para montar SQL, falta de separação de camadas, tudo que hoje rechaçamos como práticas ruins, seriam mantidas nessa primeira fase.

Uma vez realizada a primeira fase, eu teria ferramental, uma IDE, e a oportunidade de ter um time muito maior para refatorar e reestruturar esse projeto.

A ideia é que é muito mais fácil refatorar um projeto .NET com o Visual Studio, Rider, e afins, do que lidar com COM+, VB6 e ASP Clássico.

Ao passo que também, ao portar quase que exatamente igual ao projeto original, a capacidade de encontrar paridade nessa portação, facilita a correção de erros causados apenas pela migração.

Eu consigo comparar VELHO com INTERMEDIÁRIO e facilmente corrigir problemas novos, causados pela migração.

A missão é que uma vez validada a versão intermediária, a versão velha pare de ser usada como base. E a base para comparação passa a ser uma versão intermediária. Que agora com o porte de tecnologia, conseguimos ao menos ter mais gente com skill para ler, entender e executar.

Essa é a estratégia que adotaria!

E este é um caso real.

Existem estratégias, técnicas e táticas para lidar com esse tipo de projeto, e o conhecimento de negócio não é obrigatório.

Isso não significa que não seja necessário para a equipe, mas não é imprescindível para quem conduzirá a reestruturação.

Nesse caso quem desempenha o papel de Product Owner e fornece a dose de conhecimento do negócio para a reestruturação é o próprio time técnico já envolvido na versão anterior do projeto.

Essa é a mágica!

O papo foi bem mais profundo, essa Mentoria foi na mentoria do Cloud Native .NET e aconteceu dia 17/ABR.