Um cálculo de frete para testar o critério

O exemplo abaixo é original e didático, não foi retirado do livro. Considere uma loja fictícia: um pedido com subtotal de pelo menos 20.000 centavos recebe frete gratuito; abaixo disso, o frete custa 1.500 centavos. O total resulta da soma dos dois valores. Não há descontos, impostos ou integração externa nesse recorte.

Uma primeira implementação pode concentrar tudo em process(order): somar itens, verificar o limite, cobrar e enviar email. Extrair o cálculo cria uma fronteira útil porque permite discutir a regra sem executar uma cobrança. A versão mínima abaixo usa Python 3, sem dependências. Ao executá-la, todas as verificações passam e o programa termina sem saída:

FREE_SHIPPING_THRESHOLD_CENTS = 20_000
STANDARD_SHIPPING_CENTS = 1_500


def shipping_cents(subtotal_cents: int) -> int:
    if subtotal_cents < 0:
        raise ValueError("subtotal must be nonnegative")
    if subtotal_cents >= FREE_SHIPPING_THRESHOLD_CENTS:
        return 0
    return STANDARD_SHIPPING_CENTS


def total_cents(subtotal_cents: int) -> int:
    return subtotal_cents + shipping_cents(subtotal_cents)


assert total_cents(0) == 1_500
assert total_cents(19_999) == 21_499
assert total_cents(20_000) == 20_000
assert total_cents(25_000) == 25_000

try:
    total_cents(-1)
except ValueError:
    pass
else:
    raise AssertionError("negative subtotal was accepted")

O caso 19.999 torna o limite observável. Testar apenas um pedido muito barato e outro muito caro deixaria a comparação > versus >= sem proteção direta. Já o caso zero registra uma decisão potencialmente estranha: um pedido vazio ainda paga frete. O código reproduz a regra anunciada; a equipe precisaria perguntar ao responsável pelo produto se esse comportamento faz sentido antes de colocá-lo em produção.

A extração vale porque shipping_cents apresenta um conceito que pode ser explicado de forma independente. Criar ainda is_high_enough, get_standard_value e add_values fragmentaria um cálculo que já cabe na memória de quem lê. As linhas seriam menores, mas a navegação aumentaria. Minha preferência aqui é manter a comparação e seu resultado próximos.

As asserções verificam somente esses exemplos. Elas não demonstram equivalência com um checkout existente, não validam tipos em tempo de execução e não modelam múltiplas moedas. Também não resolvem idempotência, preço alterado durante a compra, persistência ou falhas do provedor de pagamento. O ganho de clareza é local e deve ser descrito assim. Em uma refatoração real, seria necessário proteger o comportamento anterior antes de substituir o cálculo.

Um exemplo organizado tampouco resolve sozinho uma discussão arquitetural. O mesmo cálculo pode precisar de outra fronteira quando várias políticas de preço mudam independentemente ou quando um contrato público precisa manter compatibilidade. A mudança necessária no sistema deve orientar os pontos de extensão, em vez de requisitos hipotéticos.

Comentários e testes precisam preservar informação

Um comentário como "soma o frete ao subtotal" adiciona pouco ao retorno de total_cents. Um comentário que registra a razão comercial do limite, com referência à decisão correspondente, pode evitar que alguém o "corrija" meses depois. A distinção depende da informação que o código consegue expressar. Nomes descrevem operações; nem sempre registram por que uma restrição existe.

Eu teria especial cuidado com protocolos, algoritmos e compatibilidade. Remover uma nota sobre um comportamento defeituoso de um fornecedor pode apagar a justificativa de uma condição aparentemente redundante. O custo de manter o comentário deve ser comparado ao custo de redescobrir essa decisão. Documentação que descreve contrato público também atende a quem não deve precisar ler a implementação.

Os testes, por sua vez, ajudam a tornar explícito o que a revisão deseja preservar. No exemplo, os nomes revelam as unidades, enquanto os casos revelam o limite. Se cada auxiliar privado recebesse seu próprio teste rígido, mudar a decomposição poderia quebrar a suíte sem alterar o resultado. Eu privilegiaria contratos observáveis e reservaria testes internos para lógica que justifique uma verificação independente.

Onde a leitura exige resistência

O ponto mais discutível é transformar tamanho de função em substituto de simplicidade. Uma rotina curta pode depender de vários conceitos externos; uma rotina um pouco maior pode apresentar uma sequência coesa. Meu critério seria observar quantos detalhes o leitor precisa carregar para fazer uma alteração específica. Contar linhas não resolve essa avaliação.

Essa discordância tem um interlocutor identificável. John Ousterhout declara diferenças com Martin sobre extensão de métodos e comentários na página de A Philosophy of Software Design. Eu recomendo confrontar as duas perspectivas usando o mesmo trecho do seu projeto. Se uma extração acrescenta uma interface e deixa o chamador dependente de todos os detalhes internos, a melhoria precisa ser demonstrada.

Há também o contexto de uma obra de 2008, fortemente associada a exemplos de orientação a objetos e Java. Transportar sua organização para código funcional, pipelines de dados ou uma rotina com requisitos de desempenho exige adaptação. Objetos extras e chamadas adicionais podem ser adequados em um serviço e inconvenientes em outro contexto. Qualquer afirmação sobre desempenho pede medição representativa; o livro não dispensa esse trabalho.

Outra limitação da recomendação indiscriminada é o momento da equipe. Um sistema sem testes, com entrega urgente e comportamento desconhecido, precisa de uma estratégia segura de mudança. Uma limpeza ampla pode consumir a janela de entrega e introduzir regressões. Melhor escolher um ponto necessário à alteração atual, registrar o contrato e manter o diff revisável. Código limpo não autoriza reescrita ilimitada.

Quem deveria ler agora

Recomendo a leitura para quem já consegue implementar funções, entender chamadas e escrever testes simples, mas encontra dificuldade para explicar decisões em revisão. Um projeto pequeno existente é suficiente para acompanhar os argumentos; experiência com incidentes ajuda a reconhecer efeitos escondidos. A senioridade importa menos que ter código concreto para questionar.

Para quem ainda está aprendendo sintaxe e depuração, eu adiaria uma leitura integral. Praticar programas pequenos e testes torna a discussão menos abstrata. Para pessoas experientes, o retorno tende a estar na revisão dos critérios da equipe: quais regras realmente reduzem erros, quais apenas reproduzem o gosto de alguém e quais ignoram as particularidades da linguagem?

Na série, minha ordem sugerida depende da dificuldade atual. Se você concorda com o objetivo de melhorar o código, mas não sabe conduzir mudanças pequenas, avance para Refactoring. Se o principal obstáculo é alterar código sem proteção, priorize Working Effectively with Legacy Code. Para questionar se a decomposição reduziu complexidade, leia A Philosophy of Software Design. São funções diferentes na sua formação, e as comparações ajudam a evitar uma preferência única para todo problema.

Como transformar a leitura em trabalho verificável

Leia um tema por vez e mantenha um registro com quatro campos: trecho problemático, dúvida do leitor, mudança proposta e evidência esperada. Comece por um nome ambíguo em código que você já precisa alterar. Depois experimente separar um cálculo de um efeito externo. Essa sequência permite perceber benefícios e custos antes de propor uma convenção para o repositório inteiro.

Em cada experimento, peça a outra pessoa que descreva entradas, saídas e efeitos antes e depois. Verifique os mesmos casos de comportamento, incluindo limites e erros relevantes. Registre também o que piorou: mais navegação, interface adicional ou dificuldade para localizar a regra. Um relato honesto desses custos vale mais que declarar o trecho "limpo".

Meu veredito é favorável com esse método de leitura. Clean Code oferece um vocabulário fértil para discutir manutenção e incentiva atenção a decisões pequenas que acumulam custo. Sua utilidade diminui quando heurísticas viram ordens sem contexto. Vale ler com um editor e um projeto abertos, pronto para explicar tanto uma melhoria quanto uma discordância. O resultado desejável é uma equipe capaz de justificar mudanças com mais precisão.