DEV Community: Alex Sandro

O clean code não vai deixar sua aplicação mais veloz

Alex Sandro — Sat, 05 Jul 2025 18:30:19 +0000

Bora desmistificar uma parada que muita gente confunde: Clean Code não é sinônimo de código mais rápido.

Sim, você leu certo! Muita gente acha que seguir as melhores práticas vai automaticamente turbinar a performance da aplicação. Tenha calma meu pequeno gafanhoto não é bem assim que a banda toca.

Clean Code: Pra que serve então?

Pra começo de conversa, Clean Code é sobre deixar seu código legível, fácil de entender e de dar manutenção.

É como organizar seu quarto: não vai te fazer correr mais rápido, mas vai te ajudar a encontrar suas coisas rapidinho e a não tropeçar em nada. No mundo do código, isso significa menos bugs, menos dor de cabeça pra quem pega seu projeto e mais agilidade pra evoluir a aplicação.

A "velocidade" do código

Quando a gente fala em código rápido, estamos falando de performance. E a performance é medida em coisas tipo:

Tempo de execução: Quanto tempo leva pra sua função rodar?
Uso de memória: Quanta memória seu código consome?
Operações por segundo: Quantas operações seu sistema consegue fazer em um segundo?

Aí que tá o X da questão: Clean Code foca na legibilidade e manutenibilidade, não diretamente na performance. Às vezes, pra deixar o código super limpo e fácil de ler, a gente acaba fazendo umas "voltas" que podem, sim, custar uns milissegundos a mais ou usar um pouquinho mais de memória.

Vamos ver alguns exemplos.

GTA V na veia: Exemplos práticos em TypeScript

Vamos pegar o GTA V como nosso campo de testes imaginário. Pensa em algo que acontece o tempo todo no jogo: o sistema de tiro.

Exemplo 1: O código "sujo" e ultra-rápido

Imagina que a gente precisa calcular o dano de um tiro no GTA V. Esse código aqui não é o mais bonito do mundo, mas ele é direto e reto, feito pra ser rápido:

function calculateRawDamage(
    t: { x: number; y: number; z: number }, // Posição do alvo
    a: { x: number; y: number; z: number }, // Posição do atirador
    d: number, // Distância máxima de dano
    b: boolean, // É headshot?
    m: number // Dano base da arma
): number {
    const dx = t.x - a.x;
    const dy = t.y - a.y;
    const dz = t.z - a.z;
    const distSq = dx * dx + dy * dy + dz * dz; // Distância ao quadrado (evita sqrt)
    let damage = m;
    if (distSq > d * d) { // Compara distâncias ao quadrado
        return 0; // Fora do alcance
    }
    if (b) {
        damage *= 2.5; // Modificador de headshot
    }
    return damage;
}

// Exemplo de uso:
const enemyPosRaw = { x: 100, y: 50, z: 10 };
const playerPosRaw = { x: 105, y: 53, z: 11 };
const maxRangeRaw = 50; // Alcance máximo
const baseDamageRaw = 20; // Dano base

// Calculando o dano de um tiro normal
const normalDamageRaw = calculateRawDamage(
    enemyPosRaw,
    playerPosRaw,
    maxRangeRaw,
    false, // Não é headshot
    baseDamageRaw
);
console.log(`Dano (código sujo, normal): ${normalDamageRaw}`);
// Saída: Dano (código sujo, normal): 20

// Calculando o dano de um headshot
const headshotDamageRaw = calculateRawDamage(
    enemyPosRaw,
    playerPosRaw,
    maxRangeRaw,
    true, // É headshot
    baseDamageRaw
);
console.log(`Dano (código sujo, headshot):  ${headshotDamageRaw}`);
// Saída: Dano (código sujo, headshot): 50

Por que é mais rápido?

Nomes curtos: t, a, d, b, m economizam caracteres.
Cálculo direto de distância ao quadrado: Evita Math.sqrt, uma operação "cara".
Sem funções auxiliares: Menos "overhead" de chamadas de função.
Parâmetros "pelados": Evita custo de criação de classes/estruturas mais complexas.

Exemplo 2: O código Clean Code com Programação Funcional (e um pouquinho mais lento)

Agora, vamos abordar o mesmo problema de cálculo de dano com uma pegada funcional. A ideia é ter funções puras, que recebem entradas e retornam saídas sem efeitos colaterais, e compor essas funções para construir a lógica. (Eu sei senior em DDD! Com classes ficaria mais simples, mas eu sou team funcional e para explicar fica mais fácil ^^)

// Interfaces para tipagem clara
interface Position {
    x: number;
    y: number;
    z: number;
}

enum DamageType {
    Normal = 1,
    Headshot = 2.5 // Modificador de dano
}

// 1. Funções Puras e de Únicas Responsabilidades

// Calcula a distância euclidiana(Da um google) entre dois pontos
const calculateDistance = (p1: Position, p2: Position): number => {
    const deltaX = p1.x - p2.x;
    const deltaY = p1.y - p2.y;
    const deltaZ = p1.z - p2.z;
    return Math.sqrt(deltaX * deltaX + deltaY * deltaY + deltaZ * deltaZ);
};

// Aplica o modificador de dano
const applyDamageModifier = (baseDamage: number, damageType: DamageType): number => {
    return baseDamage * damageType;
};

// Verifica se o alvo está dentro do alcance
const isInRange = (distance: number, maxRange: number): boolean => {
    return distance <= maxRange;
};

// 2. Composição de Funções (a "Orquestração" da Lógica)

// Função que configura e retorna um calculador de dano específico para uma arma
const createWeaponDamageCalculator = (baseDamageWeapon: number, maxRangeWeapon: number) => {
    return (attackerPos: Position, targetPos: Position, damageType: DamageType): number => {
        const distance = calculateDistance(attackerPos, targetPos);

        if (!isInRange(distance, maxRangeWeapon)) {
            return 0; // Se fora do alcance, dano é zero
        }

        // Aplica o modificador de dano
        return applyDamageModifier(baseDamageWeapon, damageType);
    };
};


// Exemplo de uso:
const ak47DamageCalculator = createWeaponDamageCalculator(30, 500);
// AK-47 com 30 de dano, 500m alcance

const franklinPos = { x: 100, y: 50, z: 10 };
const enemyPos = { x: 120, y: 60, z: 12 };

const headshotDamagePF = ak47DamageCalculator(franklinPos, enemyPos, DamageType.Headshot);
console.log(`Dano (código funcional, headshot): ${headshotDamagePF}`);
// Saída: Dano (código funcional, headshot): 75

const normalDamagePF = ak47DamageCalculator(franklinPos, enemyPos, DamageType.Normal);
console.log(`Dano (código funcional, normal): ${normalDamagePF}`);
// Saída: Dano (código funcional, normal): 30

Por que é (potencialmente) mais lento (em alguns contextos)?

Múltiplas chamadas de função: Quebrar a lógica em várias funções puras aumenta o "overhead" de chamadas de função.
Math.sqrt: A função calculateDistance ainda usa Math.sqrt, que é mais custosa.
Criação de funções em tempo de execução: createWeaponDamageCalculator retorna uma nova função, o que pode ter um pequeno custo de alocação ou otimização JIT.
Imutabilidade: Embora implícita aqui, em cenários mais complexos da PF onde cópias imutáveis são feitas, o custo de memória e processamento pode aumentar. ## Moral da história

O Clean Code, seja ele orientado a objetos, funcional ou misto, foca na experiência do desenvolvedor, tornando o código mais agradável de trabalhar, entender e manter. Isso, a longo prazo, acelera o desenvolvimento e a manutenção do projeto. O código funcional, por sua natureza de funções puras e composição, facilita muito o teste unitário e a raciocínio sobre o fluxo de dados.

A performance, por outro lado, é uma preocupação mais específica, que geralmente é resolvida com otimizações pontuais (como o truque do distSq no primeiro exemplo) e um bom entendimento de como as coisas funcionam "por baixo dos panos".

Não se esqueça: o tempo do desenvolvedor é caro! Escrever código legível e fácil de dar manutenção geralmente vale muito mais a pena do que otimizar cada milissegundo, a menos que você esteja trabalhando em um contexto super específico onde cada ciclo de CPU conta (tipo um motor de jogo de alta performance ou sistemas embarcados). Na maioria dos casos, o Clean Code vai te poupar muitas horas de depuração e estresse.

Resumão pra não esquecer:

Clean Code = Legibilidade e Manutenibilidade. Pense em quem vai ler seu código.
Programação Funcional (PF) = Funções puras, imutabilidade, composição. Ótima para código testável e modular.
Performance = Velocidade e Eficiência. Medido em tempo de execução, uso de memória, etc.
Não são a mesma coisa! Código mais "limpo" e modular (como na PF) pode ser marginalmente mais lento devido a abstrações.
Priorize a legibilidade, sempre. Só otimize performance quando tiver um problema real e mensurável.
O tempo do dev é valioso. Código fácil de manter acelera o desenvolvimento.

Vamos falar sobre memory leak (Vazamento de ram)

Alex Sandro — Tue, 27 May 2025 19:10:37 +0000

Mas, que é o memory leak?

Imagina que você tá jogando Mario Kart e eu estou te amassando (com toda a humildade). Cada vez que um personagem usa um item (tipo casco vermelho, banana, cogumelo), o jogo precisa de um espacinho na "memória" pra fazer esse item funcionar.

Agora pensa assim:

O memory leak é tipo se o Mario jogasse um casco vermelho... e o casco nunca sumisse da pista. Ele bate, acerta, faz o que tem que fazer, mas continua lá, invisível, ocupando espaço. E aí o Luigi joga uma banana, o Yoshi usa turbo, e esses itens também nunca desaparecem de verdade.

Com o tempo, a pista vai ficando cheia de itens “fantasmas” que ninguém vê mais, mas que tão ali ocupando espaço e deixando o jogo mais lento ou até travando.

No mundo real dos códigos, isso acontece quando o programa usa memória pra alguma tarefa, mas esquece de liberar depois. A memória vai se enchendo igual a pista cheia de bug no Mario Kart, e uma hora... crasha!

Memory leak no app = crash em devices low end

Beleza, já entendemos que o memory leak é tipo deixar um monte de itens invisíveis ocupando espaço na pista do Mario Kart, né?

Agora pensa no seguinte: se você tá jogando isso num Nintendo Switch topzera, talvez ainda dê pra aguentar o tranco por um tempo. Mas se for num DS velho ou um emulador fraquinho, já era! Começa a travar, lagar e… crash!

Mesma coisa rola com apps em celulares low end (aqueles com pouca memória RAM). Se o app começa a vazar memória — ou seja, vai deixando várias coisas na RAM que não tão mais sendo usadas —, o sistema fica sem espaço, e o Android ou iOS pensa:

"Mano, esse app tá descontrolado. Vou derrubar ele antes que zoe tudo aqui."

Resultado?

App fecha do nada, o usuário fica irritado, e sua avaliação vai de 5 estrelas pra 1 em 3 segundos.

Em devices mais potentes, o sistema ainda aguenta o vacilo por um tempo. Mas nos low end, que já tão no limite, qualquer leak vira um problemão.

"Mas Alex, pode me dar um exemplo de como meus códigos causam isso?"

Claro meu querido, um dos erros mais comuns que vejo no React/Ts (Tec que eu uso) é não limpar listeners e coisas do tipo, abaixo um exemplo:

Memory Leak com `setInterval`

import { useState, useEffect } from "react";

function LeakyTimer() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    const interval = setInterval(() => {
      console.log(`O melhor código ^^`);
      setCount((prev) => prev + 1);
    }, 1000);
  }, []);

  return <p>Count: {count}</p>;
}

O que está vazando aqui?

O setInterval continua rodando mesmo depois que o componente sai da tela.
Cada vez que esse componente monta, um novo intervalo é criado, mas nunca é cancelado.
Isso significa que mesmo com o componente desmontado, o intervalo ainda está ativo na memória → memory leak.

Se o usuário navegar várias vezes para dentro e fora do componente, vários intervalos vão se empilhando — todos ativos, consumindo memória e CPU desnecessariamente.

Versão corrigida com `clearInterval`

import { useState, useEffect } from "react";

function SafeTimer() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    const interval = setInterval(() => {
      console.log("O melhor código agora melhor ainda ^^");
      setCount((prev) => prev + 1);
    }, 1000);

    // ✅ Limpa o intervalo ao desmontar → evita leak
    return () => {
      clearInterval(interval);
    };
  }, []);

  return <p>Count: {count}</p>;
}

Resultados

Bom, nesse artigo não vou te ensinar a procurar memory leaks (Comenta ai caso queira um artigo ou video de como podemos procurar leaks)

Dito isso, podemos ver nitidamente em ferramentas de Profiler (Nesse caso o xcode Instruments) o consumo de Ram e processamento antes e depois de corrigirmos leaks no nosso app

Build antes do fix:

Build depois do fix:

Estamos falando do mesmo app, com a mesma quantidade de recursos, mas apenas se importando com os listeners e recursos da ram é se eles de fato estão sendo liberados.

Sabemos que as vezes não conseguimos sempre validar todos os nossos casos de uso, e muitas vezes estamos no modo go horse pra entregas, mas se puder sempre dar uma checada nos seus profiles e da uma olhada na perfomance do app garanto que a perfomance do seu app tende a escalar muito.

Resumão pra não esquecer

Memory leak é tipo deixar item invisível ocupando espaço no Mario Kart: ninguém vê, mas tá ali pesando tudo. No código, isso acontece quando você usa memória e esquece de devolver. Com o tempo, o app começa a engasgar, travar e... crasha — principalmente em devices com pouca RAM.

Fica ligado nos seus setInterval, listeners, e tudo que pode ficar rodando sem necessidade. Usou? Limpou! Seu app (e seus usuários) agradecem. 🎮🔥

Por que a sua desorganização financeira vai acabar com a sua carreira de dev!

Alex Sandro — Wed, 31 Jan 2024 01:39:10 +0000

Pessoas desenvolvedoras em sua grande maioria não tem a menor noção do quão perigoso é não ter educação financeira básica.

Segundo o InfoDados, uma pessoa que ganha R$3.500 já está acima de 80% da população brasileira em receita. Mas como assim vemos tantas pessoas desenvolvedoras em redes sociais reclamando de falta de dinheiro?

1. Prólogo

Olá, tudo bem? Eu me chamo Alex e sou um desenvolvedor focado em JS, atualmente atuo com React Native, mas estou sempre ativo no mundo da web. Bom, hoje quero compartilhar com vocês um dos possíveis calcanhares de Aquiles de muitos devs JRs (especialmente no Brasil), a sua organização financeira ou desorganização financeira no caso.

“Mas Alex, o que eu estar no vermelho, ou sem uma reserva de emergência influencia no meu desempenho/desenvolvimento como dev?”

Dev Junior

Pra isso vamos ao decorrer desse artigo algumas situações e resoluções.

2. Problemática

Você já se pegou em alguma situação no seu atual emprego onde ficou pensando: “Cara, se eu não der conta de entregar isso em um prazo impossível, vou perder meu emprego!”, “Nesses últimos dias estou com um mental bem ruim, isso vai acabar me fazendo perder meu emprego” ou pior ainda “Estou em um ambiente de trabalho horrível mas não posso perder esse emprego”.

Bom, se essas frases acima ou alguma similar já passaram pela sua imaginação, e a sua atual situação financeira foi um checkmate para você continuar simplesmente as aceitando, saiba que isso está atrapalhando a sua evolução como desenvolvedor.

Bom, de certa forma é simples, você tem boletos a pagar e o medo de sujar o seu nome vai acabar não só te mantendo em empregos ruins, aceitando situações indesejadas, mas vai te impedir de evoluir.

Vamos a um exemplo do seu dia a dia:

Você trabalha diretamente com diretores e pessoas com cargos bem altos na empresa.;
Certo dia uma dessas pessoas te pede para fazer uma nova feature, você a analisa, pensa em como vai desenvolver e encontra várias brechas de segurança, usabilidade e coisas afins, mas você acha que não é capaz de desenvolver essa feature cumprindo todos os requisitos;
Você não leva essa informação pra frente, pois você pode estar preso no pensamento: “Puts, se eu chegar com um monte de falha que eu não sou capaz de corrigir posso acabar perdendo meu emprego!”.

Tendo essa situação acima, você:

Percebe como isso vai te travar em vários momentos?
Você não vai conseguir dizer um simples não para algo impossível pelo medo de perder o emprego?

Isso vai te manter preso em empregos horríveis, com jornadas de trabalhos irreais, vai te fazer arrumar um segundo emprego e acabar com a sua saúde mental simplesmente para você comprar aquele MacBook Pro antes da hora.

Se você não tem a sua vida financeira organizada, toda a sua jornada como dev vai estar comprometida, você vai ficar estagnado tendo que trabalhar muito pra simplesmente pagar contas, não vai conseguir investir seu tempo para evoluir na carreira.

Talvez você chegue ao nível de ter que mudar de um emprego bom para um emprego terrível por 500 reais a mais e isso simplesmente por conta de dívidas.

Tá entendendo onde eu quero chegar?

3. Reflexão

A sua organização financeira além de te ajudar em momentos difíceis como layoffs e coisas do tipo, vai te possibilitar dizer sim para novos desafios dentro e fora do seu atual trabalho.

Você vai poder aceitar novos desafios no seu trabalho atual sem medo de não conseguir entregar a demanda porque você vai ter dentro da sua consciência o famoso:

“Nem ligo se eu não conseguir entregar, se eu for demitido eu não preciso trabalhar por 1 ano.”

Dev Pleno

Você vai poder migrar para uma vaga no exterior sem preocupações se vai ou não vai dar conta, sabe o motivo?

“Aaaa se eu não der conta que se dane, eu tenho uma reserva de emergência para 1 ano todo”.

Dev Pleno

4. Conclusão

Bom, espero que isso te ajude, assim como me ajudou, e comece a partir de hoje a cuidar melhor do seu dinheiro.

Comenta ai embaixo sobre seus perrengues financeiros, e se eles atrapalharam na sua evolução como dev.

Caso queira me acompanhar por aí, me siga nas minhas redes, sinta-se livre para conversar comigo sobre o mundo do desenvolvimento e afins.

Github: Link
LinkedIn: Link
Instagram: Link

Isso é tudo pessoal, vejo vocês logo mais ^^