Pular para o conteúdo

Builder OS

&
Builder · OS
L10 · Retrospectiva do git log
PRÓXIMA L11
~7 MIN DE LEITURA

Lição 10 de 13: Retrospectiva do git log

lição 10/13 do Módulo 3
AO FIM, VOCÊ VAI TER
  • Output de git log --oneline lido e analisado
  • Pelo menos 1 commit identificado como "podia ter sido melhor"
  • Arquivo docs/lessons-learned.md com 3-5 notas
  • Commit docs: lessons learned from slice 1

Por que olhar pra trás antes de seguir

Você tem 10-15 commits da fatia 1. A retrospectiva transforma esses commits em conhecimento durável que você consulta no próximo ciclo. Sem ela, você termina a fatia 1 mas não aprende com ela.

A retrospectiva tem três perguntas concretas. Você responde, documenta, e segue.

Passo 1 — Lê o git log

Cole no Claude:

prompt · text
Roda `git log --oneline -20` neste repo e mostra o output completo.

O output vai mostrar os commits desde o início. Algo como:

saída esperada
abc1234 feat(analytics): track recibo_emitido on create
def5678 feat(ui): recibo form connected to api
9012345 feat(api): POST /api/recibos with validation + insert
6789abc feat(validation): zod schema for recibo + cpf validator
ef01234 feat(db): add recibos table
5678901 docs(plans): write feat-pdf-recibo-MEI-sem-nfse for slice 1
2345678 chore(plans): rename feat-add-recibo to feat-pdf-recibo-MEI-sem-nfse
9abcdef docs(roadmap): 90-day roadmap
3456789 docs(product): initial product brief
fedcba9 feat(rules): add br-date-format rule
... (commits do Módulo 1)

Lê de cima pra baixo (mais recente primeiro) ou de baixo pra cima (cronológico). Pra cada commit, faz 3 perguntas.

Passo 2 — Aplique 3 perguntas a cada commit

Pergunta 1: O título do commit descreve o que mudou?

Bom: feat(api): POST /api/recibos with validation + insert, em que você sabe o que mudou só lendo. Ruim: wip, fix, update, changes, em que precisa abrir o diff pra saber o que mudou.

Se você tem 2-3 commits com título ruim, OK. Se tem 8, é sinal de que estava cansado ou com pressa. Anota como aprendizado.

Pergunta 2: O commit faz uma coisa só, ou várias?

Bom: schema da tabela num commit, validação noutro, route noutro. Cada um com 1 responsabilidade. Ruim: 1 commit que adiciona tabela + validação + route + UI ao mesmo tempo. Quando precisar reverter qualquer parte, vai ter que reverter o pacote todo ou fazer cherry-pick complicado.

Pergunta 3: Se eu fosse refazer esta fatia, qual decisão eu mudaria?

A pergunta é "o que eu faria diferente sabendo o que sei agora?", e não "o que faltou." Exemplos típicos pra fatia 1:

  • "Decidi cliente_cpf varchar(11) mas no caminho percebi que vou aceitar CNPJ também. Mudaria pra varchar(14) no schema original."
  • "Comecei sem teste E2E e adicionei só na L04. Começaria com teste vazio no L02 e ia preenchendo."
  • "Empacotei feat(db): add recibos table com a migration aplicada. Separaria em 2 commits: schema e migration aplicada."

Passo 3 — Registre 3-5 notas em docs/lessons-learned.md

prompt · text
Cria o arquivo docs/lessons-learned.md no repo com este shape:

# Lessons learned — fatia 1

## O que funcionou bem
- 3 itens curtos (1 linha cada) com decisões que vou repetir.

## O que eu faria diferente
- 3-5 itens curtos com decisões que eu mudaria, e por quê.

## Commits que vou imitar
- 1-2 títulos de commits desta fatia que ficaram bem feitos — quero seguir esse estilo nas próximas.

## Padrões que apareceram
- 1-2 observações sobre como eu trabalho (ex: "Tendo a empacotar mudanças demais num commit", "Esqueço de validar antes de aprovar quando estou apressado") — observações de comportamento, não de código.

Mostre o diff antes de criar.

Aprove. É registro pra você consultar quando começar a fatia 2 (e quando começar o segundo produto seu daqui a 6 meses).

Passo 4 — Faça o commit

prompt · text
Faça commit do docs/lessons-learned.md, com mensagem: docs: lessons learned from slice 1

Build Diary — o autor do CEAP registrou o que não funcionou

O CEAP tem o NOTAS_DO_AUTOR.md, e a seção mais útil dele é "o que tentei e não funcionou" (não "como fazer"). Trecho real:

Análise de Rede (Grafo Completo). Construí uma rede com NetworkX. Deputados como nós, fornecedores como nós, arestas ligando quem paga a quem.

Por que não funcionou: Com 650 mil transações, a rede virava uma bola de lã impossível de interpretar.

O que poderia funcionar: Em vez do grafo completo, segmentar por categoria de despesa.

E outras duas tentativas registradas com o mesmo formato: o que tentei / por que não funcionou / o que poderia funcionar.

A função desse arquivo é a mesma do seu lessons-learned.md: salvar o aprendizado enquanto ele ainda tem contexto. Daqui a 3 meses, você não vai lembrar por que decidiu cliente_cpf varchar(11) em vez de varchar(14). Vai abrir o arquivo, ver a nota, e ou (a) lembrar e manter a decisão, ou (b) ver que a razão original não vale mais e refatorar com confiança.

O arquivo cresce ao longo do produto. A L05 do Módulo 5 (Personal Pack) volta nele.

Takeaways

  • Retrospectiva é como você transforma 10-15 commits em conhecimento durável. Sem isso, o aprendizado evapora em 3 semanas.
  • 3 perguntas por commit: título descreve a mudança? faz uma coisa só? qual decisão você mudaria?
  • Registre o "o que NÃO funcionou": tem mais valor de longo prazo que o "o que funcionou." O que deu certo você lembra sozinho; a falha precisa do contexto anotado pra não repetir.
  • O arquivo lessons-learned.md cresce a cada fatia. M5/L05 volta nele pra compor seu Personal Pack.

Você terminou quando

Três coisas:

  1. git log --oneline lido com as 3 perguntas aplicadas
  2. docs/lessons-learned.md commitado com 3-5 notas honestas
  3. Você consegue dizer, em uma frase, qual foi sua maior aprendizagem da fatia 1