clean-code-resumo

Prévia do material em texto

R E S U M O D E L I V R O
Clean Code
Habilidades Práticas do Agile Software
Craftsmanship
Autor: Robert C. Martin ("Uncle Bob")
Documento: Resumo Capítulo por Capítulo
Data: Fevereiro de 2026
Sumário
1. Visão Geral do Livro
2. Capítulo 1 – Clean Code: o que é código limpo?
3. Capítulo 2 – Meaningful Names (nomes significativos)
4. Capítulo 3 – Functions (funções)
5. Capítulo 4 – Comments (comentários)
6. Capítulo 5 – Formatting (formatação)
7. Capítulo 6 – Objects and Data Structures
8. Capítulo 7 – Error Handling
9. Capítulo 8 – Boundaries (fronteiras)
10. Capítulo 9 – Unit Tests
11. Capítulo 10 – Classes
12. Capítulo 11 – Systems
13. Capítulo 12 – Emergence
14. Capítulo 13 – Concurrency
15. Capítulo 14 – Successive Refinement
16. Capítulos 16 e 17 – Refactoring e Smells
17. Ideias Gerais do Livro
18. Aplicação Prática para Estudantes
1. Visão Geral do Livro
3
1. Visão Geral do Livro
Informações do Livro
Atributo Detalhe
Título Clean Code: A Handbook of Agile Software Craftsmanship
Título em
Português
Código Limpo: Habilidades Práticas do Agile Software
Craftsmanship
Autor Robert C. Martin ("Uncle Bob")
Objetivo Ensinar a escrever código legível e mantenível
Objetivo Geral
O livro tem como propósito ensinar a escrever código que seja:
Fácil de ler e entender por outra pessoa
Fácil de modificar, estender e manter
Centrado em leitura humana, não apenas em "funcionar na máquina"
A ideia central: "Nós passamos muito mais tempo lendo código do que escrevendo
código. Então, o esforço principal deve ser tornar o código legível."
Estrutura do Livro
O livro é dividido em duas partes principais:
Parte I: Princípios de código (nomes, funções, comentários, formatação...)
Parte II: Estudos de caso de refatoração, com exemplos práticos
A seguir, apresenta-se um resumo capítulo a capítulo, focado nos pontos mais importantes
de cada seção.
2. Capítulo 1 – Clean Code: o que é código limpo?
4
2. Capítulo 1 – Clean Code: o que é código
limpo?
Neste capítulo introdutório, vários programadores experientes dão suas definições de
"código limpo". Ideias que aparecem recorrentemente incluem:
Limpo = elegante, eficiente, direto
Fácil de ler por outro desenvolvedor
Sem redundâncias nem "truques" desnecessários
Faz uma coisa bem feita (boa coesão, baixo acoplamento)
Código Ruim Custa Caro
O autor enfatiza que código mal escrito gera diversos problemas:
Difícil de entender
Difícil de modificar sem quebrar coisas
Gera "technical debt" que se acumula com o tempo
A Regra do Escoteiro
"Deixe o acampamento mais limpo do que você o encontrou."
Sempre que você mexe num módulo, tente deixá-lo um pouquinho melhor que estava. Esta
é uma filosofia fundamental para manter a qualidade do código ao longo do tempo.
Resumo Mental:
Código limpo não é só sobre "estar funcionando"; é sobre ser cuidadoso com quem vai
ler e manter o código depois.
3. Capítulo 2 – Meaningful Names (nomes significativos)
5
3. Capítulo 2 – Meaningful Names (nomes
significativos)
Nomes são super importantes porque são a primeira coisa que lemos no código. Este
capítulo apresenta regras essenciais para nomenclatura.
Regras Gerais
Nomes devem revelar a intenção
Ruim Bom
int d; // dias int diasDecorridos;
calcCustPrd calcularCustoProduto
Evitar abreviações obscuras
Abreviações que não são universalmente conhecidas dificultam a leitura. Prefira nomes
completos e claros.
Evitar nomes genéricos
Termos como data , info , manager , handler devem ser evitados a menos que façam
sentido no contexto específico.
Use nomes que possam ser buscados
Ruim Bom
Constantes mágicas: if (x(encapsulamento)
Exponhem dados (atributos
públicos)
Comportamento
Exponhem comportamento
(métodos)
Não têm comportamento
significativo
Dicas Importantes
Evitar "híbridos" que são meio objeto, meio estrutura de dados: tanto expõem dados
quanto têm lógica bagunçada
Lei de Demeter (simplificada)
Não "acessar" muitos objetos encadeados:
Ruim Bom
usuario.getEndereco().getCidade().getUF() usuario.getUF()
O encadeamento excessivo cria alto acoplamento e torna o código frágil.
Resumo Mental:
Objetos escondem dados e mostram comportamento. Estruturas de dados mostram
dados e não têm comportamento. Misturar os dois sem cuidado enfeia o design.
8. Capítulo 7 – Error Handling
13
8. Capítulo 7 – Error Handling
Tratamento de erro deve ser limpo também, não um monte de if s e flags espalhados.
Principais Pontos
Use exceções em vez de códigos de erro
Em vez de retornar -1 ou null , lance uma exceção quando algo der errado.
Exceções devem ter contexto
Inclua mensagens claras explicando o que aconteceu.
Não ignore exceções com catch vazio
Isso esconde problemas e torna debugging impossível.
Retornar null é convidar a NullPointerException
Prefira lançar exceção ou retornar um objeto "especial":
Optional (Java 8+)
Objeto nulo do pattern Null Object
Separe lógica de tratamento de erro
Evite que o fluxo principal fique poluído com verificações de erro.
Resumo Mental:
Erros fazem parte do sistema; trate-os de forma explícita e limpa. Não disfarce erro
com código mágico ou null.
9. Capítulo 8 – Boundaries (fronteiras/limites)
14
9. Capítulo 8 – Boundaries (fronteiras/limites)
Trata de lidar com código de terceiros (bibliotecas, frameworks, APIs).
Principais Ideias
Use interfaces para isolar seu código
Crie adaptadores/facades para não ficar acoplado diretamente a uma API de terceiros.
Escreva testes para entender a biblioteca
"Learning tests" – testes que servem para você aprender a API, não só para validar
comportamento.
Mantenha o código limpo mesmo com dependências externas
Não deixe as "idiossincrasias" da biblioteca vazar para todo o seu sistema.
Resumo Mental:
Fronteiras entre seu código e bibliotecas externas devem ser bem definidas. Não
deixe que detalhes de terceiros dominem seu design.
10. Capítulo 9 – Unit Tests
15
10. Capítulo 9 – Unit Tests
O livro é enfático: código sem testes não é limpo.
Pontos Principais
Testes são tão importantes quanto o código de produção
Devem ser tratados como cidadãos de primeira classe.
Leis do TDD (Test-Driven Development)
1. Você não pode escrever código de produção até que tenha um teste que falhe.
2. Você não pode escrever mais teste do que o suficiente para falhar (compilação também
conta como falha).
3. Você não pode escrever mais código de produção do que o suficiente para passar no
teste.
Testes devem ser
Legíveis
Fáceis de manter
Rápidos
Padrão Arrange-Act-Assert
Um teste deve ter um padrão claro:
Arrange (prepara)
Act (executa)
Assert (verifica)
Evite testes frágeis
Testes que quebram toda vez que você muda um detalhe interno da implementação. Teste
comportamento, não detalhes de implementação.
10. Capítulo 9 – Unit Tests
16
Resumo Mental:
Sem testes, você tem medo de mexer no código. Com bons testes, você ganha coragem
de refatorar e manter o código limpo.
11. Capítulo 10 – Classes
17
11. Capítulo 10 – Classes
Objetivo: classes coesas, pequenas, com uma única razão para mudar.
Princípios Abordados
Single Responsibility Principle (SRP)
Uma classe deve ter um, e apenas um, motivo para mudar.
Manter classes pequenas
Menos linhas
Menos responsabilidade
Coesão
Variáveis e métodos devem trabalhar juntos em um conceito coerente.
Organização
Variáveis privadas no topo
Métodos públicos depois
Métodos privados por último, próximos de onde são usados
Encapsulamento
Manter variáveis privadas e expor comportamento por métodos públicos.
Resumo Mental:
Classe limpa = pequena, coesa, com uma única responsabilidade, bem encapsulada.
12. Capítulo 11 – Systems
18
12. Capítulo 11 – Systems
Aqui o livro sobe o nível para pensar em arquitetura e construção de sistemas.
Pontos Importantes
Separar construção do uso
Separe a construção do sistema (inicialização, "wiring") do uso:
Use DI (Injeção de Dependência)
Factories
Containers
"Main" deve ser o único lugar "sujo"
Onde você faz o "glue" de tudo, mas o resto do sistema deve permanecer limpo.
Sistemas devem ser
Modulares
Desacoplados
Fáceis de testar
Aplicações escaláveis
Separação entre lógica de negócio e política de execução (threads, concorrência, etc.)
Resumo Mental:
Código limpo num sistema maior significa separar bem responsabilidades, isolando a
parte de "montagem" do sistema da regra de negócio.
13. Capítulo 12 – Emergence (emergência)
19
13. Capítulo 12 – Emergence (emergência)
Como o código limpo "emerge" de práticas repetidas.
Princípios Mencionados
Princípio Significado
DRY Don't Repeat Yourself (Não se repita)
KISS Keep It Simple, Stupid (Mantenha simples)
YAGNI You Aren't Gonna Need It (Você não vai precisar disso)
"Pragmatic Parsimony"
Não inventar coisas complexas antes de precisar.
Refatoração contínua
Você melhora o design aos poucos, com iterações. O design não precisa ser perfeito desde o
início, mas deve melhorar constantemente.
Resumo Mental:
Design bom nasce de aplicar princípios simples, evitar complexidade desnecessária e
refatorar sempre.
14. Capítulo 13 – Concurrency (concorrência)
20
14. Capítulo 13 – Concurrency (concorrência)
Concorrência adiciona complexidade; o livro discute alguns cuidados essenciais.
Cuidados com Concorrência
Separe lógica de concorrência da lógica de negócio
Isso facilita testar e entender cada parte.
Cuidado com
Deadlocks – quando dois processos esperam um pelo outro
Race conditions – quando a ordem de execução afeta o resultado
Problemas de performance
Use bibliotecas de alto nível
Use abstrações de alto nível sempre que possível, em vez de ficar brincando diretamente
com threads e locks o tempo todo.
Resumo Mental:
Concorrência é difícil; isole-a o máximo possível em camadas separadas e use
ferramentas/bibliotecas maduras.
15. Capítulo 14 – Successive Refinement
21
15. Capítulo 14 – Successive Refinement
O livro mostra um exemplo de código sendo refinado passo a passo.
Ideias Principais
Código quase nunca nasce perfeito
Ele é melhorado com refatorações pequenas e constantes.
A cada passo
Melhora nomes
Reduz tamanho de funções
Elimina duplicações
Separa responsabilidades
O processo é iterativo
Escreve → testa → refatora → repete
Resumo Mental:
Refatoração é parte essencial do trabalho de um desenvolvedor. Não tenha medo de
mexer no código se tiver bons testes.
16. Capítulos 16 e 17 – Refactoring e Smells
22
16. Capítulos 16 e 17 – Refactoring e Smells
Capítulo 16: Refactoring SerialDate
Um estudo de caso real, refatorando uma classe de data. Demonstra na prática como aplicar
os princípios do livro.
Capítulo 17: Smells and Heuristics
Lista de "cheiros de código" (code smells) e heurísticas para detectar problemas:
Code Smell Descrição
Métodos longos Funções com muitas linhas
Classes grandes Classes com muitas responsabilidades
Muitos argumentos Funções com mais de 3 parâmetros
Duplicação de código Código repetido em vários lugares
Comentários desnecessários Comentários que o código já diz
Nomes confusos Nomes que não revelam intenção
Feature Envy Classe que usa mais dados de outra classe
Inappropriate Intimacy Classes muito íntimas, acessando detalhes internos
Resumo Mental:
Esses dois capítulos praticamente resumem os problemas de design mais comuns e
como pensá-los de forma limpa.
17. Ideias Gerais que Atravessam o Livro
23
17. Ideias Gerais que Atravessam o Livro
Alguns temas aparecem constantemente ao longo de todas as páginas:
Legibilidade > Performance Prematura
Código legível e bem desenhado geralmente é mais fácil de otimizar depois.
Pequeno é Melhor
Funçõespequenas
Classes pequenas
Arquivos pequenos
Responsabilidade Única
Tanto em funções quanto em classes e módulos.
Baixo Acoplamento, Alta Coesão
Componentes devem ser independentes (baixo acoplamento) e focados em um propósito
(alta coesão).
Código Limpo é um Esforço Contínuo
Não é um estado final que você atinge e para
É uma disciplina diária
18. Como Aplicar na Prática (para Estudantes)
24
18. Como Aplicar na Prática (para Estudantes)
Algumas dicas práticas que estudantes de Ciência da Computação podem levar do livro:
1. Leia seu próprio código como se fosse de outra pessoa
Pergunte-se: "Se eu visse isso daqui a 6 meses, eu entenderia?"
2. Sempre pense em bons nomes
Gastar tempo escolhendo nomes não é perda, é investimento.
3. Escreva testes
Mesmo em trabalhos da faculdade, tente ter ao menos alguns testes unitários.
4. Refatore sempre que possível
Quando estiver revisando um TP ou projeto, vá tentando deixar as funções menores e mais
claras.
5. Use a Regra do Escoteiro
Quando entrar num código legado, tente pelo menos melhorar um nome ou quebrar uma
função enorme.
Isso é basicamente o coração do livro: código limpo = código que outras pessoas (e
você mesmo no futuro) conseguem ler, entender e modificar sem sofrimento.