Código Sujo: O Imposto Que Devs Pagam Sem Perceber

Onde o código vira uma armadilha

Todo mundo já abriu um arquivo e pensou: “Quem escreveu isso aqui me odiava pessoalmente”. Classes enormes, funções com 200 linhas, nomes que não dizem nada. O clássico legado onde cada ajuste vira percussão: mudou um ponto, treme o sistema inteiro.

**Código sujo não escala. Ele só acumula juros.**

Em sistemas complexos, a falta de legibilidade não é apenas incômodo técnico — é risco de negócio. Mais risco significa mais medo. E mais medo significa deploys cada vez mais raros e caros.

Como parar a sangria com pragmatismo

Não precisa reescrever o mundo. Precisa só parar de piorar a situação e aplicar algumas regras simples, totalmente alinhadas ao Clean Code clássico: funções pequenas, nomes que explicam a intenção, ausência de duplicação e limites bem definidos entre responsabilidades.

**O objetivo é reduzir entropia, não ostentar padrões.**

Implementação de Senior: exemplo real de limpeza progressiva

A seguir, um exemplo pequeno mas comum: uma classe cheia de responsabilidades, impossível de testar e frágil ao toque.

Antes:

class OrderService {    
    constructor(repo, notifier) {
        this.repo = repo;
        this.notifier = notifier;    
    }    
      
    process(order) {
        if (!order.items || order.items.length === 0) {
            throw new Error("Pedido vazio"); 
        }
        
        let total = 0;
        for (const i of order.items) {
            total += i.price * i.qty;
        }
        
        order.total = total;
        this.repo.save(order);
        this.notifier.send("Novo pedido registrado", order.customerEmail);
    }
}

class OrderService {    
    constructor(repo, notifier) {
        this.repo = repo;
        this.notifier = notifier;    
    }    
      
    process(order) {
        if (!order.items || order.items.length === 0) {
            throw new Error("Pedido vazio"); 
        }
        
        let total = 0;
        for (const i of order.items) {
            total += i.price * i.qty;
        }
        
        order.total = total;
        this.repo.save(order);
        this.notifier.send("Novo pedido registrado", order.customerEmail);
    }
}

Depois: mais legível, mais testável, ainda simples. Zero over-engineering.

class OrderCalculator {    
	calculate(order) {        
		return order.items
			.map(i => i.price * i.qty)        
			.reduce((a, b) => a + b, 0);    
	}
}

class OrderService {    
	constructor(repo, notifier, calculator) {
		this.repo = repo;        
		this.notifier = notifier;        
		this.calculator = calculator;    
	}    

	process(order) {        
		if (!order.items?.length) {            
			throw new Error("Pedido vazio");        
		}        

		order.total = this.calculator.calculate(order);        
		this.repo.save(order);        
		this.notifier.send("Novo pedido registrado", order.customerEmail);    
	}
}

class OrderCalculator {    
	calculate(order) {        
		return order.items
			.map(i => i.price * i.qty)        
			.reduce((a, b) => a + b, 0);    
	}
}

class OrderService {    
	constructor(repo, notifier, calculator) {
		this.repo = repo;        
		this.notifier = notifier;        
		this.calculator = calculator;    
	}    

	process(order) {        
		if (!order.items?.length) {            
			throw new Error("Pedido vazio");        
		}        

		order.total = this.calculator.calculate(order);        
		this.repo.save(order);        
		this.notifier.send("Novo pedido registrado", order.customerEmail);    
	}
}

Nada rebuscado. Apenas **separação de responsabilidades** — e o código já respira.

O preço de fingir que legibilidade não importa

Ignorar legibilidade tem custos claros:

Retrabalho constante porque ninguém entende o impacto das mudanças
Testes frágeis e lentos
Onboarding demorado de novos devs
Arquiteturas que viram museus de remendos

Mas também há o custo de limpar: tempo, disciplina e alinhamento da equipe. A diferença? Esse investimento paga dividendos.

Direto das Trincheiras

Regra prática: se você precisa explicar oralmente o que o código faz, o código está errado.
Não tente salvar tudo de uma vez. Limpeza progressiva vence refatorações gigantes.
Dívida técnica não é pecado. Pecado é fingir que ela não existe.

Fontes

Obrigado por acompanhar essa reflexão até o fim!

Espero que esses pontos ajudem você a tomar decisões mais lúcidas no seu próximo projeto. Não deixe de conferir outros artigos aqui no blog, onde descascamos outros “hypes” da nossa área.

Valeu e até a próxima! 😉

Kafka vs RabbitMQ: a verdade nua sobre escalabilidade em microserviços

Chega de romantizar mensageria. Quando o sistema começa a chiar, fila travando e consumidor engasgando, é aí que o arquiteto leva culpa. Kafka e RabbitMQ não são mágicos, têm propósitos distintos — e escolher errado vira dívida técnica que assombra por anos. Neste artigo, trago a visão de trincheira: onde cada um brilha, onde cada um quebra, e quando abandonar o hype e focar no que realmente resolve o problema do negócio.

Banco de dados

Mensageria em Microssistemas: Quando Ela Entrega Valor — e Quando Só Aumenta Sua Dívida Técnica

A verdade nua e crua: muita gente coloca mensageria em microserviços porque viu num diagrama bonito no slide do arquiteto da moda. Só que hype não paga boleto — e muito menos salva sistema mal modelado. Aqui eu explico onde a mensageria realmente resolve dor de negócio, quando ela vira over-engineering e como implementar sem transformar sua stack em um zoológico distribuído impossível de manter.

Discussões

A Ilusão do Low‑Code: Quando a Promessa de Velocidade Destrói Sua Arquitetura

Low‑code funciona… até o dia em que você precisa entender o que realmente está acontecendo lá dentro. Como arquiteto nas trincheiras, já vi mais projetos ruírem por dependência cega em plataformas mágicas do que por falta de framework moderno. Neste artigo, vou direto à dor: o low‑code vende eficiência, mas frequentemente entrega dívida técnica embrulhada para presente. Hora de desmontar o hype e mostrar onde ele realmente funciona — e onde vira armadilha arquitetural.