Temas que atravessam áreas

A mesma pergunta reaparece em áreas diferentes. Estas etiquetas cortam transversalmente os oito campos.

Planejamento e decisãoMediçãoUsuáriosArquiteturaDadosDesempenhoConfiabilidadeSegurançaPrivacidadeCustoTestesDeployMonitoramentoDocumentaçãoProcesso e timesFornecedores e terceirosCompatibilidade e mudançaManutenção no longo prazoExperimentosInterfaces

Planejamento e decisão

Definir um problema, priorizar e escolher o que não fazer

16 artigos
Também aparece em: Fundamentos de produto · Apps mobile · Segurança · IA na prática · Ofício, qualidade e times
001De uma ideia a um problema que dá para resolverAntes de escolher tecnologia, escreva quem sofre com o problema, o que essa pessoa faz hoje no lugar e como você vai saber que ele foi resolvido.002O menor protótipo que prova alguma coisaUm protótipo existe para responder a uma pergunta perigosa, não para demonstrar um produto — por isso pode ser feio, manual e incompleto.003Escrever uma especificação que o time realmente lêUma boa especificação descreve comportamento e critérios de aceite, não telas prontas — e o tamanho dela se mede em páginas, não em dezenas.004Escolher o que não construirA capacidade de dizer não é o que separa um produto que foi lançado de um que está em desenvolvimento para sempre.005Quanto tempo vai levar: estimativas sem ilusãoUma boa estimativa é um intervalo com hipóteses visíveis, atualizado conforme o conhecimento cresce — não um único número dito uma vez.006Construir, comprar ou integrarConstrua apenas o que te distingue; todo o resto — compre, integre ou abra mão.007Pesquisa de usuário em três diasCinco conversas de meia hora com quem faz o trabalho revelam mais do que uma pesquisa com mil respostas.009Dívida técnica: quando contrair e quando pagarDívida técnica é uma ferramenta de financiamento legítima — desde que seja contraída conscientemente, registrada e tenha uma data em que se fala sobre o pagamento.010Primeira versão: o que precisa entrarA primeira versão precisa fazer uma coisa de ponta a ponta, e fazê-la de um jeito em que você possa confiar.011Como priorizar quando todos estão gritandoPriorização não é uma lista ordenada, mas uma regra de decisão que todos conhecem de antemão — senão, é quem fala mais alto que decide.012Da especificação para tarefas com as quais dá para começarUma boa tarefa termina em um resultado que dá para executar e verificar, e leva um a dois dias — não uma semana nem uma hora.021Nativo, multiplataforma ou site web mobileA escolha é determinada por quanto você precisa do próprio dispositivo e pelo tamanho do time — não pela tecnologia que está na moda este ano.061Um modelo de ameaças em uma horaEsboce o que você tem, quem pode querer e onde cruza uma fronteira — e você obtém uma lista de prioridades real em vez de um palpite.075Como escolher um modelo — e por que não é a primeira decisãoComece com o modelo mais poderoso para testar se a tarefa é solucionável, e só então desça para um mais barato até a qualidade quebrar.097Escolher tecnologia sem se arrepender em dois anosEscolha pelo time, pela maturidade e pela comunidade — e o que é entediante e familiar quase sempre vence o que é novo e empolgante.100O que realmente decide se um projeto tem sucessoNão a tecnologia nem o tamanho do time — mas a clareza do objetivo, ciclos curtos de feedback e uma pessoa responsável por decidir.

Medição

Saber se algo realmente melhorou

12 artigos
Também aparece em: Fundamentos de produto · Apps mobile · Infraestrutura, nuvem e DevOps · IA na prática · Ofício, qualidade e times
001De uma ideia a um problema que dá para resolverAntes de escolher tecnologia, escreva quem sofre com o problema, o que essa pessoa faz hoje no lugar e como você vai saber que ele foi resolvido.002O menor protótipo que prova alguma coisaUm protótipo existe para responder a uma pergunta perigosa, não para demonstrar um produto — por isso pode ser feio, manual e incompleto.008Métricas de sucesso que não mentemEscolha uma métrica ligada ao valor que o usuário recebeu, e ao lado uma que impeça que você quebre outra coisa.025Performance mobile: memória, bateria e a sensação de velocidadeNos apps, a sensação é definida no tempo de inicialização e na fluidez do scroll — e ambos são quebrados por imagens e trabalho rodando na thread principal.029Monitoramento de crashes e erros em um appSem reporte automático de crash, você fica sabendo dos problemas pelas avaliações da loja — ou seja, tarde demais.052Monitoramento e observabilidade: saber que algo quebrou antes do clienteTrês tipos de sinal — métricas, logs e traces — e uma pergunta que precisam responder: o que está acontecendo agora e por quê.054Custos de cloud: para onde o dinheiro vaiA maior parte da fatura vem de três lugares: recursos rodando que ninguém precisa, armazenamento crescendo sem política e tráfego entre regiões.079Avaliação: como saber que o sistema melhorouSem um conjunto de avaliação fixo, toda mudança é uma crença — e uma melhoria em uma área vai esconder uma regressão em outra.081Classificação e extração: as tarefas que mais retornamAntes de construir um chat, verifique se o problema é na verdade classificar uma consulta ou extrair campos de um documento — duas tarefas simples que retornam valor imediato.082Alucinações: por que acontecem e o que realmente ajudaUm modelo ao qual se faz uma pergunta sem resposta vai produzir uma resposta plausível — a solução não é pedir para não errar, mas dar uma fonte e uma forma de dizer não.088Experimentos: como saber que a mudança melhorou algoCompare duas versões no mesmo tráfego ao mesmo tempo — qualquer comparação de 'antes e depois' também mede o mundo, não só você.100O que realmente decide se um projeto tem sucessoNão a tecnologia nem o tamanho do time — mas a clareza do objetivo, ciclos curtos de feedback e uma pessoa responsável por decidir.

Usuários

O que acontece do lado de quem usa o sistema

11 artigos
Também aparece em: Fundamentos de produto · Web e frontend · Apps mobile · Segurança · IA na prática
007Pesquisa de usuário em três diasCinco conversas de meia hora com quem faz o trabalho revelam mais do que uma pesquisa com mil respostas.014Performance no navegador: o que realmente deixa um site lentoNa maioria dos sites lentos, o culpado não é o código, mas o peso — imagens grandes, fontes e scripts de terceiros.015Acessibilidade: o mínimo que não dá para pularA maior parte da acessibilidade vem de escrever HTML correto, e a maioria das falhas vem de substituir elementos padrão por algo desenhado para se parecer com eles.016Design responsivo sem dorComece pela tela pequena, deixe o conteúdo decidir onde quebra, e não projete para uma lista de dispositivos.017SEO técnico para sites modernosAntes das palavras-chave, garanta que o mecanismo de busca consegue chegar na página, lê-la e entender o que ela é.019Formulários: a parte onde mais usuários quebramUm bom formulário pede pouco, verifica no momento certo, explica um erro onde ele aconteceu e não apaga o que foi digitado.020Hebraico e da direita para a esquerda: o que quebra e como consertarA maioria dos bugs de direita para esquerda vem de usar left e right em vez de start e end — e de texto misto que colide em uma linha.023Notificações push sem perder usuáriosUma notificação justificada é aquela cuja ausência o usuário lamentaria — todo o resto leva a desativar a permissão, o que é quase irreversível.028UX mobile: o que é diferente de uma tela grandeNo mobile o usuário está de pé, com pressa, segurando com uma mão e às vezes ao sol — e isso muda cada decisão.063Senhas, segundo fator e sessõesArmazene senhas com um algoritmo lento dedicado, habilite o segundo fator e torne possível encerrar sessão em todos os dispositivos.084Projetar uma interface para um sistema que nem sempre acertaUma boa interface mostra certeza variável, permite correção fácil e não apresenta um palpite como fato.

Arquitetura

Como os componentes são divididos e conversam entre si

16 artigos
Também aparece em: Web e frontend · Apps mobile · Backend, APIs e dados · Infraestrutura, nuvem e DevOps · IA na prática · Ofício, qualidade e times
013Escolher entre site estático, site renderizado no servidor e app de navegadorQuanto mais fixo o conteúdo, mais simples deve ser a arquitetura — e cada camada de dinamismo que você adiciona você paga todo dia a partir daí.018Gerenciamento de estado em um app webA maior parte do que se chama de estado são dados do servidor guardados no lugar errado — separe-os e metade da complexidade desaparece.021Nativo, multiplataforma ou site web mobileA escolha é determinada por quanto você precisa do próprio dispositivo e pelo tamanho do time — não pela tecnologia que está na moda este ano.022Trabalhar offline: um app que não quebra no elevadorProjete o app em torno da suposição de que não há rede, e você ganha de graça um app que também parece rápido quando há.034Bancos de dados: escolher e não se arrependerNa maioria dos casos, um banco de dados relacional é a resposta certa, e qualquer outra escolha precisa de um motivo que dê para dizer em uma frase.036Filas e jobs em segundo planoTudo que leva mais de um segundo e não é necessário para a resposta ao usuário pertence a uma fila, não à requisição.037Cache: acelerar sem servir dados desatualizadosAntes de adicionar um cache, decida por quanto tempo um dado desatualizado ainda é aceitável — é a única pergunta que realmente importa.039Um serviço ou muitos: quando dividirComece com um sistema bem ordenado. Divida só quando houver dor real — times que se bloqueiam ou um componente que precisa de uma escala diferente.040Projetar um modelo de dados que dure anosUm bom modelo representa a realidade do negócio, não a primeira tela que pediram para você construir.042Arquivos e armazenamento de objetosArquivos não pertencem ao banco de dados nem ao disco do servidor — pertencem ao armazenamento de objetos com endereços assinados.055Escalabilidade: horizontal, vertical e o que você realmente precisaAntes de escalar, meça onde está o gargalo — na maioria dos sistemas é o banco de dados ou uma consulta, não o número de servidores.076Conectar seu conhecimento ao modelo: recuperação sem palavras grandesO modelo não conhece seus documentos — você precisa encontrar os trechos relevantes para cada pergunta e anexá-los ao prompt.077Agentes: quando deixar o sistema agir sozinhoUm agente decide por si mesmo quais ações executar — toda a recompensa e o risco estão nas permissões que você deu.087Automação de processos: onde um modelo adiciona e onde é desnecessárioSe o processo é fixo e claro, escreva código; um modelo vale exatamente nos lugares onde é preciso julgamento sobre texto não estruturado.089Arquitetura de um sistema baseado em modeloO modelo é um componente dentro de um sistema comum — e o sistema ao redor é a maior parte do trabalho e do risco.096Nomes, estrutura e código para o qual dá para voltarCódigo é lido muito mais do que é escrito — por isso um nome preciso e uma estrutura previsível valem mais do que qualquer engenhosidade.

Dados

Estrutura, armazenamento e integridade da informação

13 artigos
Também aparece em: Web e frontend · Apps mobile · Backend, APIs e dados · Infraestrutura, nuvem e DevOps · Segurança · IA na prática
018Gerenciamento de estado em um app webA maior parte do que se chama de estado são dados do servidor guardados no lugar errado — separe-os e metade da complexidade desaparece.022Trabalhar offline: um app que não quebra no elevadorProjete o app em torno da suposição de que não há rede, e você ganha de graça um app que também parece rápido quando há.026Armazenamento local e dados sensíveis no dispositivoAssuma que o dispositivo será perdido ou comprometido: o que for armazenado localmente deve ser mínimo, criptografado e revogável remotamente.034Bancos de dados: escolher e não se arrependerNa maioria dos casos, um banco de dados relacional é a resposta certa, e qualquer outra escolha precisa de um motivo que dê para dizer em uma frase.035Migrações de esquema sem tempo de inatividadeMude o esquema em passos compatíveis retroativamente: adicione, preencha, mude, e só no final — remova.040Projetar um modelo de dados que dure anosUm bom modelo representa a realidade do negócio, não a primeira tela que pediram para você construir.043Busca: quando o banco de dados não é mais suficienteBusca de texto livre com relevância, erros de digitação e múltiplos filtros é um mundo à parte — e nem todo sistema precisa disso.046Trabalhar com dinheiro: pagamentos e cobrançasNunca armazene dados de cartão, nunca confie em um valor que veio do cliente, e sempre mantenha um log imutável de eventos.053Backup e recuperação: o que não é testado não existeUm backup não é uma política; uma política é quanto dado você pode perder e quanto tempo pode ficar fora — e a prova de que você cumpriu.069Privacidade por design: coletar menosA forma mais barata de proteger informações é não coletá-las — e cada campo coletado deve ter uma finalidade, um dono e uma data de exclusão.076Conectar seu conhecimento ao modelo: recuperação sem palavras grandesO modelo não conhece seus documentos — você precisa encontrar os trechos relevantes para cada pergunta e anexá-los ao prompt.081Classificação e extração: as tarefas que mais retornamAntes de construir um chat, verifique se o problema é na verdade classificar uma consulta ou extrair campos de um documento — duas tarefas simples que retornam valor imediato.083Dados: de onde vêm e o que fazer quando não háNa maioria dos projetos os dados existem mas estão espalhados, sem rótulo e sem limpeza — e essa é a etapa que come a maior parte do tempo.

Desempenho

Velocidade, carga e como o usuário sente

11 artigos
Também aparece em: Web e frontend · Apps mobile · Backend, APIs e dados · Infraestrutura, nuvem e DevOps · IA na prática
013Escolher entre site estático, site renderizado no servidor e app de navegadorQuanto mais fixo o conteúdo, mais simples deve ser a arquitetura — e cada camada de dinamismo que você adiciona você paga todo dia a partir daí.014Performance no navegador: o que realmente deixa um site lentoNa maioria dos sites lentos, o culpado não é o código, mas o peso — imagens grandes, fontes e scripts de terceiros.017SEO técnico para sites modernosAntes das palavras-chave, garanta que o mecanismo de busca consegue chegar na página, lê-la e entender o que ela é.025Performance mobile: memória, bateria e a sensação de velocidadeNos apps, a sensação é definida no tempo de inicialização e na fluidez do scroll — e ambos são quebrados por imagens e trabalho rodando na thread principal.031Arquivos, mídia e uploads do dispositivoUma foto da câmera pesa dezenas de vezes mais do que o necessário — processe no dispositivo antes de tocar na rede.037Cache: acelerar sem servir dados desatualizadosAntes de adicionar um cache, decida por quanto tempo um dado desatualizado ainda é aceitável — é a única pergunta que realmente importa.043Busca: quando o banco de dados não é mais suficienteBusca de texto livre com relevância, erros de digitação e múltiplos filtros é um mundo à parte — e nem todo sistema precisa disso.045Carga: limites de taxa e autoproteçãoUm sistema saudável recusa cedo e com clareza, em vez de desabar lentamente sob uma carga que não consegue suportar.055Escalabilidade: horizontal, vertical e o que você realmente precisaAntes de escalar, meça onde está o gargalo — na maioria dos sistemas é o banco de dados ou uma consulta, não o número de servidores.080Custo e latência em sistemas baseados em modelosA maior parte do custo vem do texto que entra, e a maior parte da latência do que sai — por isso as duas correções são diferentes.086Modelos pequenos, locais e de bordaQuando o volume é grande, a latência é crítica ou os dados não podem sair — um modelo pequeno do seu lado supera um grande na cloud.

Confiabilidade

O que acontece quando algo quebra

13 artigos
Também aparece em: Fundamentos de produto · Apps mobile · Backend, APIs e dados · Infraestrutura, nuvem e DevOps · IA na prática
010Primeira versão: o que precisa entrarA primeira versão precisa fazer uma coisa de ponta a ponta, e fazê-la de um jeito em que você possa confiar.022Trabalhar offline: um app que não quebra no elevadorProjete o app em torno da suposição de que não há rede, e você ganha de graça um app que também parece rápido quando há.036Filas e jobs em segundo planoTudo que leva mais de um segundo e não é necessário para a resposta ao usuário pertence a uma fila, não à requisição.041Confiabilidade em chamadas a serviços externosToda chamada de saída vai falhar em algum momento — a única pergunta é se você planejou o que acontece então.044E-mail de saída, mensagens e webhooksMensagens de saída são uma interface pública: precisam de fila, retentativas e registro do que foi enviado para quem.045Carga: limites de taxa e autoproteçãoUm sistema saudável recusa cedo e com clareza, em vez de desabar lentamente sob uma carga que não consegue suportar.051Estratégias de deploy: azul-verde, canário e gradualUm bom deploy é medido pela capacidade de reverter rapidamente, não pela velocidade de sair.053Backup e recuperação: o que não é testado não existeUm backup não é uma política; uma política é quanto dado você pode perder e quanto tempo pode ficar fora — e a prova de que você cumpriu.056Redes e certificados: domínio, DNS e HTTPSA maioria dos incidentes de 'o site não carrega' são um domínio, um certificado expirado ou o roteamento — não o código.058Revisão de incidente sem busca de culpadosDepois de cada incidente, uma hora de revisão escrita focada no sistema e não na pessoa vale a pena — senão o mesmo incidente volta.059Alta disponibilidade e recuperação de desastresDecida quanto custa uma hora de inatividade e só então decida quanta redundância comprar.082Alucinações: por que acontecem e o que realmente ajudaUm modelo ao qual se faz uma pergunta sem resposta vai produzir uma resposta plausível — a solução não é pedir para não errar, mas dar uma fonte e uma forma de dizer não.089Arquitetura de um sistema baseado em modeloO modelo é um componente dentro de um sistema comum — e o sistema ao redor é a maior parte do trabalho e do risco.

Segurança

Pensar como um atacante antes que ele pense

19 artigos
Também aparece em: Apps mobile · Backend, APIs e dados · Infraestrutura, nuvem e DevOps · Segurança · IA na prática
026Armazenamento local e dados sensíveis no dispositivoAssuma que o dispositivo será perdido ou comprometido: o que for armazenado localmente deve ser mínimo, criptografado e revogável remotamente.038Autenticação e autorização: quem você é e o que tem permissãoIdentidade e autorização são duas perguntas distintas, e a maioria das brechas vem da segunda ser verificada na interface e não no servidor.046Trabalhar com dinheiro: pagamentos e cobrançasNunca armazene dados de cartão, nunca confie em um valor que veio do cliente, e sempre mantenha um log imutável de eventos.056Redes e certificados: domínio, DNS e HTTPSA maioria dos incidentes de 'o site não carrega' são um domínio, um certificado expirado ou o roteamento — não o código.057Gerenciar segredos e chavesUm segredo no repositório de código é um segredo vazado — mesmo que o repositório seja privado e mesmo que você o tenha deletado depois.061Um modelo de ameaças em uma horaEsboce o que você tem, quem pode querer e onde cruza uma fronteira — e você obtém uma lista de prioridades real em vez de um palpite.062Os dez falhas que se repetem em toda auditoriaA maioria dos achados não é sofisticada: permissões não verificadas no servidor, entrada que chega a uma consulta e bibliotecas antigas.063Senhas, segundo fator e sessõesArmazene senhas com um algoritmo lento dedicado, habilite o segundo fator e torne possível encerrar sessão em todos os dispositivos.064Injeções: separar uma instrução dos dadosTodo lugar onde uma string do usuário é montada em um comando é um buraco — a solução são parâmetros, não filtragem.065Proteger interfaces públicasUma interface aberta para a internet é escaneada automaticamente desde o primeiro dia — assuma que toda rota será chamada, em qualquer ordem, com qualquer entrada.066A cadeia de suprimentos do códigoSeu código é uma minoria do que roda em produção — a maior parte do risco está nos pacotes que você trouxe e nas ferramentas que os construíram.067Criptografia: quando, onde e como não errarUse bibliotecas conhecidas com padrões modernos, e não invente nada — quase toda falha de criptografia é uma falha de uso.068Permissões na cloud: a regra mais importante é o mínimoA maioria dos incidentes graves na cloud começa com uma identidade que tem mais permissões do que precisa e sem expiração.070Segurança no navegador: proteções definidas nos cabeçalhosGrande parte dos ataques do lado do cliente é bloqueada por alguns cabeçalhos de resposta e algumas configurações corretas de cookie.071Segurança do time: onde a maioria das brechas começaMesmo um sistema seguro é comprometido pelo dispositivo de um funcionário, um e-mail de phishing ou uma conta sem segundo fator.072Testes de segurança: o que pedir e quandoVarredura automática é higiene contínua; um teste de penetração é um evento focado — e os dois precisam de um objetivo escrito.073Segurança em sistemas baseados em modelosUm modelo adiciona dois novos riscos: conteúdo externo interpretado como uma instrução, e saída que chega a um lugar sensível sem verificação.074Preparar-se para um incidente antes que ele aconteçaDurante um incidente não há tempo para decidir quem decide — o papel escrito numa manhã tranquila é a diferença entre uma hora e uma semana.077Agentes: quando deixar o sistema agir sozinhoUm agente decide por si mesmo quais ações executar — toda a recompensa e o risco estão nas permissões que você deu.

Privacidade

Coletar menos e proteger o que é coletado

5 artigos
Também aparece em: Apps mobile · Infraestrutura, nuvem e DevOps · Segurança · IA na prática
026Armazenamento local e dados sensíveis no dispositivoAssuma que o dispositivo será perdido ou comprometido: o que for armazenado localmente deve ser mínimo, criptografado e revogável remotamente.060Logs: armazenar corretamente e encontrar rápidoUm bom log é estruturado, identificado com um ID de requisição, guardado por um tempo definido e livre de informações pessoais que não têm motivo de estar lá.067Criptografia: quando, onde e como não errarUse bibliotecas conhecidas com padrões modernos, e não invente nada — quase toda falha de criptografia é uma falha de uso.069Privacidade por design: coletar menosA forma mais barata de proteger informações é não coletá-las — e cada campo coletado deve ter uma finalidade, um dono e uma data de exclusão.085Viés, equidade e responsabilidade no uso de modelosUm modelo reflete o que viu — por isso decisões que afetam pessoas exigem verificação por segmentos, uma pessoa no loop e documentação.

Custo

Quanto custa e por que cresce

7 artigos
Também aparece em: Fundamentos de produto · Apps mobile · Backend, APIs e dados · Infraestrutura, nuvem e DevOps · IA na prática
006Construir, comprar ou integrarConstrua apenas o que te distingue; todo o resto — compre, integre ou abra mão.031Arquivos, mídia e uploads do dispositivoUma foto da câmera pesa dezenas de vezes mais do que o necessário — processe no dispositivo antes de tocar na rede.042Arquivos e armazenamento de objetosArquivos não pertencem ao banco de dados nem ao disco do servidor — pertencem ao armazenamento de objetos com endereços assinados.054Custos de cloud: para onde o dinheiro vaiA maior parte da fatura vem de três lugares: recursos rodando que ninguém precisa, armazenamento crescendo sem política e tráfego entre regiões.075Como escolher um modelo — e por que não é a primeira decisãoComece com o modelo mais poderoso para testar se a tarefa é solucionável, e só então desça para um mais barato até a qualidade quebrar.080Custo e latência em sistemas baseados em modelosA maior parte do custo vem do texto que entra, e a maior parte da latência do que sai — por isso as duas correções são diferentes.086Modelos pequenos, locais e de bordaQuando o volume é grande, a latência é crítica ou os dados não podem sair — um modelo pequeno do seu lado supera um grande na cloud.

Testes

Pegar falhas antes que cheguem à produção

6 artigos
Também aparece em: Infraestrutura, nuvem e DevOps · Segurança · IA na prática · Ofício, qualidade e times
050Uma pipeline automatizada de build e deployTodo merge deveria disparar a mesma sequência: build, testes, verificações de segurança, deploy — sem um único passo manual no meio.062Os dez falhas que se repetem em toda auditoriaA maioria dos achados não é sofisticada: permissões não verificadas no servidor, entrada que chega a uma consulta e bibliotecas antigas.072Testes de segurança: o que pedir e quandoVarredura automática é higiene contínua; um teste de penetração é um evento focado — e os dois precisam de um objetivo escrito.079Avaliação: como saber que o sistema melhorouSem um conjunto de avaliação fixo, toda mudança é uma crença — e uma melhoria em uma área vai esconder uma regressão em outra.091Testes: quantos, quais e quais não valemInvista na maioria de testes que exercitam sua lógica, alguns de integração e pouquíssimos de ponta a ponta.098Qualidade sem burocracia: como não quebrar o que funcionaRegressões são evitadas por três coisas: testes automáticos, lançamentos pequenos e frequentes e a capacidade de reverter rápido.

Deploy

Como o código vai ao ar e como se reverte

8 artigos
Também aparece em: Apps mobile · Backend, APIs e dados · Infraestrutura, nuvem e DevOps · Ofício, qualidade e times
030Rollout gradual e switches de capacidadeLance para uma pequena porcentagem, observe as métricas e expanda — e mantenha a capacidade de desligar uma funcionalidade sem lançar uma versão.035Migrações de esquema sem tempo de inatividadeMude o esquema em passos compatíveis retroativamente: adicione, preencha, mude, e só no final — remova.047Ambientes: desenvolvimento, teste e produçãoTrês ambientes construídos a partir da mesma definição, diferindo apenas em configuração e dados — qualquer outra diferença é um bug esperando para ser encontrado.048Containers: o que trazem e quando são desnecessáriosUm container empacota o app com tudo que ele precisa para rodar, de modo que se comporta igual em qualquer lugar.049Infraestrutura como códigoSe você não consegue reproduzir o ambiente a partir de um arquivo no controle de versões, você não tem infraestrutura, mas um histórico de cliques.050Uma pipeline automatizada de build e deployTodo merge deveria disparar a mesma sequência: build, testes, verificações de segurança, deploy — sem um único passo manual no meio.051Estratégias de deploy: azul-verde, canário e gradualUm bom deploy é medido pela capacidade de reverter rapidamente, não pela velocidade de sair.098Qualidade sem burocracia: como não quebrar o que funcionaRegressões são evitadas por três coisas: testes automáticos, lançamentos pequenos e frequentes e a capacidade de reverter rápido.

Monitoramento

Saber o que está acontecendo agora e por quê

4 artigos
Também aparece em: Apps mobile · Infraestrutura, nuvem e DevOps · IA na prática
029Monitoramento de crashes e erros em um appSem reporte automático de crash, você fica sabendo dos problemas pelas avaliações da loja — ou seja, tarde demais.052Monitoramento e observabilidade: saber que algo quebrou antes do clienteTrês tipos de sinal — métricas, logs e traces — e uma pergunta que precisam responder: o que está acontecendo agora e por quê.060Logs: armazenar corretamente e encontrar rápidoUm bom log é estruturado, identificado com um ID de requisição, guardado por um tempo definido e livre de informações pessoais que não têm motivo de estar lá.090Operar um sistema de IA ao longo do tempoModelos são substituídos, documentos mudam e usuários aprendem a perguntar de forma diferente — um sistema não tocado por seis meses é quase sempre pior.

Documentação

O que não dá para inferir do código

6 artigos
Também aparece em: Fundamentos de produto · Backend, APIs e dados · IA na prática · Ofício, qualidade e times
003Escrever uma especificação que o time realmente lêUma boa especificação descreve comportamento e critérios de aceite, não telas prontas — e o tamanho dela se mede em páginas, não em dezenas.032Projetar uma interface com a qual dá para conviverUma boa interface é previsível, consistente e entediante — cada surpresa nela vira uma pergunta recorrente e um bug para quem a usa.078Prompts: escreva uma especificação, não um encantamentoUm bom prompt define um papel, a entrada, as regras de decisão e a estrutura de saída — e é tratado como código, em controle de versões e com testes.092Revisão de código que melhora em vez de atrasarUma boa revisão é pequena, rápida e focada em correção e manutenibilidade — não nas preferências de estilo que uma ferramenta automática deveria aplicar.094Documentação que as pessoas realmente leemDocumente o que não dá para inferir do código: decisões, limites e a forma de começar — todo o resto envelhece e engana.095Integrar um novo desenvolvedor em uma semana, não em um mêsA métrica é quanto tempo passa até a primeira mudança em produção — e a maior parte do atraso é em acessos e configuração local, não em entender o código.

Processo e times

Como trabalhar junto sem travar uns aos outros

22 artigos
Também aparece em: Fundamentos de produto · Apps mobile · Backend, APIs e dados · Infraestrutura, nuvem e DevOps · Segurança · IA na prática · Ofício, qualidade e times
005Quanto tempo vai levar: estimativas sem ilusãoUma boa estimativa é um intervalo com hipóteses visíveis, atualizado conforme o conhecimento cresce — não um único número dito uma vez.011Como priorizar quando todos estão gritandoPriorização não é uma lista ordenada, mas uma regra de decisão que todos conhecem de antemão — senão, é quem fala mais alto que decide.012Da especificação para tarefas com as quais dá para começarUma boa tarefa termina em um resultado que dá para executar e verificar, e leva um a dois dias — não uma semana nem uma hora.024Passar na revisão da loja na primeira tentativaA maioria das rejeições vem de metadados e permissões, não do código — e pode ser evitada com uma hora de preparação.039Um serviço ou muitos: quando dividirComece com um sistema bem ordenado. Divida só quando houver dor real — times que se bloqueiam ou um componente que precisa de uma escala diferente.047Ambientes: desenvolvimento, teste e produçãoTrês ambientes construídos a partir da mesma definição, diferindo apenas em configuração e dados — qualquer outra diferença é um bug esperando para ser encontrado.049Infraestrutura como códigoSe você não consegue reproduzir o ambiente a partir de um arquivo no controle de versões, você não tem infraestrutura, mas um histórico de cliques.050Uma pipeline automatizada de build e deployTodo merge deveria disparar a mesma sequência: build, testes, verificações de segurança, deploy — sem um único passo manual no meio.057Gerenciar segredos e chavesUm segredo no repositório de código é um segredo vazado — mesmo que o repositório seja privado e mesmo que você o tenha deletado depois.058Revisão de incidente sem busca de culpadosDepois de cada incidente, uma hora de revisão escrita focada no sistema e não na pessoa vale a pena — senão o mesmo incidente volta.071Segurança do time: onde a maioria das brechas começaMesmo um sistema seguro é comprometido pelo dispositivo de um funcionário, um e-mail de phishing ou uma conta sem segundo fator.074Preparar-se para um incidente antes que ele aconteçaDurante um incidente não há tempo para decidir quem decide — o papel escrito numa manhã tranquila é a diferença entre uma hora e uma semana.078Prompts: escreva uma especificação, não um encantamentoUm bom prompt define um papel, a entrada, as regras de decisão e a estrutura de saída — e é tratado como código, em controle de versões e com testes.085Viés, equidade e responsabilidade no uso de modelosUm modelo reflete o que viu — por isso decisões que afetam pessoas exigem verificação por segmentos, uma pessoa no loop e documentação.087Automação de processos: onde um modelo adiciona e onde é desnecessárioSe o processo é fixo e claro, escreva código; um modelo vale exatamente nos lugares onde é preciso julgamento sobre texto não estruturado.092Revisão de código que melhora em vez de atrasarUma boa revisão é pequena, rápida e focada em correção e manutenibilidade — não nas preferências de estilo que uma ferramenta automática deveria aplicar.093Trabalhar com versões: branches, merges e históricoBranches curtos e merges frequentes evitam a maior parte da dor de versão — e um histórico legível vale o esforço no dia em que você investiga um incidente.094Documentação que as pessoas realmente leemDocumente o que não dá para inferir do código: decisões, limites e a forma de começar — todo o resto envelhece e engana.095Integrar um novo desenvolvedor em uma semana, não em um mêsA métrica é quanto tempo passa até a primeira mudança em produção — e a maior parte do atraso é em acessos e configuração local, não em entender o código.098Qualidade sem burocracia: como não quebrar o que funcionaRegressões são evitadas por três coisas: testes automáticos, lançamentos pequenos e frequentes e a capacidade de reverter rápido.099Trabalhar com fornecedores e contratantes de desenvolvimentoDefina entregáveis, propriedade e acesso por escrito com antecedência — e peça entrega contínua, não uma grande entrega no final.100O que realmente decide se um projeto tem sucessoNão a tecnologia nem o tamanho do time — mas a clareza do objetivo, ciclos curtos de feedback e uma pessoa responsável por decidir.

Fornecedores e terceiros

O que acontece quando você depende de outro

6 artigos
Também aparece em: Fundamentos de produto · Apps mobile · Backend, APIs e dados · Segurança · Ofício, qualidade e times
006Construir, comprar ou integrarConstrua apenas o que te distingue; todo o resto — compre, integre ou abra mão.024Passar na revisão da loja na primeira tentativaA maioria das rejeições vem de metadados e permissões, não do código — e pode ser evitada com uma hora de preparação.041Confiabilidade em chamadas a serviços externosToda chamada de saída vai falhar em algum momento — a única pergunta é se você planejou o que acontece então.066A cadeia de suprimentos do códigoSeu código é uma minoria do que roda em produção — a maior parte do risco está nos pacotes que você trouxe e nas ferramentas que os construíram.097Escolher tecnologia sem se arrepender em dois anosEscolha pelo time, pela maturidade e pela comunidade — e o que é entediante e familiar quase sempre vence o que é novo e empolgante.099Trabalhar com fornecedores e contratantes de desenvolvimentoDefina entregáveis, propriedade e acesso por escrito com antecedência — e peça entrega contínua, não uma grande entrega no final.

Compatibilidade e mudança

Mudar sem quebrar quem já usa

5 artigos
Também aparece em: Apps mobile · Backend, APIs e dados · Infraestrutura, nuvem e DevOps · Ofício, qualidade e times
027Versões e compatibilidade retroativa em appsUsuários têm versões antigas por meses — o servidor precisa suportá-las e saber quando parar.033Versionamento de interfaces: como mudar sem quebrarVocê publicou uma interface — se comprometeu. Uma mudança que quebra exige uma nova versão, um período de sobreposição e aviso prévio.035Migrações de esquema sem tempo de inatividadeMude o esquema em passos compatíveis retroativamente: adicione, preencha, mude, e só no final — remova.051Estratégias de deploy: azul-verde, canário e gradualUm bom deploy é medido pela capacidade de reverter rapidamente, não pela velocidade de sair.093Trabalhar com versões: branches, merges e históricoBranches curtos e merges frequentes evitam a maior parte da dor de versão — e um histórico legível vale o esforço no dia em que você investiga um incidente.

Manutenção no longo prazo

O que acontece com o sistema depois que o projeto acaba

5 artigos
Também aparece em: Fundamentos de produto · Apps mobile · Segurança · IA na prática · Ofício, qualidade e times
009Dívida técnica: quando contrair e quando pagarDívida técnica é uma ferramenta de financiamento legítima — desde que seja contraída conscientemente, registrada e tenha uma data em que se fala sobre o pagamento.027Versões e compatibilidade retroativa em appsUsuários têm versões antigas por meses — o servidor precisa suportá-las e saber quando parar.066A cadeia de suprimentos do códigoSeu código é uma minoria do que roda em produção — a maior parte do risco está nos pacotes que você trouxe e nas ferramentas que os construíram.090Operar um sistema de IA ao longo do tempoModelos são substituídos, documentos mudam e usuários aprendem a perguntar de forma diferente — um sistema não tocado por seis meses é quase sempre pior.096Nomes, estrutura e código para o qual dá para voltarCódigo é lido muito mais do que é escrito — por isso um nome preciso e uma estrutura previsível valem mais do que qualquer engenhosidade.

Experimentos

Lançar gradualmente e comparar versões

3 artigos
Também aparece em: Fundamentos de produto · Apps mobile · IA na prática
002O menor protótipo que prova alguma coisaUm protótipo existe para responder a uma pergunta perigosa, não para demonstrar um produto — por isso pode ser feio, manual e incompleto.030Rollout gradual e switches de capacidadeLance para uma pequena porcentagem, observe as métricas e expanda — e mantenha a capacidade de desligar uma funcionalidade sem lançar uma versão.088Experimentos: como saber que a mudança melhorou algoCompare duas versões no mesmo tráfego ao mesmo tempo — qualquer comparação de 'antes e depois' também mede o mundo, não só você.

Interfaces

O contrato que você dá a quem te consome

4 artigos
Também aparece em: Backend, APIs e dados · Segurança
032Projetar uma interface com a qual dá para conviverUma boa interface é previsível, consistente e entediante — cada surpresa nela vira uma pergunta recorrente e um bug para quem a usa.033Versionamento de interfaces: como mudar sem quebrarVocê publicou uma interface — se comprometeu. Uma mudança que quebra exige uma nova versão, um período de sobreposição e aviso prévio.044E-mail de saída, mensagens e webhooksMensagens de saída são uma interface pública: precisam de fila, retentativas e registro do que foi enviado para quem.065Proteger interfaces públicasUma interface aberta para a internet é escaneada automaticamente desde o primeiro dia — assuma que toda rota será chamada, em qualquer ordem, com qualquer entrada.