Quantas linhas deve ter um desenvolvimento
A resposta curta é: depende. A resposta longa, que realmente ajuda quem tá na prática, é que o tamanho do código não tem uma regra universal, mas tem uma série de indícios de que algo tá saindo do controle. Eu já vi time todo começar uma história com a métrica de que nenhuma função pode passar de 50 linhas. Achei bom no começo, tinha uma lógica. Depois vi que os devs só começaram a quebrar funções em outras funções menores, cada uma com 40 linhas, porque o linter não deixava passar. O resultado foi um código mais difícil de entender do que se deixassem tudo junto.
A resposta real sobre quantas linhas deve ter um desenvolvimento
Não existe um número mágico. O que eu vejo funcionando na vida real é pensar em termos de responsabilidade única, não de contagem de linhas. Um método que faz uma coisa só pode ter 200 linhas e ser perfeitamente legítimo. Um método que mistura três preocupações diferentes com 15 linhas é pior do que o outro. Quando comecei a trabalhar com sistemas de pagamento, precisei construir um validador de transações. Na primeira versão, tinha 47 linhas. Acha que é muito? Não. O validador precisava checar saldo, verificar bloqueios, aplicar regras de negócio por bandeira, calcular taxas, e levantar eventos. Tudo isso era uma única responsabilidade: decidir se a transação passa ou não. Se eu tivesse dividido em três métodos só para diminuir o tamanho, ninguém ganharia nada.
O problema real começa quando você identifica que um bloco de código tem mais de uma razão para mudar. Aí você parte pro refatoramento. E não é questão de linha, é questão de coesão.
O que realmente importa medir
Complexidade ciclomática é uma métrica muito mais útil do que contagem de linhas. Um método com 80 linhas e complexidade 2 é mais tranquilo de manter do que um com 30 linhas e complexidade 12, porque esse segundo provavelmente tá cheio de if encadeados e switch case que você precisa rastrear mentalmente toda vez que for mexer. Falando em complexidade, já passei por um caso onde um service inteiro de aprovação de crédito tinha 150 linhas mas era completamente linear. Sem condições aninhadas, sem loops complicados. Apenas uma sequência de chamadas síncronas. Na minha máquina local, isso rodava em 2 segundos. Quando foi para produção com carga real, comecei a ver timeouts. O gargalo não era o código, era que eu tinha colocado três chamadas HTTP encadeadas sem timeout configurado. O workaround foi adicionar um SemaphoreSlim limitado a 5 concorrentes e configurar o Timeout de 3 segundos em cada HttpClient. Resolvi o problema sem alterar uma linha do fluxo de negócio.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Pegadinhas que ninguém conta
O primeiro erro que vejo todo mundo cometendo é achar que teste unitário conta como linha de desenvolvimento. Não conta. Teste é uma outra coisa. Se você tiver 500 linhas de código de produção e 2000 de teste, o teste não diminui a complexidade do código principal. Outro erro comum é usar blocos try-catch gigantes só para esconder a falta de tratamento adequado de erro. Uma exceção genérica capturada e logada não significa que seu método ficou menor. Significa que você escondeu um problema que vai aparecer no pior momento possível.
Tem também aquela história de que código gerado automaticamente não conta. Em alguns times sim, em outros não. O importante é saber exatamente o que está sendo medido e por quê. Se ninguém te disse o critério, pergunte.
Quando o tamanho realmente vira problema
Eu tenho observado que o tamanho vira questão mesmo quando você perde a capacidade de fazer code review eficientemente. Um arquivo com mais de 800 linhas geralmente exige que o revisor abra em outra aba, faça scroll o tempo todo, e gaste duas vezes mais tempo do que gostaria. Isso não é uma regra absoluta, mas na prática é onde a maioria dos times começa a sentir dor. Aqui vai algo contra-intuitivo: às vezes juntar código é melhor do que separar. Já vi dev criar um helper novo pra cada passo de um processo, resultando em cinco arquivos com 30 linhas cada, quando dois arquivos com 120 linhas resolveriam o problema com muito mais clareza. A separação prematura é tão ruim quanto a aglomeração.
O único cenário onde eu recomendo rigidamente um limite de linhas é em classes de view ou componentes frontend. Lá, mais de 300-400 linhas geralmente indica que você tá misturando lógica de apresentação com lógica de negócio, e isso é um problema real de manutenção.
Alternativas que funcionam na prática
Se sua equipe tá sofrendo com métricas de linha, a alternativa que costuma funcionar é adotar uma revisão por tamanho apenas como gatilho para discussão, não como regra. Se alguém entrega um arquivo com mais de 400 linhas, o colega de revisão pergunta: isso poderia ser dividido? Se a resposta for não, tudo bem. Se a resposta for sim e ninguém dividiu, aí sim há trabalho a fazer. Esse approach eliminou a pressão de "atrapalhar a métrica" e manteve o foco na qualidade real do código. Eu implementei isso em dois projetos diferentes e vi o tempo de code review cair de uma média de 45 minutos para cerca de 20 minutos em menos de um mês, porque as pessoas pararam de justificar o tamanho e começaram a discutir o design.
