As Regras da Programação

Como criar códigos melhores

As Regras da Programação
× As Regras da Programação

As Regras da Programação

Compartilhar

Autor: Chris Zimmerman

ISBN impresso: 978-85-7522-854-8
ISBN ebook: 978-85-7522-855-5
Ano: 2023
Páginas: 352
Preço impresso: R$ 97,00 O ebook deste livro está disponível na Amazon.

1 opinião | Opine sobre este livro

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
Ver sumário completo ▼

Sobre o autor

Chris Zimmerman

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 ▶

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.

Ver todas ▼