O Mito do Grande Rewrite

Eu escrevi sobre isso em: https://www.tabnews.com.br/maniero/dbe71a2a-f0b2-44a9-a12b-185246d2cc9c.

Vou contar uma experiência. Há alguns anos eu convenci uma empresa a mudar de stack, e portanto reescrever do zero. Fiz isso com vários subsídios que eu tinha, por exemplo que o sistema estava todo impraticável, com inúmeras gambiarras custosas e horríveis, clientes extremamente insatisfeitos, pulando fora porque sabem que não dá pra melhor aquela geringonça e a pessoa que gerencia tudo isso sabe bem menos do que ela acha e que outros ali no local acham.

Propus aproveitar para fazer de uma forma que facilitasse muito a manutenção depois e resolvesse problemas específicos em vez de só reescrever tudo igual. Dei 4 anos para fazer tudo aquilo se a equipe colaborasse de forma adequada, o que eu não sabia se era possível.

Começaram fazer sem mim porque o gerente de todo desenvolvimento deu apenas 1 ano e faria a troca de stack mesmo, sem modernizar o sistema. Até começaram resolver alguns problemas graves porque qualquer coisa que fizessem iria melhorar isso, mas continuou ruim, e agora feito com uma linguagem que nem o gerente, muito menos os demais sabiam como usar adequadamente (eu sou reconhecido como alguém que domina bem ela).

Eles estão indo para o 6o. ano, tem bem poucas partes refeitas, tem vários problemas novos que não deveriam estar lá se soubessem o que estavam fazendo, e mantinha os erros pontuais do sistema. A única vantagem era jogar fora a gambiarra maior que fazia o sistema desktop deles rodar na web e passar ser web mesmo, mas do jeito errado.

Refazer pode ser a solução em alguns casos, mas precisa de gente muito experiente cuidando disso, e isso é muito raro de achar, então não refazer provavelmente ganha nessas condições inadequadas.

S2

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui).

Como o maniero já bem disse, sim e não.

A (outra) verdade inconveniente

Código de prototipação nunca deveria ver a produção.

Mas verá.

Sempre vê.

Cada nova aplicação devia nascer com etiqueta “jogue fora depois que funcionar”.

Enquanto ainda estamos descobrindo o que diabos queremos resolver, a regra é clara: vai sair gambiarra, e tá tudo bem. O crime começa quando a gambiarra ganha cargo de arquitetura. Já fiz refactor que transformou TempFixHelper em LegacyCoreManager.

Agora estou trabalhando em um novo produto que bateu 100k de linhas de código. A PoC original, só o caminho feliz, cabia em duas mil. 98k sloc e dois anos depois de “só ajustar aqui” pra cobrir todo edge case que aparecia percebemos que quase tudo era variação de um caso especial só.

Nunca teríamos aprendido isso sem ter feito todas as gambiarras. Sem ter perdido noites debugando teste que só passava em noite de lua cheia com cache quente. Mas depois que aprendemos…

aí, meu amigo, Hora de jogar as 100 k sloc fora e começar de novo.

Porque finalmente sabemos o estamos construindo.

Frase de Aldo Novak: “É melhor o imperfeito feito que o perfeito não feito.”