As Regras da Programação
Como criar códigos melhores
Descrição do livro
Este guia de filosofia da programação apresenta uma maneira única e divertida de como considerar a arte de programar. Uma coleção de 21 regras pragmáticas, cada uma apresentada em um capítulo autônomo, captura o conhecimento essencial que todo programador iniciante precisa ter e fornece insights instigantes para programadores mais experientes.
O autor Chris Zimmerman, cofundador do estúdio de videogames Sucker Punch Productions, ensina verdades básicas de programação enfeitando-as com aforismos memoráveis e colocando-as em prática com exemplos tirados de códigos reais. Este guia prático também ajudará os gerentes a procurar maneiras de treinar novos membros da equipe.
As regras deste livro incluem:
• O mais simples possível, mas não mais simples do que isso
• Deixe seu código contar sua própria história
• Isole a complexidade
• A generalização demanda três exemplos
• Trabalhe para trás a partir de seu resultado, e não para a frente a partir do código
• A primeira lição para a otimização é não otimizar
• Um bom nome é a melhor documentação
• Bugs são contagiosos
• Elimine casos de falha
• Código que não é executado não funciona
• Às vezes só precisamos martelar os pregos
Ver menos ▲Sumário
- Prefácio
- A História das Regras
- Como discordar das Regras
- Regra 1 ■ O mais simples possível, mas não mais simples do que isso
- Avaliação da simplicidade
- … Mas não mais simples do que isso
- Às vezes é melhor simplificar o problema e não a solução
- Algoritmos simples
- Não perca o rumo
- Uma Regra que regulamenta todas
- Regra 2 ■ Bugs são contagiosos
- Não dependa de seus usuários
- Os testes automatizados podem ser complicados
- Um código stateless é mais fácil de testar
- Audite o estado que não puder eliminar
- Não confie no chamador
- Mantenha seu código íntegro
- Regra 3 ■ Um bom nome é a melhor documentação
- Não otimize usando menos pressionamentos de teclas
- Não misture convenções
- Não dê um tiro no pé
- Não me faça pensar
- Regra 4 ■ A generalização demanda três exemplos
- YAGNI
- Uma objeção óbvia a essa estratégia, em resposta à qual eu dobro a aposta
- Na verdade, é pior do que o padrão YAGNI
- Eu não chamaria isso de sucesso
- Regra 5 ■ A primeira lição para a otimização é não otimizar
- Primeira lição da otimização
- Segunda lição da otimização
- Teste a segunda lição
- Etapa 1: Meça e atribua o tempo do processador
- Etapa 2: Verifique se não é um bug
- Etapa 3: Avalie seus dados
- Etapa 4: Planeje e crie um protótipo
- Etapa 5: Otimize e repita
- Aplicação do processo de otimização de cinco etapas
- Não existe terceira lição da otimização
- Interlúdio: no qual o capítulo anterior é criticado
- Regra 6 ■ Revisões de código são boas por três razões
- As revisões de código permitem compartilhar conhecimento
- Revisão de código proibida
- O real valor da revisão de código
- As revisões de código são inerentemente sociais
- Regra 7 ■ Elimine casos de falha
- Uma função que torna fácil dar um tiro no próprio pé
- Atirando no próprio pé via ricochete
- Uso da ajuda do compilador para evitar o tiro no pé
- A hora certa é o que importa
- Um exemplo mais complicado
- Faça com que erros de ordenação não possam ocorrer
- Uso de templates em substituição ao encadeamento de métodos
- Controle de estado coordenado
- É bom detectar erros, mas tornar impossível expressá-los é melhor
- Regra 8 ■ Código que não é executado não funciona
- Etapa 1: Um começo simples
- Etapa 2: Generalização de um padrão comum
- Etapa 3: Inclusão de disfarces
- Etapa 4: O feitiço vira contra o feiticeiro
- Atribuição de culpa
- Limites dos testes
- Regra 9 ■ Escreva código resumível
- É assim que nos sentimos quando não temos sucesso
- Papel da memória de curto prazo
- Onde definir o limite
- Custo da abstração
- Use a abstração para facilitar o entendimento
- Papel da memória de longo prazo
- O conhecimento comum é gratuito; novos conceitos são caros
- Juntando tudo
- Regra 10 ■ Isole a complexidade
- Um exemplo simples
- Ocultação de detalhes internos
- Estado distribuído e complexidade
- Capacitado?
- As coisas começam a ficar nebulosas
- Repensando a abordagem
- Complexidade isolada, interações simples
- Regra 11 ■ É duas vezes melhor?
- Três caminhos para seguir em frente: ignore, ajuste ou refatore
- Evolução gradual versus reinvenção contínua
- Princípio básico simples
- Lidando com benefícios nebulosos
- Reformular é uma boa oportunidade para corrigir pequenos problemas
- Regra 12 ■ Equipes grandes precisam de convenções fortes
- Convenções de formatação
- Convenções de uso da linguagem
- Convenções de solução de problemas
- Membros de equipes eficazes pensam da mesma forma
- Regra 13 ■ Encontre a pedra que começou a avalanche
- Ciclo de vida de um bug
- Redução do estado
- Como lidar com um estado inevitável
- Como lidar com atrasos inevitáveis
- Regra 14 ■ Existem quatro tipos de código
- Problema Fácil, solução Simples
- Problema Fácil, três soluções Complicadas
- Custo da complexidade
- Os quatro (que na verdade são três) tipos de programadores
- Problema Difícil, soluções um pouco Complicadas que não funcionam
- Problema Difícil, solução um pouco Complicada
- Problema Difícil, solução Simples
- Regra 15 ■ Remova as ervas daninhas
- Identificação de ervas daninhas
- Como o código passa a apresentar ervas daninhas
- Um exemplo
- Surge um incômodo
- Escolha um lado da lacuna
- Trabalhando para trás
- E agora algo totalmente diferente
- Trabalhando para a frente e para trás
- Regra 17 ■ Às vezes o problema maior é mais fácil de resolver
- Conclusões apressadas
- Busca de um caminho claro para seguir
- Reconhecendo a oportunidade
- Regra 18 ■ Deixe seu código contar a própria história
- Não conte histórias que não sejam reais
- Certifique-se de que a história seja relevante
- Conte boas histórias
- Regra 19 ■ Reformule em paralelo
- Obstáculos no caminho
- Crie um sistema paralelo
- Um exemplo concreto
- Alocação de pilha na prática
- Uma nuvem no horizonte
- Torne os contextos de pilha mais inteligentes
- Migração dos contextos de pilha antigos para os novos
- Prepare-se para migrar StackVector
- Hora de migrar
- Reconhecendo quando a reformulação paralela é uma boa estratégia
- Regra 20 ■ Faça o cálculo
- Automatizar ou não automatizar
- Procure limites rígidos
- Quando o cálculo muda
- Quando o problema matemático volta a ser um problema do Word
- Regra 21 ■ Às vezes só precisamos martelar os pregos
- Um novo argumento
- Nunca há apenas um bug
- A tendência de automatizar
- Gerencie o tamanho dos arquivos
- Não existem atalhos
- Conclusão: Adapte as Regras para você
- Use o bom senso
- Façam debates entre vocês
- Hora de me despedir
- Apêndice A ■ Leitura de C++ para programadores Python
- Tipos
- Formatação e comentários
- Comentários
- Indentação e divisão de linhas
- Operações booleanas
- Listas
- Operadores de incremento
- Classes
- Visibilidade
- Declarações e definições
- Sobrecarga de funções
- Templates
- Ponteiros e referências
- Apêndice B ■ Leitura de C++ para programadores JavaScript
- Tipos
- Arrays
- Classes
- Declarações e definições
- Sobrecarga de funções
- Templates
- Ponteiros e referências
- Sobre o autor
- Índice remissivo
Sobre o autor
Chris Zimmerman ajudou a fundar o estúdio de videogames Sucker Punch Productions em 1997 e conduziu a equipe de codificação por um quarto de século na criação de videogames de sucesso, o que culminou com o prêmio Game of the Year de 2020 para Ghost of Tsushima. Antes de sua semiaposentadoria para escrever este livro, ele dividia seu tempo entre… Ver perfil completo ▶
Livros relacionados
Recursos
Opinião dos leitores
Ailton T
O livro “As Regras da Programação” apresenta uma coletânea muito interessante de princípios, boas práticas e reflexões sobre desenvolvimento de software. O conteúdo aborda temas que vão além da sintaxe e da implementação técnica, trazendo discussões sobre legibilidade, manutenção, organização e disciplina na construção de código. Achei interessante como o livro reforça conceitos que muitas vezes parecem simples, mas fazem bastante diferença na qualidade e sustentabilidade dos projetos ao longo do tempo. A abordagem é prática e ajuda a estimular uma visão mais madura sobre engenharia de software. A leitura é fluida e traz várias ideias aplicáveis no dia a dia, principalmente para profissionais que querem evoluir na escrita de código mais limpo, consistente e fácil de manter. No geral, considero um livro bastante válido para quem deseja fortalecer fundamentos de desenvolvimento e aprimorar a forma como pensa e estrutura soluções de software.






