Saltar para o conteúdo
GUIA · 1.ª EDIÇÃOPT + EN

Tornar-se engenheiro sénior: Guia prático para programadores full-stack

Doze capítulos curtos para o ajudar a tomar melhores decisões, escrever melhor software, comunicar melhor e reunir evidências de que trabalha a nível sénior.

PDF + EPUB · Sem DRM · Atualizações 1.x gratuitas

O que o livro contém
CONTEÚDOQTD.PÁGINAS
CAPÍTULOS1212–90
CONCEITOS134148–218
LISTAS DE VERIFICAÇÃO8130–132
MODELOS4133–144
PLANO DE IMPLEMENTAÇÃO192–128
TOTAL220 páginas · PDF + EPUB
TAMBÉM INCLUÍDABecoming a Senior Engineer · 206 páginas · PDF + EPUB
PUBLICADO PELA FEITURA, UM ESTÚDIO DE ENGENHARIA SÉNIOR2026

O que torna um programador sénior?

DO CAPÍTULO 01 · P. 13

Das entregas aos resultados

No início de uma carreira, o sucesso significa muitas vezes concluir corretamente as tarefas atribuídas. O trabalho de nível sénior é diferente.

Para um sénior, a pergunta não é apenas «Construí o que me pediram?» É também:

  • Isto resolveu o problema certo?
  • Reduziu ou aumentou o risco futuro?
  • A equipa consegue compreendê-lo e mantê-lo?
  • Tornei visíveis os trade-offs?
  • Deixei o sistema mais fácil de alterar?

Os projetos reais raramente têm informação perfeita, tempo perfeito ou requisitos perfeitos. A senioridade é a capacidade de tomar boas decisões mesmo assim.

Restrições comuns:

  • O prazo é fixo, mas o âmbito não é claro.
  • A base de código tem comportamentos legados que ninguém compreende por completo.
  • A arquitetura ideal é demasiado cara para a fase atual.
  • O negócio quer rapidez, mas o sistema já tem problemas de qualidade.
  • A equipa não está de acordo quanto à abordagem.
Um programador sénior não é apenas alguém que sabe mais sintaxe. Um programador sénior melhora os resultados de forma fiável em situações de incerteza.
— Introdução, p. 7

Quatro capacidades, treinadas em conjunto

  1. Profundidade técnica

    Compreende código, sistemas, dados, testes, desempenho e operações.

  2. Discernimento de produto

    Consegue ligar as escolhas de engenharia aos resultados para o utilizador e para o negócio.

  3. Capacidade de entrega

    Consegue decompor o trabalho, reduzir o risco e concluir incrementos que acrescentam valor.

  4. Atitude de liderança

    Melhora as pessoas e o sistema à sua volta sem esperar que lhe deem autoridade.

Este guia treina estas capacidades em paralelo.

Ler grátis a introdução e o capítulo 1 →

O livro em 75 segundos

Páginas reais e os números da própria capa, com música. Não há narração; a transcrição está a seguir ao vídeo.

Ler a transcrição
  1. 0:00Ser sénior não é apenas ter mais anos de experiência… saber mais sintaxe…
  2. 0:05A senioridade é discernimento perante restrições. Capítulo 01 · A mentalidade do engenheiro sénior A senioridade é a capacidade de tomar boas decisões mesmo assim.
  3. 0:13Guia · 1.ª edição Tornar-se engenheiro sénior. Guia prático para programadores full-stack Capítulos 12 Conceitos 134 Listas de verificação 8 Modelos 4 Plano de implementação 1
  4. 0:20A ideia central Quatro capacidades, treinadas em conjunto. 01 Profundidade técnica 02 Discernimento de produto 03 Capacidade de entrega 04 Atitude de liderança
  5. 0:27Índice 12 capítulos. Cada capítulo termina com um exercício prático. A senioridade é discernimento perante restrições · 13 / 220
  6. 0:358 listas de verificação. Decisões Preparação de funcionalidades Revisão de código Testes Modelação de dados Desempenho Operações Liderança
  7. 0:424 modelos para preencher. Registo de decisão de arquitetura (ADR) Documento de design Registo de evidências Plano de projeto Listas de verificação e modelos que pode usar logo na segunda-feira.
  8. 0:50Parte IV Projeto final: um plano de implementação completo. Laravel · Vue · MariaDB · Docker Compose §1–§16
  9. 0:55Dicionário de conceitos 134. Resumo · explicação · exemplo · armadilha comum · sugestão para praticar Com o termo original em inglês. Acoplamento · Coupling
  10. 1:02PDF e EPUB. PDF · 220 páginas EPUB Pensado para ser lido sem acesso à internet. Sem DRM
  11. 1:08Tornar-se engenheiro sénior. Guia prático para programadores full-stack 1.ª edição · 2026 PDF · EPUB · Sem DRM Publicado pela Feitura feitura.com

Doze capítulos, doze evidências.

Cada capítulo termina com um exercício prático, e cada exercício deixa algo feito: uma nota, um plano, um teste, uma medição. Como diz o livro: «As evidências são o que separa uma confiança vaga de uma prova de nível sénior.» (p. 8)

O que o exercício prático de cada capítulo lhe deixa
N.ºTERÁ FEITOORIGEM
01Uma nota de decisão de uma página: as opções consideradas, porque escolheu uma delas e o que o faria mudar de ideias.Cap. 01 · p. 17Cap. 01 · p. 17
02Uma nota antes de construir: os conceitos do domínio, as fronteiras, os estados inválidos a excluir e o que significa «concluído».Cap. 02 · p. 24Cap. 02 · p. 24
03Dois esquemas de base de dados, desenhados antes de programar: devoluções de encomendas e revisões de artigos.Cap. 03 · p. 33Cap. 03 · p. 33
04Uma nota de design de uma página para alertas de stock baixo, suficientemente clara para outro programador a contestar.Cap. 04 · p. 40Cap. 04 · p. 40
05Os testes de «adicionar linha a uma encomenda», concebidos antes da implementação.Cap. 05 · p. 46Cap. 05 · p. 46
06Um método de controlador refatorado em três rondas: Form Request, classe de ação ou de serviço, Resource.Cap. 06 · p. 52Cap. 06 · p. 52
07Uma nota de desempenho com números de antes e depois, medidos sobre 10 000 encomendas de teste.Cap. 07 · p. 58Cap. 07 · p. 58
08Um manual de operação (runbook) que permite aos outros ter sucesso sem precisarem de si na sala.Cap. 08 · p. 65Cap. 08 · p. 65
09A mesma decisão escrita de três formas: para programadores, para as partes interessadas do produto e para quem vier a manter o código.Cap. 09 · p. 71Cap. 09 · p. 71
10Uma nota de liderança sobre um atrito recorrente, e uma pequena mudança posta em prática.Cap. 10 · p. 77Cap. 10 · p. 77
11Um plano de projeto para a primeira fatia de um MVP: resultado, riscos, critérios de aceitação e passos da demonstração.Cap. 11 · p. 84Cap. 11 · p. 84
12Um ficheiro evidence-log.md, com uma entrada por semana.Cap. 12 · p. 90Cap. 12 · p. 90

A história de um sénior

Com o tempo, o seu portefólio deve contar uma história coerente:

«Consigo identificar um problema importante, conceber uma solução prática, implementá-la com qualidade, comunicar os trade-offs, reduzir o risco operacional e ajudar os outros a compreender o trabalho ou a dar-lhe continuidade.»
— Capítulo 12, p. 88

Para quem é, e para quem não é.

É para si se…

  • É programador full-stack e quer trabalhar a nível sénior. É exatamente para si que o livro foi escrito.

  • Aprende na prática. Cada capítulo termina com um exercício prático, o livro pede-lhe que aplique cada capítulo a um projeto real, e a Parte IV dá-lhe um plano completo para construir, se não tiver nenhum.

  • Consegue dedicar-lhe algumas horas por semana. O livro sugere 8 a 12 horas por semana, um capítulo ou parte de um de cada vez, e a mesma estrutura com menos volume se tiver menos tempo.

  • Quer uma referência sempre à mão. 8 listas de verificação, 4 modelos para preencher e 134 conceitos de A a Z, cujas entradas têm ligações a partir dos capítulos.

Não é para si se…

  • Procura preparação para entrevistas. Aqui não há nada sobre algoritmos, entrevistas técnicas ou negociação salarial.

  • Quer a promessa de uma promoção. O livro treina a forma como decide e ajuda-o a reunir evidências disso. Não promete um cargo nem um aumento.

  • Precisa de código em React, Node ou Python. Os exemplos de código são excertos curtos de PHP e Laravel, e o plano de implementação usa Laravel, Vue, MariaDB e Docker Compose. O raciocínio aplica-se; o código não.

  • Procura microsserviços ou Kubernetes. O plano de implementação escolhe de propósito um monólito modular: «Nada de microsserviços. Nada de Kubernetes.» (p. 122)

  • Quer uma leitura rápida. Os capítulos são curtos, mas o livro pede-lhe que pratique entre eles: «Não tente absorver tudo depressa.» (p. 8)

Índice

Doze capítulos curtos, em três partes. Depois, a metade prática do livro: um plano de implementação completo, uma caixa de ferramentas e uma referência de A a Z.

Como se distribuem as 220 páginas

  1. Abertura e introduçãopp. 1–10
  2. 12 capítulospp. 11–90
  3. Plano de implementaçãopp. 91–128
  4. Caixa de ferramentaspp. 129–144
  5. Glossário e dicionário de conceitospp. 145–218
  6. Sobre a editora e contracapapp. 219–220
Os capítulos são curtos, e o livro pede-lhe que ponha cada um em prática. A maior parte das páginas é o plano de implementação, a caixa de ferramentas e a referência a que vai voltar.
Introdução · Como usar este guia Amostra grátis →6–10

Parte I Pensar como um sénior 11–24

  1. A mentalidade do engenheiro sénior12–17
    Secções do capítulo 01
    NESTE CAPÍTULOPÁGINA
    Das entregas aos resultados13
    A senioridade é discernimento perante restrições13
    Os três horizontes14
    Responsabilidade sem controlo14
    Bom gosto em engenharia15
    Os modos de falha do sénior16
    Um método prático para decidir como um sénior16
    Exercício prático17
    «Um programador sénior não espera que toda a incerteza desapareça. Reduz a incerteza deliberadamente.»
    p. 13
    Amostra grátis →
  2. Fundamentos de engenharia18–24
    Secções do capítulo 02
    NESTE CAPÍTULOPÁGINA
    Os fundamentos não são temas para principiantes19
    O código deve exprimir a intenção19
    Manter as unidades suficientemente pequenas para se compreenderem20
    Tornar os estados inválidos mais difíceis de representar20
    As fronteiras importam21
    Ciclos de feedback21
    Disciplina de depuração22
    A definição de concluído para o trabalho de nível sénior23
    Exercício prático24
    «Depurar não é adivinhar em voz alta. É reduzir a incerteza.»
    p. 22

Parte II Conceber e construir sistemas 25–58

  1. Modelação do domínio e dados26–33
    Secções do capítulo 03
    NESTE CAPÍTULOPÁGINA
    Os modelos de dados são decisões de produto27
    Começar pela linguagem27
    Relações28
    As restrições são ferramentas de design29
    Normalização e desnormalização30
    Os campos de estado precisam de um significado claro31
    Eliminação lógica ou física?31
    Lista de verificação para o design de dados32
    Esboço do esquema para os dois exemplos32
    Exercício prático33
    «[A] desnormalização não é errada, mas tem de se pagar.»
    p. 30
  2. Arquitetura e design de sistemas34–40
    Secções do capítulo 04
    NESTE CAPÍTULOPÁGINA
    A arquitetura tem a ver com mudança35
    Começar pelas forças35
    A lógica do monólito modular36
    Organização em camadas36
    Evitar abstrações prematuras37
    Perguntas de design de sistemas37
    Registos de decisão de arquitetura (ADR)38
    Exemplo de decisão: sistema de notificações38
    Sinais de alerta na arquitetura39
    Exercício prático40
    «Uma boa arquitetura não é o maior design possível. É a estrutura mais pequena que mantém em aberto as opções importantes.»
    p. 35
  3. Estratégia de testes41–46
    Secções do capítulo 05
    NESTE CAPÍTULOPÁGINA
    Os testes são uma ferramenta de design42
    A pirâmide de testes, na prática42
    Comportamento acima da implementação42
    O que testar primeiro43
    Os nomes dos testes devem ensinar43
    Factories e preparação dos dados44
    Os testes de integração são valiosos44
    Evitar testes frágeis45
    Testes de regressão45
    Nota de estratégia de testes45
    Exercício prático46
    «Os engenheiros seniores sabem que testar tudo não é o mesmo que testar com sensatez.»
    p. 46
  4. Refactoring e código legado47–52
    Secções do capítulo 06
    NESTE CAPÍTULOPÁGINA
    Código legado é código em que se tem medo de mexer48
    Primeiro, compreender o comportamento48
    Testes de caracterização48
    Pequenos passos de refactoring49
    Separar o refactoring da mudança de comportamento49
    Quando não refatorar50
    Refatorar um fluxo de encomendas legado50
    A regra do escuteiro, com conta, peso e medida51
    Lista de verificação para refactoring52
    Exercício prático52
    «Passos pequenos reduzem o medo.»
    p. 49
  5. Desempenho e escalabilidade53–58
    Secções do capítulo 07
    NESTE CAPÍTULOPÁGINA
    O desempenho começa pela medição54
    Pontos de estrangulamento comuns em aplicações web54
    A escalabilidade não é só tráfego55
    Cache56
    Orçamentos de desempenho57
    Ler o plano de execução57
    Exercício prático58
    «Os programadores seniores não otimizam com base em meros palpites.»
    p. 54

Parte III Operar, comunicar e liderar 59–90

  1. Operações e fiabilidade60–65
    Secções do capítulo 08
    NESTE CAPÍTULOPÁGINA
    O código corre algures61
    O desenvolvimento local faz parte da fiabilidade61
    Configuração62
    As migrações são eventos operacionais62
    Noções básicas de observabilidade63
    Pensar em incidentes63
    Deploy e rollback64
    Os trade-offs da fiabilidade64
    Exercício prático65
    «Um bom manual de operação é um artefacto de liderança: permite que os outros tenham sucesso sem precisarem de si na sala.»
    p. 65
  2. Comunicação técnica66–71
    Secções do capítulo 09
    NESTE CAPÍTULOPÁGINA
    A comunicação faz parte da engenharia67
    A clareza vale mais do que a exaustividade67
    Escrever para públicos diferentes68
    Pontos de situação69
    Comunicar na revisão de código69
    Discordância70
    Documentação que se lê70
    Exercício prático71
    «O objetivo não é ganhar. O objetivo é melhorar a decisão.»
    p. 70
  3. Liderança e influência72–77
    Secções do capítulo 10
    NESTE CAPÍTULOPÁGINA
    Liderar é criar melhores resultados através dos outros73
    O multiplicador sénior73
    Mentoria74
    Segurança psicológica e exigência74
    Delegação75
    Liderar a mudança técnica75
    Lidar com conflitos76
    Evidências de liderança76
    Exercício prático77
    «Segurança sem exigência transforma-se em mediocridade confortável. Exigência sem segurança transforma-se em medo.»
    p. 74
  4. Gestão de projetos para engenheiros78–84
    Secções do capítulo 11
    NESTE CAPÍTULOPÁGINA
    A gestão de projetos é gestão de riscos79
    Definir o resultado79
    Dividir o trabalho em fatias80
    Dependências80
    Estimativas81
    Registo de riscos81
    Ritmo do projeto82
    Controlo do âmbito82
    Definição de preparado e de concluído83
    Exercício prático84
    «As estimativas não são promessas. São previsões feitas sob incerteza.»
    p. 81
  5. Portefólio sénior e evidências85–90
    Secções do capítulo 12
    NESTE CAPÍTULOPÁGINA
    A senioridade tem de se tornar visível86
    Categorias de evidências86
    A história de um sénior88
    Rotina mensal de evidências88
    O que conta como boas evidências88
    Perguntas de autoavaliação89
    Exercício prático90
    «O objetivo não é a vaidade. O objetivo é a clareza.»
    p. 86

Parte IV Projeto final: um plano de implementação completo 91–128

Aplicação de gestão de projetos — plano de implementação de referência (v1)Ver o plano ↓

Parte V Caixa de ferramentas 129–144

Listas de verificação · Modelo de ADR · Modelo de documento de design · Registo de evidências · Modelo de plano de projetoVer a caixa de ferramentas ↓

Parte VI Referência 145–218

Glossário · Dicionário de conceitosVer a referência ↓

Sobre a Feitura219–220

Páginas reais, não maquetas

Estas páginas vêm do PDF que descarrega, composto em Archivo e IBM Plex Mono. Abra qualquer uma em tamanho real.

p. 12 / 220 · Abertura do capítulo 01 · Das entregas aos resultados

Leia grátis a introdução e o capítulo 1

As páginas 6 a 17 do livro, palavra por palavra, no browser, ou as primeiras 17 páginas do livro em PDF. Sem email e sem registo.

O que a amostra gratuita contém
NA AMOSTRAQTD.
Páginas6–17
Introdução · secções8
Capítulo 01 · secções8
Exercício prático1

Um excerto do capítulo 01

Os modos de falha do sénior

Cuidado com estas armadilhas:

A armadilha do herói
Resolve tudo sozinho, depressa e em silêncio. …
A armadilha do astronauta da arquitetura
Cria complexidade para possibilidades futuras que podem nunca se concretizar. …
A armadilha do cínico
Já viu muitos fracassos e, por isso, passa a desvalorizar tudo. …
A armadilha da otimização local
Otimiza o seu ticket, mas prejudica o sistema como um todo. …
Ler as quatro, e o resto do capítulo 1 →

Fraco, depois mais sólido.

Ao longo dos capítulos, os conselhos vêm muitas vezes com um exemplo fraco ao lado de um mais sólido. Eis três, tal como aparecem no livro:

Um ponto de situação

p. 69

FRACO

  • «A trabalhar na API de faturação.»

MAIS SÓLIDO

«O endpoint de criação de faturas está implementado e passa nos testes de funcionalidade. O processamento de reembolsos parciais está bloqueado porque não é clara a regra que define se as faturas já liquidadas podem ser alteradas ou se têm de dar origem a uma nota de crédito. Recomendo que se proíbam as alterações diretas e que, em vez disso, se crie uma nota de crédito explícita, o que mantém limpo o histórico de auditoria. A seguir, vou acrescentar os testes do fluxo de notas de crédito, a não ser que decidamos de outra forma.»

Um comentário de revisão de código

pp. 69–70

FRACO

  • «Isto está mal.»

MAIS SÓLIDO

«Este controlador passou a tratar da validação, da persistência e da formatação da resposta. Podíamos mover a validação para um Form Request e a lógica de escrita para uma classe de ação (action)? Assim, o endpoint ficaria mais fácil de testar e as futuras alterações ao controlador seriam mais pequenas.»

Evidências para o seu portefólio

p. 89

FRACO

  • «Melhorei a arquitetura.»
  • «Trabalhei no desempenho.»
  • «Ajudei a equipa.»

MAIS SÓLIDO

«Reduzi de 17 para 4 o número de consultas no detalhe da encomenda ao aplicar carregamento antecipado (eager loading) de forma seletiva e ao ajustar o formato da resposta. Documentei por que razão se evitou o carregamento antecipado completo no endpoint da lista de encomendas, onde o custo era superior ao benefício.»

«A revisão não é lugar para exibir superioridade. É um lugar para melhorar o código e a equipa.»
— Capítulo 09, p. 70

Um plano de implementação completo para uma aplicação web full-stack.

Uma aplicação web de gestão de projetos, planeada como um sénior a planearia: resultados, modelo de domínio, esquema da base de dados, contrato da API, arquitetura, testes, operações, desempenho, segurança, riscos, um roteiro em fatias e o guião da demonstração.

Neste plano

As secções do plano de implementação e a página onde começa cada uma
—NESTE PLANOPÁGINA
—Em resumo93
§1Visão e resultados94
§2Modelo de domínio95
§3Esquema da base de dados97
§4Contrato da API100
§5Arquitetura da aplicação104
§6Arquitetura do frontend105
§7Fluxos de trabalho (percursos do utilizador em fatias)108
§8Estratégia de testes112
§9Operações113
§10Orçamento de desempenho116
§11Segurança e autorização118
§12Riscos e trade-offs120
§13Roteiro de implementação (fatias)123
§14Definição de concluído (todo o projeto)124
§15Guião da demonstração125
§16Notas de execução para o agente125

FIXADO NO PLANO

MariaDB 11.4 LTS · PHP 8.4 · Laravel 13 · Vue 3.5 · Docker Compose

É um plano escrito, não código-fonte: construí-lo é o exercício. Cada fatia indica os capítulos que põe em prática. As versões ficam fixadas tal como o plano foi escrito, e o próprio livro recomenda consultar a documentação atualizada antes de aplicar em produção qualquer pormenor.

«O plano está organizado para que uma pessoa o possa ler como um documento de design de nível sénior e um agente de implementação o possa executar do princípio ao fim.»
— Em resumo, p. 93

O plano em números

O que o plano de implementação especifica
NO PLANOQTD.
Papéis3
Entidades8
Invariantes6
Tabelas da base de dados9
Endpoints REST27
Fluxos de trabalho (W1–W10)10
Fatias de entrega (S1–S14)14
Passos do guião da demonstração10
Passos ordenados para um agente de implementação21

Matriz de transições de estado

De / para, nas tarefas. «sim» significa que a mudança é permitida.
DE / PARAtodoin_progressblockeddonecancelled
todo—simsimnãosim
in_progresssim—simsimsim
blockedsimsim—nãosim
donesimnãonão—não
cancelledsimnãonãonão—

§11 · p. 119 · As transições ilegais devolvem 409 Conflict.

Listas de verificação e modelos que pode usar logo na segunda-feira.

A caixa de ferramentas é a parte que vai reutilizar: 8 listas de verificação e 4 modelos para preencher. Experimente aqui a primeira lista.

CAIXA DE FERRAMENTAS · P. 130

Lista de verificação para decisões de nível sénior

Lista de verificação para decisões de nível sénior

0 de 7 assinaladas

Experimente-a numa decisão que tenha de tomar esta semana. Nada fica guardado.

Oito listas de verificação

As listas de verificação da caixa de ferramentas e o número de pontos de cada uma
LISTAPONTOS
Decisões de nível sénior7
Preparar uma funcionalidade8
Revisão de código8
Testes7
Modelação de dados7
Desempenho7
Operações7
Liderança7

Quatro modelos para preencher

Os modelos da caixa de ferramentas, as páginas e os campos
MODELOPÁGINA
Modelo de ADRTítulo · Estado · Contexto · Decisão · Alternativas consideradas · Consequências · Gatilho de revisão133
Modelo de documento de designProblema · Objetivos · Fora do âmbito · Utilizadores e fluxos de trabalho · Solução proposta · Modelo de dados · Design da API · Design do frontend · Estratégia de testes · Notas operacionais · Riscos · Questões em aberto · Critérios de aceitação136
Registo de evidênciasData · Trabalho concluído · Competência sénior praticada · Artefacto criado · Decisão ou trade-off · O que aprendi · O que melhoraria · Prova (link ou ficheiro)140
Modelo de plano de projetoResultado · Âmbito · Marcos · Dependências · Riscos · Critérios de aceitação · Plano de testes · Plano de demonstração · Plano de comunicação · Perguntas para a retrospetiva142

Os modelos são páginas dentro do PDF e do EPUB, pensadas para serem preenchidas, com linhas para escrever. Não são ficheiros editáveis à parte.

134 conceitos, de A a Z.

Cada conceito tem a sua entrada: um resumo numa linha, uma explicação mais completa, um exemplo, uma armadilha comum, uma sugestão para praticar e, quando se aplica, os pontos do livro em que aparece. Os termos sublinhados ao longo dos capítulos levam diretamente até ela. Cada entrada indica também o termo original em inglês.

Reversibilidade

OUTROS TERMOSreversívelirreversívelReversibilityreversibleirreversible

A reversibilidade descreve a dificuldade de desfazer ou alterar uma decisão mais tarde.

As decisões muito reversíveis podem ser tomadas mais depressa. As decisões difíceis de reverter merecem mais design, mais comunicação e mais evidências. Os engenheiros seniores ajustam o processo de decisão à reversibilidade, em vez de tratarem todas as escolhas da mesma forma.

EXEMPLO
Mudar o texto de um botão é reversível. Escolher um modelo de dados que vai guardar registos de vários anos é muito mais difícil de reverter.
ARMADILHA COMUM
Pensar demasiado o design de escolhas reversíveis ou apressar as irreversíveis.
PARA PRATICAR
Classifique as próximas três decisões técnicas quanto à facilidade de reversão: fácil, média ou difícil.
NESTE LIVRO
  • Capítulo 1 · A mentalidade do engenheiro séniorp. 12
  • Capítulo 8 · Operações e fiabilidadep. 60
  • Caixa de ferramentas · Listas de verificaçãop. 130
  • Caixa de ferramentas · Modelo de ADRp. 133
Uma entrada, tal como está impressa na p. 207.

Os 134 conceitos

Todos os nomes, com a página onde começa cada entrada. Os resumos, os exemplos, as armadilhas comuns e as sugestões para praticar estão no livro.

Mostrar os 134 conceitos
  • Abstraçãop. 148
  • Acoplamentop. 149
  • ADRp. 149
  • Agregadop. 150
  • Alinhamentop. 150
  • API Resourcep. 151
  • Armadilha do heróip. 151
  • Arquiteturap. 152
  • Astronauta da arquiteturap. 152
  • Autorizaçãop. 153
  • Bloqueiop. 153
  • Cachep. 154
  • Camada de serviçosp. 154
  • Campo de estadop. 155
  • Carregamento antecipadop. 155
  • Chave estrangeirap. 156
  • Ciclo de feedbackp. 156
  • Clareza de intençãop. 157
  • Classe de açãop. 157
  • Cobertura de testesp. 158
  • Comportamento em cascatap. 158
  • Composablep. 159
  • Comunicação assíncronap. 159
  • Comunicação técnicap. 160
  • Configuração do ambientep. 160
  • Consulta N+1p. 161
  • Conteúdo pré-carregadop. 161
  • Contrato da APIp. 162
  • Controlador magrop. 163
  • Controlo do âmbitop. 163
  • Decisão pragmáticap. 164
  • Definição de concluídop. 164
  • Dependênciap. 165
  • Deploy segurop. 165
  • Deploy sem indisponibilidadep. 166
  • Desnormalizaçãop. 166
  • Disciplina de depuraçãop. 167
  • Disjuntorp. 167
  • Docker Composep. 168
  • Eliminação lógicap. 168
  • Engenharia insuficientep. 169
  • Estado inválidop. 169
  • Estados assíncronos da interfacep. 170
  • Estimativap. 170
  • Estratégia de logsp. 171
  • Evolução do esquemap. 171
  • Excesso de engenhariap. 172
  • Factory de testep. 172
  • Fatia de trabalhop. 173
  • Feature flagp. 173
  • Fixture de testep. 174
  • Forçasp. 174
  • Form Requestp. 175
  • Fronteirap. 175
  • Gatilho de revisãop. 176
  • Gestão de estadop. 177
  • Gestão de segredosp. 177
  • Gosto técnicop. 178
  • Hierarquia de componentesp. 178
  • Idempotênciap. 179
  • Incidentep. 179
  • Índice de base de dadosp. 180
  • Invariantep. 180
  • Investimento técnicop. 181
  • Isolamento dos testesp. 181
  • Iteraçãop. 182
  • Layout responsivop. 182
  • Limite de pedidosp. 183
  • Linguagem do domíniop. 183
  • Manual de operaçãop. 184
  • Manutenibilidadep. 185
  • Mentoriap. 185
  • Metadados da tabela de ligaçãop. 186
  • Middlewarep. 186
  • Migração da base de dadosp. 187
  • Mocksp. 187
  • Modelo de domíniop. 188
  • Modelo Eloquentp. 188
  • Monólito modularp. 189
  • Muitos-para-muitosp. 189
  • MVPp. 190
  • Norma de qualidade de códigop. 190
  • Normalizaçãop. 191
  • Objeto de valorp. 191
  • Observabilidadep. 192
  • Orçamento de desempenhop. 192
  • Organização dos testesp. 193
  • Organização em camadasp. 193
  • Otimização de consultasp. 194
  • Paginaçãop. 194
  • Parte interessadap. 195
  • Pipeline de CI/CDp. 195
  • Pirâmide de testesp. 196
  • Planeamento de capacidadep. 196
  • Ponto de situaçãop. 197
  • Portefólio de evidênciasp. 197
  • Portefólio séniorp. 198
  • Povoamento da base de dadosp. 198
  • Prevenção de regressõesp. 199
  • Procedimento de recuperaçãop. 199
  • Progressão de aprendizagemp. 200
  • Projeto finalp. 200
  • Qualidade do sinalp. 201
  • Refactoringp. 201
  • Registo de evidênciasp. 202
  • Relaçãop. 202
  • Relação entre modelosp. 203
  • Repetição espaçadap. 203
  • Responsabilidadep. 204
  • Restriçãop. 204
  • Restrição de dadosp. 205
  • Restrição de unicidadep. 205
  • Resultadop. 206
  • Retrospetivap. 207
  • Reversibilidadep. 207
  • Revisão de códigop. 208
  • Riscop. 208
  • Ritmo semanalp. 209
  • Rollbackp. 209
  • Senioridadep. 210
  • Simplicidadep. 211
  • Slugp. 211
  • Teste de caracterizaçãop. 212
  • Teste de comportamentop. 212
  • Teste de funcionalidadep. 213
  • Teste de ponta a pontap. 214
  • Teste de regressãop. 214
  • Trade-offp. 215
  • Transferência de conhecimentop. 215
  • Tratamento de eventosp. 216
  • Três horizontesp. 216
  • Validação de formulários no frontendp. 217
  • Validação dos dados de entradap. 217
  • Verificação de saúdep. 218

As duas edições. Os dois formatos. Um preço.

Inclui todas as atualizações 1.x, gratuitas, na sua conta.

ENCOMENDA

Encomendar o ebook

19 €

Preço final · as duas edições, os dois formatos

PT 220 pp. + EN 206 pp. · PDF + EPUB · versão 1.1 · 3,5 MB

Cartão, MB WAY, Multibanco e outros · Não vendemos a compradores no Reino Unido

Precisamos desta informação para os nossos registos fiscais.

Enviamos para aqui os links de transferência e a confirmação da encomenda. Também criamos a sua conta com este email, para poder voltar a descarregar os ficheiros mais tarde.

Dados para a fatura (opcional)

Deixe em branco para uma fatura sem NIF.

Antes de encomendar

O que compra:
Tornar-se engenheiro sénior, versão 1.1: a edição em português europeu (220 páginas) e a edição original em inglês, Becoming a Senior Engineer (206 páginas), cada uma em ficheiro PDF e EPUB 3, descarregadas deste site. Conteúdo digital fornecido sem suporte material.
Funcionalidade:
Sem DRM nem outras medidas de proteção técnica. O PDF é etiquetado, com marcadores e referências cruzadas clicáveis. O EPUB 3 foi validado com o EPUBCheck.
Compatibilidade:
Ficheiros nos formatos-padrão EPUB 3 e PDF, para as aplicações e os dispositivos de leitura que suportam estes formatos. Não testámos dispositivos nem aplicações em particular e não prometemos nenhum.
Preço total:
19 €. IVA – regime de isenção (art. 53.º CIVA). Sem custos adicionais.
Pagamento:
Cartão, Apple Pay, Google Pay, MB WAY, Multibanco, Klarna, Revolut Pay, Bancontact, Amazon Pay, Satispay ou Link, na página de pagamento segura da Stripe.
Entrega:
Imediata, assim que o pagamento for confirmado: links de transferência na página seguinte, por email e na sua conta. Sem suporte físico.
Atualizações:
Todas as versões 1.x, gratuitas, na sua conta. Enviamos-lhe um email quando sair uma nova.
Disponibilidade:
Não vendemos a compradores no Reino Unido.
Livre resolução:
Tem 14 dias para resolver o contrato, sem indicar motivo, mas os ficheiros só são vendidos com entrega imediata: na caixa abaixo, pede-a e reconhece que perde esse direito a partir do momento em que os ficheiros lhe são disponibilizados.
Garantia:
2 anos de responsabilidade por falta de conformidade (DL 84/2021).
Vendedor:
Identificação completa, contactos e livro de reclamações

Preço total: 19 €Pagamento pela Stripe. Nunca vemos o seu cartão.

O que recebe

O que inclui uma compra
RECEBEDETALHE
Edição portuguesa220 páginas
Edição original em inglês206 páginas
FormatosPDF + EPUB 3 de cada edição
PDFEtiquetado, com marcadores e referências cruzadas clicáveis
EPUBValidado com o EPUBCheck: 0 erros
DRMNenhum
Ficheiros4 · 3,5 MB no total
AtualizaçõesTodas as versões 1.x, na sua conta
Edição1.ª edição, 2026 · versão 1.1
Composto emArchivo e IBM Plex Mono
EditorFeitura
TOTAL19 €
Capa de Becoming a Senior Engineer, a edição original em inglêsCapa de Tornar-se engenheiro sénior, a edição portuguesa

O que acontece depois de pagar

  1. Paga na página segura da Stripe.

  2. Assim que o pagamento for confirmado, os quatro ficheiros ficam disponíveis na página seguinte, e os links chegam por email.

  3. A sua conta guarda sempre os ficheiros 1.x mais recentes, prontos quando precisar deles.

AINDA NÃO HÁ AVALIAÇÕES: JULGUE-O PELAS PÁGINAS. Ver as páginas ↑

O que recebo, exatamente?

Quatro ficheiros sem DRM: Tornar-se engenheiro sénior em PDF (220 páginas) e em EPUB 3, e a edição original em inglês, Becoming a Senior Engineer, em PDF (206 páginas) e em EPUB 3. Versão 1.1, 1.ª edição, 2026. Não há edição impressa. É um guia, não um romance: a introdução e os doze capítulos vão até à página 90, e o plano de implementação, a caixa de ferramentas e a referência de A a Z ocupam quase todo o resto.

Posso ler uma parte antes?

Sim. A introdução e o capítulo 1 estão disponíveis aqui, no browser, palavra por palavra, ou num PDF com as primeiras 17 páginas do livro. Não pedimos o seu email.

Ler grátis a introdução e o capítulo 1 →

Em que dispositivos e aplicações posso ler?

São ficheiros nos formatos-padrão EPUB 3 e PDF, para as aplicações e os dispositivos de leitura que suportam estes formatos. O EPUB adapta o texto ao ecrã, o que é prático num telemóvel. O PDF mantém a paginação do livro, mais confortável num tablet ou num computador. Não testámos leitores de ebooks nem aplicações em particular, por isso não prometemos nenhum: abra primeiro a amostra gratuita em PDF no seu dispositivo.

Ler grátis a introdução e o capítulo 1 →

Preciso de saber Laravel e Vue?

Não, mas ajuda. Os capítulos tratam de decisões, design, entrega e liderança, e o livro foi escrito para ser útil em qualquer projeto em que esteja a trabalhar. Quando mostra código, usa excertos curtos de PHP e Laravel. O plano de implementação da Parte IV fixa as versões para que foi escrito: Laravel 13, PHP 8.4, Vue 3.5, MariaDB 11.4 LTS e Docker Compose. Não há nada sobre React ou Python, nem sobre Node no back-end. As ferramentas mudam, como diz a ficha técnica do livro: consulte a documentação atualizada antes de aplicar em produção qualquer pormenor.

O plano de implementação inclui código-fonte?

Não. É um plano escrito, da §1 à §16: resultados, modelo de domínio, esquema da base de dados, contrato da API, arquitetura, fluxos de trabalho, testes, operações, orçamento de desempenho, segurança, riscos, um roteiro em fatias, uma definição de concluído, um guião de demonstração e 21 passos ordenados para o construir. O livro não inclui nenhum repositório: escrever o código é o exercício. O plano está escrito para que, nas palavras do livro, «um agente de implementação o possa executar do princípio ao fim»: um agente de programação pode seguir esses passos, desde a criação do projeto até à marcação da versão v1.0.0. Lê-se igualmente bem como documento de design, se o construir por si. O livro não ensina ferramentas de IA.

A edição portuguesa é uma tradução?

Sim. É a edição em português europeu do original inglês, Becoming a Senior Engineer, com os mesmos capítulos, o mesmo plano de implementação, a mesma caixa de ferramentas e os mesmos 134 conceitos. O dicionário de conceitos indica também o termo original em inglês de cada entrada.

Quem o escreveu?

A Feitura, um estúdio de criação de sites e software em Portugal, é a editora e surge como autora. O livro não tem assinatura pessoal. A melhor forma de o avaliar é o capítulo gratuito.

Ler grátis a introdução e o capítulo 1 →

Como funcionam as atualizações e a conta?

O livro está na versão 1.1. Todas as versões 1.x são gratuitas: quando sair uma, enviamos-lhe um email e a sua conta em feitura.com/conta passa a disponibilizar os ficheiros novos, nas duas línguas e nos dois formatos. As atualizações para lá da 1.x não estão incluídas. Não precisa de conta antes de pagar: quando compra, criamos uma para o seu email (o email inclui um link para escolher a palavra-passe) ou associamos a compra à conta que já tem na Feitura.

Posso pedir o reembolso?

Os ficheiros são entregues assim que o pagamento é confirmado. Por isso, ao encomendar, pede a entrega imediata numa caixa à parte e reconhece que perde o direito de livre resolução de 14 dias. A garantia legal de conformidade de 2 anos continua a aplicar-se: se um ficheiro tiver defeito ou não corresponder ao que está nesta página, responda ao email da encomenda e resolvemos, sem custos. Se não for possível, se não o fizermos num prazo razoável ou se a falta de conformidade for grave, tem direito a uma redução do preço ou, a não ser que a falta de conformidade seja mínima, à resolução do contrato, com o reembolso do preço.

Como pago, e recebo fatura?

Paga na página de pagamento segura da Stripe, por cartão, Apple Pay, Google Pay, MB WAY, Multibanco, Klarna, Revolut Pay, Bancontact, Amazon Pay, Satispay ou Link. Nunca vemos os dados do seu cartão. A Feitura emite uma fatura-recibo por cada encomenda e envia-a para o seu email; para incluir um NIF ou o nome de uma empresa, abra «Dados para a fatura» antes de pagar. Comprar não o inscreve em nenhuma newsletter.

Posso partilhá-lo com a minha equipa?

Cada compra é um exemplar pessoal, para um leitor: pode guardar os ficheiros nos seus dispositivos e imprimi-los para uso próprio, mas não os pode partilhar nem revender. A ficha técnica do livro não permite reproduzi-lo nem distribuí-lo sem autorização, salvo citações breves e algumas outras utilizações não comerciais permitidas por lei, por isso cada leitor precisa do seu exemplar.

Há desconto de lançamento?

Não. O preço é 19 €. Não há descontos de lançamento, contagens decrescentes nem preços riscados.

Porque não posso comprar a partir do Reino Unido?

Vender ebooks a consumidores no Reino Unido obrigaria a Feitura a registar-se para efeitos de IVA britânico logo na primeira venda, e a Feitura não tem esse registo. Por isso, não aceitamos encomendas do Reino Unido. A amostra gratuita está aberta a todos.

Ler grátis a introdução e o capítulo 1 →

Publicado pela Feitura, um estúdio de engenharia sénior.

Sites melhores. Software à medida.Feito para si.

A Feitura concebe e constrói sites, lojas online e aplicações web, aliando engenharia sénior a uma entrega acelerada por IA. Os hábitos deste guia (resultados claros, fatias pequenas e reversíveis, comportamento testado, trade-offs visíveis) são os mesmos que praticamos em cada projeto.
— Sobre a Feitura, p. 219

FEITO EM PORTUGAL.

feitura