Quebrando um problema grande em funções pequenas

Uma fábrica de máquinas, não um monstro de mil linhas

Seus algoritmos cresceram módulo após módulo: entrada, contas, decisões, laços, listas. Junte tudo num problema real e a tentação é escrever um bloco único de sessenta linhas, um monstro onde ninguém acha nada. A alternativa dos programadores experientes é pensar como uma fábrica: nenhuma fábrica tem uma máquina gigante que faz tudo; tem máquinas pequenas e especializadas, ligadas numa linha de montagem. Decompor é isso: olhar o problema e perguntar quais são as máquinas antes de escrever a primeira linha.

Tome um problema concreto: o relatório da cantina da escola. O programa precisa ler as vendas do dia, somar o total, calcular a média por venda e mostrar um resumo caprichado. Um iniciante ataca tudo de uma vez. Quem decompõe enxerga quatro máquinas: ler_vendas devolve a lista de valores; somar_total recebe a lista e retorna a soma; calcular_media recebe a lista e retorna a média; mostrar_resumo recebe total e média e imprime o relatório. Repare que as três primeiras são funções com retorno e a última é um procedimento: cada peça do módulo no seu lugar.

// programa principal do relatório da cantina
vendas <- ler_vendas()
total <- somar_total(vendas)
media <- calcular_media(vendas)
mostrar_resumo(total, media)
// quatro linhas que se leem como um resumo do problema

O programa principal é o chef: comanda as máquinas na ordem e cabe numa tela.

O método da decomposição, passo a passo

A decomposição tem um método que funciona para qualquer tamanho de problema. Comece lendo o enunciado e listando as tarefas grandes em português, sem pensar em código. Dê a cada tarefa um nome de verbo que caberia num botão: ler_vendas, calcular_media. Escreva as funções uma por vez, da mais simples para a mais difícil, e teste cada uma sozinha com valores conhecidos: calcular_media com a lista 10, 20 e 30 tem que retornar 20, e você sabe disso antes de rodar. Só então monte o programa principal chamando as máquinas na ordem, e feche testando o conjunto de ponta a ponta.

O passo de testar cada função sozinha merece destaque, porque é ele que transforma a decomposição em superpoder de caça a bugs. Se o relatório da cantina sai com a média errada, o monstro de sessenta linhas obriga você a reler tudo. Na versão decomposta, você testa calcular_media isolada em trinta segundos: se ela devolve 20 para a lista 10, 20 e 30, a máquina está inocente e a suspeita muda de lugar. Investigar quatro máquinas pequenas é mais rápido que investigar um monstro, pela mesma razão que o mecânico testa peça por peça em vez de desmontar o carro inteiro.

Uma responsabilidade por máquina

Falta o critério de corte: o que faz uma divisão ser boa? A resposta clássica é a responsabilidade única: cada função deve fazer UMA coisa, e o nome deve contar qual é. Um teste prático é tentar descrever a função sem usar a palavra “e”. Se a descrição sai “calcula a média E mostra o relatório E salva no histórico”, são três máquinas grudadas pedindo separação. Máquinas de uma responsabilidade só são fáceis de nomear, fáceis de testar e fáceis de reaproveitar, o assunto da última aula deste módulo.