Resumo

Este gerador de relatório com IA estima quanto tempo um novo engenheiro demora a entregar o primeiro PR relevante, e quão arriscada é uma codebase para trabalhar, a partir de cinco dados: linhas de código, colaboradores ativos, cobertura de testes, idade da codebase e estilo de tipagem. A fórmula é uma heurística transparente baseada em estudos publicados sobre revisão de código e inquéritos a programadores (Google/SmartBear, relatório Developer Coefficient da Stripe) - não é uma caixa preta. Tudo corre no browser; nada sobre a tua codebase é enviado para lado nenhum.

Um gerador de relatório com IA para onboarding e risco de código

Introduz linhas de código, cobertura de testes, tamanho da equipa e idade. Recebe um relatório em português claro que podes colar numa descrição de PR ou numa thread do Slack - sem registo, sem chamadas ao servidor.

Experimenta agora

Gerador de Relatório de Codebase com IA

Introduz os dados da tua codebase abaixo. O relatório atualiza-se em tempo real e podes copiá-lo como texto simples.

Tempo de onboarding estimado -
Pontuação de risco da codebase - -

O que corrigir primeiro

    Como funciona o relatório

    O que entra na estimativa

    Tamanho e cobertura

    O tempo de onboarding escala com as linhas de código e piora visivelmente abaixo dos 50% de cobertura de testes - revisores e novos contratados acabam a ler a implementação linha a linha em vez de confiar na suite de testes para saber o que ainda funciona.

    Capacidade da equipa

    Equipas com menos de 5 colaboradores ativos não têm rede de segurança informal - uma pergunta sem dono óbvio fica pendente numa DM durante um dia. A partir de cerca de 15 colaboradores, a capacidade de mentoria deixa de ser o gargalo e a própria codebase passa a ser o fator limitante.

    Idade e tipagem

    Codebases com mais de 3 a 7 anos acumulam conhecimento tribal que nunca chegou a comentários ou documentação - convenções de nomenclatura, módulos obsoletos que ninguém apagou, contornos para bugs já corrigidos noutro sítio. A tipagem estática (TypeScript, Go, Rust, Java) reduz o tempo de adaptação face a linguagens dinâmicas porque os tipos funcionam também como documentação.

    Lê o ambiente antes de atribuíres o ticket

    Uma pontuação de risco é o ponto de partida para uma conversa com a tua equipa sobre onde estão os verdadeiros gargalos, não um veredicto gravado em pedra - usa-a para decidir o que corrigir antes do próximo contratado começar, não para ordenar engenheiros.

    Close-up of hands typing on a keyboard with a laptop screen showing blurred abstract report widgets

    Perguntas frequentes

    Isto é gratuito?
    Sim. O gerador de relatório corre inteiramente no teu browser - não há registo, não há paywall e nenhum dado é enviado a um servidor para calcular a estimativa.
    De onde vêm estes valores de referência?
    A fórmula é uma heurística transparente, não um modelo revisto por pares. A recomendação sobre o tamanho das revisões (manter PRs abaixo de cerca de 400 linhas, com a eficácia a cair ao fim de cerca de 60 minutos de leitura contínua) vem da documentação de práticas de engenharia da Google e do estudo de revisão de código da SmartBear/Cisco. A dimensão das penalizações de cobertura e de dívida técnica segue o relatório Developer Coefficient da Stripe, que concluiu que os engenheiros passam uma grande parte da semana a lidar com código mau e trabalho de manutenção. Chamamos-lhe heurística de propósito - trata o número como direcional, não exato.
    Os dados da minha codebase são enviados para algum lado?
    Não. Cada valor que introduzes fica no teu browser e o cálculo corre em JavaScript no teu dispositivo. A única atividade de rede é um ping anónimo de utilização da ferramenta, sem qualquer detalhe da tua codebase associado.
    Isto substitui um plano de onboarding a sério?
    Não. Dá-te um número de partida para planear - uma contagem de dias aproximada e um nível de risco. Combina-o com uma checklist de onboarding real, um mentor atribuído e uma lista de leitura da primeira semana construída a partir do teu próprio repositório.
    Porque é que a minha pontuação de risco saiu mais alta do que esperava?
    Três fatores fazem-na subir mais depressa: cobertura de testes abaixo dos 30%, uma codebase com mais de 7 anos e uma proporção elevada de linhas de código por engenheiro. Verifica esses três primeiro - são normalmente os que consegues mesmo corrigir este trimestre.
    E se o meu repositório for um monorepo com várias linguagens?
    Faz as contas para a linguagem e a área que um novo contratado vai realmente tocar primeiro, não o monorepo inteiro. Um monorepo de 2 milhões de linhas onde um júnior só trabalha num serviço de 40 mil linhas deve ser avaliado nesse serviço, não no repositório completo.
    Posso usar isto também para planear capacidade de code review?
    Em parte. A pontuação de risco está correlacionada com a carga de revisão - uma codebase de risco elevado costuma significar revisões mais lentas e mais caras - mas não substitui medir o tempo de ciclo real dos teus PRs no teu próprio painel de métricas.
    Qual a diferença entre a pontuação de risco e a estimativa de onboarding?
    O tempo de onboarding responde a quanto tempo até um novo engenheiro ser produtivo. A pontuação de risco responde a quão frágil é a codebase em geral - cobertura de testes baixa e uma codebase envelhecida e concentrada aumentam o risco mesmo para engenheiros que já lá estão há anos.

    Transforma este relatório num deck de onboarding

    O Skywork transforma notas soltas em slides, documentos e diagramas - útil para o pacote de onboarding que ninguém tem tempo de desenhar à mão quando um novo engenheiro começa na segunda-feira seguinte.