Entrar no código de outro dev sem derrubar o que está no ar
O sistema já tem cliente usando e dinheiro passando. Como assumir sem quebrar, e por onde eu começo.
Quem chega depois herda o sistema e a culpa
Boa parte do que eu faço não começa numa pasta vazia. Começa num sistema que já está no ar, com cliente usando, às vezes com dinheiro passando, e com o desenvolvedor anterior fora do jogo.
É um trabalho diferente de escrever do zero, e a maior armadilha é tratar como se fosse igual. Quem chega e sai reescrevendo não entrega mais rápido: entrega um segundo sistema quebrado ao lado do primeiro.
Primeiro dia: não mexer em nada
O primeiro dia é de leitura. Subo o projeto local, rodo, e tento reproduzir o caminho principal inteiro: cadastro, login, a operação que dá dinheiro e o que acontece depois dela.
Enquanto isso vou anotando duas listas. A primeira é o que eu não entendi. A segunda é o que me assustou. A segunda lista é a que importa: é dela que sai a ordem do trabalho.
O erro que não aparece é o mais caro
O padrão que mais encontro em sistema herdado não é código feio. É erro engolido: a rota faz o trabalho, alguma etapa falha no meio, e a resposta volta como se tivesse dado certo.
Isso acontece por um motivo simples de entender. Alguém, em algum momento, se cansou de ver erro na tela e envolveu o trecho num bloco que captura tudo e segue a vida. O sistema para de reclamar e todo mundo acha que melhorou.
Só que agora o problema mudou de lugar: em vez de aparecer na hora, ele aparece no fim do mês, na conciliação, quando o número não fecha. Num gateway de pagamento isso é diferença entre um bug e um prejuízo.
Como eu acho isso
Procuro por três coisas, nessa ordem. Primeiro, todo lugar que captura exceção e não faz nada com ela: é onde o erro está sendo enterrado. Segundo, toda resposta de sucesso que não confere se a etapa anterior realmente aconteceu. Terceiro, log: se não existe, o sistema é uma caixa preta e qualquer conserto é chute.
Antes de corrigir, eu faço o erro aparecer. Log estruturado com o identificador da operação, e a falha subindo em vez de sumir. Costuma ser desconfortável, porque de repente o sistema começa a gritar coisas que já estavam acontecendo há meses em silêncio.
Fechar o buraco antes de refatorar
A vontade de reorganizar tudo é grande e é a hora errada. Primeiro fecho o que vaza: as rotas que mentem, o dado que entra sem validação, o dinheiro que muda de estado sem registro.
Refatoração vem depois, e vem por pedaço, sempre atrás de uma coisa que já esteja funcionando e testada. O cliente não paga por código bonito, paga por sistema que para de dar problema.
Reescrever do zero quase nunca é a resposta
Todo desenvolvedor que assume código de outro sente vontade de propor a reescrita. Eu já senti, e algumas vezes propus errado.
O sistema feio que está no ar carrega anos de regra de negócio que ninguém documentou, e boa parte dela está escondida em condição estranha no meio de uma função. Reescrever significa redescobrir tudo isso na base do prejuízo, um cliente irritado por vez.
Reescrita compensa quando a tecnologia inviabiliza o próximo passo, e não quando o código é feio. Feio se conserta em partes, sem apagar a luz.
Como eu trabalho nisso
Entro com acesso próprio e ambiente separado do que já existe, pra não misturar o que é meu com o que era do outro dev. Levanto a lista de riscos, fecho o que vaza, e só então sigo pro que você quer construir.
Se você tem um sistema no ar e o desenvolvedor sumiu, esse é exatamente o serviço. Chama que eu olho e te digo o que dá pra salvar.
Tem um sistema no ar sem dono?
Assumo o que outra pessoa começou, fecho o que está vazando e sigo dali.