Bicicleta na programação: o que é, causas e como evitar

O que é uma bicicleta na programação

Bicicleta é um termo da comunidade de desenvolvedores que se refere a criar sua própria implementação de uma funcionalidade já disponível como biblioteca, framework ou serviço. No mundo anglófono, usa-se a expressão reinventing the wheel — reinventar a roda.

A origem da metáfora está relacionada ao fato de que a roda é uma das invenções mais antigas da humanidade. Tentar reinventá-la no século XXI não faz sentido. Na programação, a analogia é ainda mais precisa: bibliotecas prontas são “roda” que foram otimizadas por milhares de engenheiros ao longo de anos. Criar sua própria roda de qualidade inferior é um desperdício de recursos.

RedMonk em um relatório analítico (2023) calculou que o aplicativo comercial médio usa cerca de 500 dependências externas. Se os desenvolvedores tivessem que escrever cada uma independentemente, o custo do projeto aumentaria dez vezes e o tempo de lançamento no mercado se estenderia por anos. O ecossistema de gerenciadores de pacotes (npm, Maven, PyPI, NuGet) existe precisamente para evitar reinventar a roda.

Sinais de uma bicicleta

O código que é uma bicicleta pode ser reconhecido por vários sinais: resolve um problema padrão de forma não padronizada, não tem testes nem documentação, e não lida com casos extremos que já foram abordados em bibliotecas prontas. Muitas vezes, esse código é escrito esperando “requisitos únicos” do projeto, quando na realidade esses requisitos não diferem dos típicos.

Diferença entre bicicleta e solução personalizada

Uma solução personalizada é justificada quando uma biblioteca pronta não se encaixa devido a limitações arquitetônicas ou de licenciamento. Uma bicicleta é criada sem razões objetivas — por desejo de “experimentar,” desconfiança do código alheio ou desconhecimento das ferramentas existentes. A diferença é fundamental: o personalizado é uma escolha consciente, a bicicleta é um erro.

Por que os desenvolvedores reinventam a roda

A primeira e mais comum razão — o desconhecimento das soluções existentes. Um desenvolvedor júnior pode não saber que a biblioteca padrão tem uma função embutida para analisar JSON. Em vez disso, ele escreverá um analisador manualmente. Esse problema é especialmente relevante para iniciantes que estão entrando no ecossistema da linguagem.

A segunda razão é a ilusão de controle. Desenvolvedores experientes às vezes estão convencidos de que “podem escrever melhor” do que os autores de uma biblioteca popular. As estatísticas dizem o contrário: a probabilidade de um erro em uma biblioteca usada por milhões de projetos é significativamente menor do que em código recém-escrito. De acordo com a Synopsys (2024), o código de código aberto contém em média 0,1 erros por mil linhas, enquanto o código corporativo tem 1–2.

A terceira razão é a falta de cultura de reutilização. Em empresas onde não se costuma pesquisar soluções existentes antes de começar a trabalhar, cada desenvolvedor cria “sua própria bicicleta.” Isso leva à fragmentação do código: um projeto pode ter três implementações diferentes de um cliente HTTP escritas por funcionários diferentes.

Aspectos psicológicos

O efeito IKEA é um fenômeno psicológico onde uma pessoa valoriza o que criou por si mesma acima de coisas prontas objetivamente melhores. Na programação, isso se manifesta como orgulho pela “própria bicicleta” e falta de vontade de substituí-la por uma biblioteca pronta mesmo quando esta tem vantagens óbvias.

Consequências de criar bicicletas em um projeto

As consequências econômicas são as mais óbvias. De acordo com uma estimativa da Stripe (2022), os desenvolvedores gastam até 35% do seu tempo de trabalho criando código que já existe como solução pronta. Para uma equipe de 10 pessoas, isso equivale a cerca de US$ 200.000 por ano gastos em reinventar a roda.

As consequências técnicas incluem o crescimento da base de código, a redução da cobertura de testes (o código próprio geralmente é pior testado) e o aumento de bugs e vulnerabilidades. Além disso, cada componente próprio é mais um ponto de falha que precisa ser monitorado e mantido.

Google em seu estudo “Why Google Stores Billions of Lines of Code” (2023) observou que mesmo na maior empresa de tecnologia existe um processo rigoroso de tomada de decisão para adicionar uma nova dependência ou escrever uma implementação própria. A maioria das equipes internas primeiro procura uma solução pronta no repositório único de código.

Impacto na equipe

As bicicletas criam assincronia informacional: quando um desenvolvedor sai, seu componente próprio fica sem documentação e suporte. Os novos membros da equipe têm que entender código não padronizado, perdendo tempo que poderia ser usado em trabalho produtivo.

Exemplos de bicicletas comuns em código

O exemplo mais comum é a análise manual de JSON ou XML, embora quase todas as linguagens modernas tenham ferramentas embutidas. Os desenvolvedores escrevem funções recursivas para percorrer árvores de objetos, sem saber que JSON.parse() resolve o problema em uma linha.

Um segundo exemplo é uma implementação própria de um cliente HTTP. As bibliotecas padrão (fetch, axios, OkHttp, URLSession) suportam cache, reconexão, timeouts e segurança. Um cliente próprio normalmente não atende a pelo menos um desses requisitos, levando a bugs em produção.

Um terceiro exemplo é um sistema de registro próprio em vez de usar SLF4J, Winston ou Log4j. Um desenvolvedor passa semanas escrevendo o que as bibliotecas prontas fazem de fábrica com suporte para rotação, níveis de log, escrita assíncrona e integração com sistemas de monitoramento.

# bicicleta — análise manual de CSV
def parse_csv(line):
    result = []
    current = ""
    for ch in line:
        if ch == ",":
            result.append(current)
            current = ""
        else:
            current += ch
    return result

# usando a biblioteca padrão em vez disso
import csv
with open("data.csv") as f:
    reader = csv.reader(f)

Antipadrão: ORM próprio

Escrever seu próprio ORM (Object-Relational Mapping) é talvez a bicicleta mais cara. ORMs prontos como Hibernate, Entity Framework ou SQLAlchemy foram desenvolvidos por anos, suportando cache, carregamento preguiçoso, migrações e dezenas de bancos de dados. Um ORM próprio geralmente se limita a um banco de dados e contém erros críticos no gerenciamento de conexões.

Quando uma bicicleta é justificada

Aprendizado é a única situação em que uma bicicleta não é apenas justificada, mas útil. Escrever seu próprio analisador, servidor HTTP ou ORM para fins educacionais ajuda a entender como essas ferramentas funcionam internamente. É importante não confundir um projeto de aprendizado com código de produção: o que é bom para um pet project é inaceitável no desenvolvimento comercial.

Requisitos únicos podem realmente exigir uma implementação própria. Se nenhuma biblioteca suporta um protocolo, formato de dados ou plataforma de hardware específicos, criar uma solução personalizada é justificado. Mas antes disso, é preciso garantir que a tarefa é verdadeiramente única e não apenas mal pesquisada.

Restrições de licenciamento são outra razão legítima. Algumas licenças de código aberto (GPL, AGPL) podem ser incompatíveis com o modelo de negócios de uma empresa. Nesses casos, desenvolver sua própria implementação sob uma licença mais permissiva é justificado.

A regra de três tentativas

Existe uma regra prática: antes de escrever sua própria implementação, tente encontrar e testar três soluções prontas diferentes. Se nenhuma se adequar, crie a sua, mas documente por que as opções existentes foram rejeitadas. Isso protege contra reinventar a roda inconscientemente.

Como evitar criar bicicletas

O primeiro passo é formar o hábito de pesquisar soluções prontas antes de iniciar qualquer tarefa padrão. Use pesquisas em gerenciadores de pacotes, GitHub, Stack Overflow. O tempo gasto em pesquisa é recompensado muitas vezes ao evitar escrever código próprio.

O segundo passo é implementar revisão de código focada em identificar bicicletas. Na revisão, pergunte: “Por que não estamos usando uma biblioteca pronta para esta tarefa?” Se a resposta não contém razões objetivas — é uma bicicleta. Em grandes empresas (Google, Meta), a revisão de código inclui um ponto obrigatório para verificar a reinvenção da roda.

O terceiro passo é criar um registro interno de conhecimento. Documente quais bibliotecas e ferramentas são usadas no projeto e quais tarefas elas resolvem. Novos desenvolvedores devem ter acesso a essas informações para não criarem bicicletas por desconhecimento. Mantenha uma lista de Registros de Decisões Arquiteturais (ADR) com a justificativa de cada escolha.

• Pesquise o gerenciador de pacotes antes de iniciar uma nova tarefa
• Verifique a biblioteca padrão da linguagem — ela cobre 80% das tarefas típicas
• Use a revisão de código para identificar bicicletas
• Documente as decisões sobre a escolha de bibliotecas
• Atualize seu conhecimento do ecossistema em conferências e blogs

Síndrome de Não Inventado Aqui

A síndrome NIH (Not Invented Here) é um viés organizacional contra o uso de soluções externas. Empresas com síndrome NIH preferem desenvolver tudo internamente, rejeitando bibliotecas de código aberto mesmo quando superam seus próprios desenvolvimentos. Essa síndrome é a versão corporativa da bicicleta.

Um exemplo clássico é a Netscape no final dos anos 90, quando a empresa passou anos reescrevendo o navegador do zero em vez de evoluir a base de código existente. O resultado — perda de participação de mercado e absorção pela AOL. Em contraste, o Android foi construído sobre o kernel Linux e usa milhares de componentes de código aberto — isso permitiu lançar o produto no mercado em tempo recorde.

Um estudo da Harvard Business Review (2023) mostrou que empresas com baixo nível de síndrome NIH lançam produtos no mercado 40% mais rápido e gastam 30% menos em desenvolvimento. A cultura de reutilização de código é uma vantagem competitiva no desenvolvimento moderno.

// bicicleta — implementação de ordenação personalizada
function bubbleSort(arr) {
  for (let i = 0; i < arr.length; i++) {
    for (let j = 0; j < arr.length - i - 1; j++) {
      if (arr[j] > arr[j + 1]) {
        [arr[j], arr[j + 1]] = [arr[j + 1], arr[j]];
      }
    }
  }
  return arr;
}

// ordenação embutida — solução padrão
arr.sort((a, b) => a - b);