Software legado & Inovação

Seu sistema não é legado porque é velho. Ele é legado porque ninguém quer cuidar dele, e é isso que ninguém te explicou antes de você propor a reescrita.

Todo mundo já viu a cena: o backup derruba o site, o relatório de vendas mata o banco, o sistema cai na sexta e só descobrem na segunda. Aí alguém diz que a solução é migrar para microsserviço, ou trocar a linguagem, ou "ir para o Mongo, porqueque o Mongo não cai". Nenhuma dessas conversas resolve o problema porque nenhuma delas está falando do problema.

O que você vai aprender

• Uma definição de legado que funciona no roadmap: por que um sistema feito há 3 meses pode ser legado e um de 6 anos pode não ser, e porque essa distinção decide o que você vai conseguir aprovar
• Os 3 problemas que aparecem em toda operação de tecnologia consolidada: design mal definido, bola dividida (o sistema sem dono) e ausência de monitoria
• Por que débito técnico é a mãe do legado, e os 7 tipos de débito, do mais visível (infra) ao mais ignorado de todos (monitoria e pessoas)
• A tabela de 4 linhas que faz um gerente de produto ler sua recomendação técnica em 1 minuto e porque começar pelo porquê é o erro clássico de engenheiro
• Por que backlog de débito técnico é uma lista de promessas que você nunca cumpre, e o que fazer em vez disso
• Como usar as quatro métricas de execução do Accelerate para transformar "isso aqui me incomoda" em prioridade aprovada

Como a aula funciona

Você acompanha um caso real do começo ao fim: um marketplace de planos de saúde, um ano depois do rollout, com quatro parceiros no ar, três aplicações penduradas no mesmo cluster de banco e uma integração que levou 5 meses para entrar. A turma debate o que atacar primeiro. E então o instrutor mostra a ordem que ele usaria e por que a ordem dele é diferente da que você normalmente escolheria.

Não é uma aula de slide. É uma sala com Tech Leads, DBAs e engenheiros sênior trazendo o legado das empresas onde trabalham: o banco em Docker que ninguém sabia que existia, os quatro frameworks que viraram legado em dois anos, a pirâmide de testes que virou losango, o "sobrinho de TI" que o diretor adora.

Para quem é esta aula

Líderes técnicos, engenheiros sênior e arquitetos que sabem exatamente qual parte do sistema está apodrecendo, já tentaram explicar isso para o produto e foram ignorados.

"Contra número não existe argumento. Se você não consegue mostrar o risco do débito técnico, ele não vai ser priorizado."

O que você leva junto

1. Um vocabulário para nomear o problema na frente de quem decide o roadmap
2. Um método de priorização que coloca débito técnico na mesma fila do negócio (porque separado ele nunca sai)
3. As referências práticas para atacar o código: Working Effectively with Legacy Code (Michael Feathers) e Refactoring (Martin Fowler), e o que buscar em cada um

Ao fim da aula vai ficar claro para você que o problema quase nunca é a linguagem de programação.