Funções pequenas e o princípio de não se repetir

Uma função, uma coisa

No módulo de decomposição você aprendeu a quebrar um problema grande em funções. Agora refinamos essa ideia com uma regra de tamanho: cada função deve fazer uma coisa só. Uma função que calcula a média, valida a nota e imprime o boletim faz três coisas, e por isso é difícil de entender, de testar e de reaproveitar. Quebrada em três funções, cada uma com um nome honesto, tudo melhora: você lê o programa principal como um resumo, testa cada parte isolada, e reusa a função de média em outro lugar sem carregar a impressão junto. O teste prático é o da conjunção: se você não consegue descrever o que a função faz sem usar a palavra e, ela provavelmente deveria ser mais de uma. Funções pequenas não são um capricho estético; elas são a unidade que a mente humana consegue segurar de uma vez.

A função gigante, aquela de duzentas linhas que faz de tudo, é um dos maiores inimigos da manutenção. Para entendê-la, você precisa segurar todas as suas partes na cabeça ao mesmo tempo, o que é exaustivo e propenso a erro. Para mudar uma parte, você teme quebrar outra, porque tudo está entrelaçado. E para testar, não dá para isolar nada. Quebrar essa função em pedaços pequenos, cada um com uma responsabilidade clara, desfaz esses três problemas de uma vez. Não existe um número mágico de linhas, mas a intuição é boa: se a função não cabe numa tela, ou se você precisa rolar e anotar para acompanhá-la, ela provavelmente está pedindo para ser dividida.

Não se repita: o princípio DRY

O segundo hábito é evitar a duplicação, resumido na sigla DRY, do inglês não se repita. A ideia é simples: quando o mesmo trecho de lógica aparece em dois, três ou mais lugares do código, isso é um sinal de alerta. O problema da duplicação não é o espaço que ela ocupa; é a manutenção. Imagine que a regra de calcular o frete está copiada em cinco telas diferentes. No dia em que o frete mudar, alguém vai ter que achar e corrigir as cinco cópias, sem esquecer nenhuma. Uma esquecida vira um bug: uma tela cobrando o frete antigo, e ninguém entende por quê. A solução DRY é escrever a regra do frete uma única vez, numa função calcular_frete, e chamá-la nas cinco telas. Agora, se o frete mudar, você corrige um lugar só, e as cinco telas mudam juntas, automaticamente. Não se repetir transforma cinco pontos de falha em um ponto de verdade.

// RUIM (repetido): a mesma conta de frete em vários lugares
totalA <- precoA + (precoA * 0.02)
totalB <- precoB + (precoB * 0.02)
totalC <- precoC + (precoC * 0.02)

// DRY: a regra do frete numa função, chamada onde precisar
função comFrete(preco)
  retorne preco + (preco * 0.02)
fim
totalA <- comFrete(precoA)
totalB <- comFrete(precoB)
totalC <- comFrete(precoC)
// se o frete mudar de 0.02 para 0.03, corrige-se UM lugar

A versão DRY concentra a regra numa função. Mudar o frete vira uma correção num lugar só, não três.

DRY com bom senso

Como todo bom princípio, o DRY pede bom senso e não fanatismo. Nem toda repetição precisa virar função na hora; duas linhas parecidas que por acaso se assemelham, mas representam ideias diferentes, podem ser deixadas em paz, porque forçá-las numa função só as amarraria sem motivo. A pergunta certa não é as linhas são iguais?, e sim elas representam a MESMA regra ou ideia? Se sim, e se essa regra pode mudar, centralize-a: aí a duplicação é perigosa. Se são só coincidências passageiras, talvez juntá-las crie um acoplamento artificial. Uma regra prática dos programadores é a do três: na terceira vez que você copia o mesmo trecho de lógica de verdade, é hora de extrair uma função. Antes disso, tolere; a partir dali, a duplicação começa a cobrar caro na manutenção. O DRY, bem aplicado, é sobre ter uma única fonte de verdade para cada regra do seu programa.