Dividir para conquistar: quebrar o problema grande

O grande assusta, o pequeno se resolve

Diante de um problema grande, iniciante congela e experiente sorri, porque conhece o truque mais antigo da resolução de problemas: não resolva o grande, quebre-o em pequenos. Organizar uma festa parece impossível como um bloco só, mas vira uma lista tranquila quando você separa em partes: mandar convites, comprar comida, escolher música, arrumar o local. Cada parte é simples; a festa inteira é só a soma delas. Programar funciona exatamente assim. Um programa de folha de pagamento parece um monstro, até você perceber que ele é feito de pedaços menores: calcular o salário bruto, descontar o imposto, somar os benefícios, gerar o holerite. Cada pedaço é uma função do tamanho da sua cabeça.

A decomposição é onde as funções que você estudou no módulo anterior mostram todo o valor. Cada subproblema vira uma função com um nome que diz o que ela faz e um trabalho bem delimitado: calcularImposto, montarMensagem, validarEmail. O programa principal deixa de ser um paredão de instruções e vira uma sequência legível de chamadas, quase um resumo em português do que acontece. Quem lê entende o todo sem se afogar nos detalhes, e quem conserta um bug sabe exatamente em qual função mexer. Escrever um programa grande sem decompor é como escrever um livro sem capítulos: até dá, mas ninguém acha nada, nem você.

De cima para baixo: pensar antes de escrever

Uma forma prática de decompor é pensar de cima para baixo. Comece pelo problema inteiro e pergunte: quais são as três ou quatro grandes partes disto? Escreva o programa principal como se essas partes já existissem, chamando funções que você ainda nem criou: primeiro calcule o salário bruto, depois desconte os impostos, depois some os benefícios. Nesse momento você está projetando, não codando os detalhes. Só depois você desce e resolve cada função, e, se alguma ainda for grande, aplica a mesma quebra dentro dela. Essa abordagem tem uma vantagem enorme: você organiza o raciocínio antes de se perder nas minúcias, exatamente o passo planejar do método dos quatro passos que abriu o curso.

// o programa principal lê como um resumo do que acontece:
função gerarHolerite(funcionario)
  bruto <- calcularSalarioBruto(funcionario)
  impostos <- calcularImpostos(bruto)
  beneficios <- somarBeneficios(funcionario)
  liquido <- bruto - impostos + beneficios
  retorne montarHolerite(funcionario, bruto, impostos, liquido)
fim
// cada função chamada é um subproblema resolvido à parte

O programa principal vira um resumo legível: cada linha delega um subproblema a uma função com nome claro.

O tamanho certo de cada função

Uma dúvida natural: até onde dividir? A regra prática que os programadores seguem é que cada função deve fazer UMA coisa, e fazê-la bem. Se você não consegue descrever o que uma função faz sem usar a palavra e (ela calcula o imposto E monta o relatório E envia o e-mail), ela provavelmente deveria ser mais de uma função. Por outro lado, não é preciso exagerar e criar uma função para cada linha; o objetivo é legibilidade, não fragmentação. O bom tamanho é aquele em que a função cabe na sua cabeça de uma vez e tem um nome honesto. Essa disciplina, que você vai aprofundar no módulo de código limpo, começa aqui, na hora de decidir como quebrar o problema.