fbpx
Arquitetura Fria — Enfrentando reestruturações tecnológicas sem nenhum conhecimento sobre o negócio
Publicado em: quarta-feira, 19 de abr de 2023
Categorias: Arquitetura

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.


Mentoria Cloud Native .NET

Se você é desenvolvedor sênior, líder técnico ou arquiteto e tem interesse em fazer parte da mentoria, ter acesso à gravação dessa mentoria e outras dezenas, com todas as perguntas e respostas dessa live, e participar ao vivo das próximas pelos próximos 6 meses.

Clique no link e faça sua aplicação.

O Cloud Native .NET é meu principal projeto.

Onde empenho energia para ajudar, acompanhar, direcionar Desenvolvedores, Líderes Técnicos e jovens Arquitetos na jornada Cloud Native.

Conduzo entregando a maior e mais completa stack de tecnologias do mercado.

Ao trabalhar com desenvolvedores experientes, eu consigo usar seu aprendizado com .NET, banco de dados, e arquitetura para encurtar a jornada.

Ao restringir à desenvolvedores .NET eu consigo usar do contexto de tecnologias e problemas do seu dia-a-dia, coisas que você conhece hoje, como WCF, WebForms, IIS e MVC, por exemplo, para mostrar a comparação entre o que você conhece e o que está sendo apresentado.

É assim que construímos fundamentos sólidos, digerindo a complexidade com didática, tornando o complexo, simples.

É assim que conseguimos tornar uma jornada densa, em um pacote de ~4 meses.

Eu não acredito que um desenvolvedor possa entender uma tecnologia sem compreender seus fundamentos. Ele no máximo consegue ser produtivo, mas isso não faz desse desenvolvedor um bom tomador de decisões técnicas.

É preciso entender os fundamentos para conseguir tomar boas decisões.

0 comentários

Enviar um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.

Luiz Carlos Faria

Mensagem do Autor

Espero que goste desse post. Não deixe de comentar e falar o que achou.

Se acha que esse post pode ajudar alguém que você conheça, compartilhe!

 

Lives

Fique de olho nas lives

Fique de olho nas lives no meu canal do Youtube, no Canal .NET e nos Grupos do Facebook e Instagram.

Aceleradores

Existem diversas formas de viabilizar o suporte ao teu projeto. Seja com os treinamentos, consultoria, mentorias em grupo.