carlos schults / blog

Elaborando Ótimas Mensagens de Commit na Era da IA

Wed, 12 Aug 2026 00:00:00 +0000

Um tempo atrás, expliquei que as suas mensagens de commit são uma porcaria e o que fazer a respeito. Naquele post, falei rapidinho sobre IA, afirmando que não acho que o uso de LLMs (Large Language Models, ou Grandes Modelos de Linguagem) mude fundamentalmente nenhum dos pontos que levantei no post.

Mas o tema das mensagens de commit geradas por LLM é relevante o suficiente para merecer um post próprio, especialmente agora que cada vez mais pessoas estão usando agentes para gerar código.

É sobre isso que este post trata. Vou basicamente compartilhar minhas experiências sobre o que funciona e o que não funciona na hora de criar boas mensagens de commit.

Por Que LLMs Não São Automaticamente Boas em Criar Boas Mensagens de Commit

Quando se trata de escrever mensagens de commit, há uma área em que as IAs são muito boas: olhar para um diff e gerar um resumo.

Em outras palavras, elas se destacam em descrever o que você fez em detalhes… o que, se você leu meu outro post, sabe que é exatamente o que não é pra você fazer!

O que os LLMs não fazem bem é entender o contexto. Eles conseguem olhar para um diff e dizer algo como “Ok, o usuário desabilitou a cláusula OUTPUT do SQL Server na configuração do EF Core” e então escrever uma mensagem de commit detalhada descrevendo essas mudanças. O que é inútil, porque o diff do commit já mostra as mudanças.

O que o LLM não consegue fazer é descobrir que eu fiz a mudança porque tínhamos introduzido triggers em algumas tabelas e o EF Core começou a falhar porque a cláusula OUTPUT conflita com triggers, então tivemos que desabilitá-la.

Existe toda uma história por trás de uma mudança, e a AI não vai conseguir adivinhar essa história se ninguém contar pra ela.

A IA Não Lê Sua Mente

Vejo que muitas pessoas ficam frustradas com código gerado por IA, e é um padrão comum. As pessoas fazem um pedido vago pra caramba, depois recebem algo em troca, e então ficam frustradas porque não era o que tinham em mente. Bom, se você tem algo específico em mente que a IA deveria levar em conta, garanta que isso saia da sua cabeça e chegue até a IA!

Repitam comigo: a IA não lê mentes.

Além disso, a IA é incrivelmente confiante. Ela sempre vai te dar alguma coisa de volta. O que pode ser o que você quer, mais ou menos, mas também pode não ser, já que ela será tendenciosa em relação às abordagens que o LLM mais viu em seus dados de treinamento.

Por exemplo, se você pedir uma mensagem de commit para um diff, sem instruções adicionais, é bem provável que ela cuspa algo usando conventional commits, simplesmente porque muita gente usa esse padrão. Pessoalmente, não gosto desse padrão e não quero usá-lo, mas é claro que o Claude não sabe disso sobre mim a menos que eu diga.

O Que Fazer Então?

No outro post, compartilhei o prompt que eu estava usando com o Claude na época:

Write a concise, well-crafted commit message for the diff I'm going to give you.
Make it more high-level, focusing on the why rather than listing all changes in great detail.
Follow these rules:
- Summary
	- Brief description of what was done
	- 50 chars at the most
	- Use imperative mood
	- Do not use conventional commits
- Body
	- Brief description of the "how", but focus more on the reason for the changes
	- Use prose rather than bullet points.
	- Use past tense
	- Lines no longer than 72 chars

Eu não estava totalmente satisfeito com os resultados que estava obtendo com esse prompt, então continuei iterando sobre ele. Uma coisa que adicionei em algum momento foi que o Claude deveria me perguntar sobre o contexto quando não tivesse certeza. Isso funcionou, mas de forma um tanto inconsistente.

Então, não me lembro exatamente quando, outra coisa aconteceu. Mas antes de entrar nisso, preciso fazer uma pequena digressão e explicar por que não uso Conventional Commits.

Conventional Commits Não É um Bom Padrão

Não gosto nem uso Conventional Commits. No passado, eu usava, mas comecei a mudar de ideia depois de um tempo.

Por um bom tempo, não conseguia articular direito por que não gostava desse padrão, até ler este post de Sumner Evans.

A essência do motivo pelo qual Evans não gosta do Conventional Commits é que ele foca nas coisas erradas, tornando o tipo do commit (“feat”, “fix”, etc.) a informação mais importante, em vez do escopo. Ou seja, quais áreas ou partes do sistema o commit modifica.

O Conventional Commits costuma ser combinado com ferramentas que geram changelogs automaticamente e incrementam números de versão com base nas mensagens. Evans argumenta, e eu concordo, que isso é uma ideia fundamentalmente ruim.

Há mais motivos pelos quais esse padrão tão difundido não é tão bom quanto parece, mas vá ler o post do Evans para saber mais.

A pergunta então se torna: o que usar no lugar?

Chegam os Scoped Commits

Em seu post, depois de construir um argumento convincente contra o Conventional Commits, Evans oferece uma alternativa diferente. Baseado nos padrões usados por projetos open-source de sucesso, como Git, o kernel do Linux, Go, entre outros, ele propõe um novo padrão que chamou de Scoped Commits.

O básico desse padrão é incrivelmente simples. Você para de usar o tipo da mudança como prefixo da sua mensagem e passa a usar um escopo, que se relaciona à área, subsistema ou parte da sua aplicação que o commit afeta.

Este é um exemplo:

auth: Add SSO login controller

The login page previously relied on a legacy form-based flow that
was being decommissioned. Introduced a new controller and service
layer to handle SSO natively, preserving existing session logic
while decoupling it from the legacy system.

Closes: AB998

Chega a Skill do Claude

Foi mais ou menos nessa época que comecei a experimentar com skills do Claude, porque estava cansado de repetir as mesmas instruções sempre. Decidi tentar encapsular todas essas preferências em uma skill que eu pudesse usar. Depois de bastante tentativa e erro e reescritas, cheguei a algo que acho útil.

As partes mais importantes da skill, para mim, são as seguintes:

- Read the full diff carefully before writing anything
- If the scope isn't clear from the diff, ask one focused question
- **If the diff shows *what* changed but not *why*** — the underlying
  problem, bug, or motivation isn't inferable from the code itself — ask
  one focused question about the reason for the change before writing the
  body. A body written without knowing the "why" tends to just restate the
  diff in prose, which isn't useful. It's fine to write the summary line
  in the meantime, but hold off on the body until you know the reason, or
  proceed with summary-only (ticket in parentheses) if the user doesn't
  have more context to give.

Elas me ajudam a garantir que o Claude receba o contexto certo para a mudança. Caso contrário, ele vai apenas fornecer uma lista detalhada de mudanças, que não é o que estou buscando.

Se tiver interesse, veja a skill completa aqui.

Meu Veredito?

Estou razoavelmente satisfeito com os resultados que consigo com a skill até agora. Não é perfeita, porém.

Um problema que tenho com frequência é que o Claude às vezes “esquece” de usar a skill. Ele simplesmente segue em frente e escreve qualquer coisa como mensagem de commit, e aí eu tenho que dar uma bronca nele. Na maioria das vezes, ele usa a skill, então isso não chega a ser um grande problema.

Outro problema é que às vezes ele não respeita a regra do 50/72 para o comprimento máximo das linhas. As linhas no corpo da mensagem costumam chegar a 75 ou 76 caracteres. Às vezes, são necessárias duas ou três tentativas até ele acertar. Chega um ponto que eu desisto é conserto manualmente.

Por falar nisso, costumo alterar e editar a mensagem de commit gerada eu mesmo. Às vezes, falta uma parte crítica de contexto, ou o Claude entendeu algo errado, e é simplesmente mais fácil e rápido consertar por conta própria do que ficar insistindo com o clanker até ele fazer certo.

Então, qual é o veredito? No geral, estou satisfeito, mas certamente há espaço para melhorias.

O Que Você Deveria Fazer?

Você pode fazer o que quiser, claro, mas se está buscando conselhos sobre como obter as melhores mensagens de commit possíveis do seu LLM de preferência, aqui vai: garanta que você dê contexto a ele.

Você não precisa usar scoped commits, embora eu recomende experimentar. Você não precisa usar minha skill commit-message, nem nenhuma skill, se não quiser.

Apenas garanta que, seja qual for o fluxo de trabalho que você use para gerar mensagens de commit, exista uma etapa em que você forneça o contexto, o “porquê” por trás da sua mudança. Essa é a informação mais importante que uma mensagem de commit deve conter, e seu pequeno robô assistente não vai conseguir isso sozinho. Ele precisa da sua ajuda.

Operador LIKE do PostgreSQL: Um Guia Detalhado

Tue, 14 Jul 2026 00:00:00 +0000

ℹ️ Info

Nota editorial: escrevi esse post originalmente para o blog da CoderPad. Você pode conferir o original aqui, em inglês, no site deles.

Ao trabalhar com bancos de dados, precisar buscar valores que correspondam a um padrão é bem comum. Você pode querer achar todos os alunos que o sobrenome comece com uma determinada letra, ou atualizar todos os produtos cujo id contenha uma string específica. Se você usa PostgreSQL, vai usar o operador LIKE para isso.

Se você quer aprender mais sobre o LIKE do PostgreSQL, chegou ao lugar certo, já que este post é totalmente dedicado a esse operador. Ao final do post, você vai ter aprendido:

o que o LIKE do PostgreSQL faz, e por que você gostaria de usá-lo
como ele difere do operador LIKE em diferentes bancos de dados
como ele difere do operador ILIKE

Mas só teoria sem prática iriam tornar esse post chato demais. Então, antes de encerrar, você vai ver exemplos do operador LIKE na prática.

Pré-requisitos

Se você quiser acompanhar a parte prática do post, você vai precisar de:

instância funcional do PostgreSQL instalada na sua máquina
conseguir se conectar a essa instância através de um cliente
ter ao menos um pouco de experiência com o banco de dados PostgreSQL e com a linguagem SQL

LIKE do PostgreSQL: Fundamentos

Com os pré-requisitos resolvidos, vamos começar cobrindo alguns fundamentos sobre o assunto de hoje.

O Que É o `LIKE` do PostgreSQL?

O LIKE do PostgreSQL é a implementação, feita pelo PostgreSQL, do operador LIKE da linguagem SQL. Você usa o LIKE quando quer encontrar linhas nas quais uma ou mais colunas textuais correspondem a um determinado padrão. Na introdução, dei um exemplo: achar alunos cujo sobrenome comece com uma determinada letra. Então, vamos ver uma query real que faz exatamente isso usando o LIKE do PostgreSQL:

SELECT id, first_name, last_name, email FROM students WHERE last_name LIKE 'M%';

A query acima recupera algumas colunas da tabela students, mas apenas as linhas que atendem à condição: o valor da coluna last_name precisa começar com a letra “M”. Tem alguns pontos interessantes neste primeiro exemplo:

Você usa o operador LIKE na cláusula WHERE de uma query
Ele vai no mesmo lugar em que você colocaria qualquer operador de comparação, como “==”, “>”, “<”, e assim por diante
O caractere de porcentagem (%) é usado como um wildcard para corresponder a qualquer quantidade de caracteres

E se você quisesse apenas os alunos cujo primeiro nome termina com “k”? Simples, basta trocar a letra e o wildcard de posição:

SELECT id, first_name, last_name, email FROM students WHERE first_name LIKE '%k';

Outro exemplo: vamos buscar alunos cujo endereço de e-mail contenha a palavra “gmail”:

SELECT id, first_name, last_name, email FROM students WHERE email LIKE '%gmail%';

Isso mesmo: se você quer buscar valores que contenham uma string, basta envolver a string com sinais de porcentagem (%).

Qual a Diferença Entre LIKE e ILIKE no PostgreSQL?

Ao ler código PostgreSQL por aí, você pode encontrar queries que usam o operador ILIKE em vez do LIKE e ficar confuso. A diferença é que o operador LIKE diferencia maiúsculas de minúsculas (é case sensitive). Já o operador ILIKE não diferencia (é case insensitive) — daí o “i” no nome. Ele não distingue letras maiúsculas de minúsculas, e por isso você deveria usá-lo quando não se importa com a caixa das letras.

Um detalhe importante a se ter em mente: o operador ILIKE não existe no SQL ANSI; na verdade, é uma extensão específica do PostgreSQL. Isso significa que usar o ILIKE torna seu código SQL menos portável, caso você precise trocar de banco de dados no futuro.

LIKE do PostgreSQL: Casos de Uso Práticos

Tendo coberto o básico sobre o LIKE do PostgreSQL, vamos agora ver vários exemplos de uso. Vamos começar preparando o banco de dados para os testes.

Preparando o Banco de Dados

Usando seu cliente preferido, conecte-se à sua instância do PostgreSQL, garantindo que existe um banco de dados ao qual você pode se conectar para os testes.

Vamos começar criando uma tabela e inserindo algumas linhas nela:

CREATE TABLE albums (
  id              SERIAL PRIMARY KEY,
  title           VARCHAR(250) NOT NULL,
  artist          VARCHAR(250) NOT NULL,
  release_year int NOT NULL);

INSERT INTO albums (title, artist, release_year) VALUES('Abbey Road', 'The Beatles', 1969);
INSERT INTO albums  (title, artist, release_year) VALUES('Construção', 'Chico Buarque', 1971);
INSERT INTO albums  (title, artist, release_year) VALUES('The Dark Side of the Moon', 'Pink Floyd', 1973);
INSERT INTO albums  (title, artist, release_year) VALUES('Reckless', 'Bryan Adams', 1984);
INSERT INTO albums  (title, artist, release_year) VALUES('Ryan Adams', 'Ryan Adams', 2014);

Correspondendo a um Único Caractere

Como você viu, a tabela agora contém álbuns tanto do Bryan quanto do Ryan Adams. Isso não é coincidência. Primeiro, use a seguinte query para recuperar álbuns dos dois cantores:

SELECT * FROM albums WHERE artist LIKE '%yan%';

A query acima corresponde a todos os artistas que contenham a string “yan” em qualquer parte do nome. Veja como fica o resultado:

 id |   title    |   artist    | release_year 
----+------------+-------------+--------------
  4 | Reckless   | Bryan Adams |         1984
  5 | Ryan Adams | Ryan Adams  |         2014
(2 rows)

O operador LIKE oferece um wildcard adicional, o caractere de sublinhado (_), que corresponde a um único caractere. Dessa forma, é possível reescrever a query de modo que apenas Ryan Adams seja retornado:

SELECT * FROM albums WHERE artist LIKE '_yan%';

E aqui, novamente, está o resultado:

 id |   title    |   artist   | release_year 
----+------------+------------+--------------
  5 | Ryan Adams | Ryan Adams |         2014
(1 row)

Correspondências Negativas

Ao trabalhar com tabelas de banco de dados, muitas vezes você precisa recuperar dados que não correspondam a um certo padrão. Para isso, você pode usar o operador NOT LIKE. Por exemplo, vamos buscar apenas artistas cujo nome não comece com “The”:

SELECT * FROM albums WHERE artist NOT LIKE 'The%';

Já que o único artista que começa com “The” é The Beatles, ele não será retornado pela query acima.

Correspondência Sem Diferenciar Maiúsculas de Minúsculas

Como falei antes, o operador ILIKE é uma extensão especial do PostgreSQL para o LIKE que faz correspondências sem diferenciar maiúsculas de minúsculas. Vamos ver isso na prática. Primeiro, vamos usar o operador LIKE para obter todos os artistas que contenham um “A” maiúsculo:

SELECT * FROM albums WHERE artist LIKE '%A%';

Apenas “Bryan Adams” e “Ryan Adams” são retornados, o que faz sentido:

 id |   title    |   artist    | release_year 
----+------------+-------------+--------------
  4 | Reckless   | Bryan Adams |         1984
  5 | Ryan Adams | Ryan Adams  |         2014
(2 rows)

Agora vamos substituir o operador LIKE pelo ILIKE e rodar a query novamente:

SELECT * FROM albums WHERE artist ILIKE '%A%';

 id |   title    |    artist     | release_year 
----+------------+---------------+--------------
  1 | Abbey Road | The Beatles   |         1969
  2 | Construção | Chico Buarque |         1971
  4 | Reckless   | Bryan Adams   |         1984
  5 | Ryan Adams | Ryan Adams    |         2014
(4 rows)

Agora, todos os artistas são retornados, exceto Pink Floyd.

Escapando os Wildcards

Para este exemplo, vamos atualizar duas linhas:

UPDATE albums SET artist = 'The%Beatles' WHERE id = 1;
UPDATE albums SET artist = 'Chico_Buarque' WHERE id = 2;

Agora, digamos que queremos recuperar álbuns de artistas cujo nome contenha um sinal de porcentagem ou um sublinhado:

SELECT * FROM albums WHERE artist LIKE '%%%';
SELECT * FROM albums WHERE artist LIKE '%_%';

Como você provavelmente já imaginou, nenhuma das duas queries funciona: ambas retornam todas as linhas. Felizmente, existe uma forma de contornar esse problema: é possível escapar um wildcard para usá-lo como um caractere normal. Basta colocar uma barra invertida antes do caractere problemático:

SELECT * FROM albums WHERE artist LIKE '%\%%';

E aqui está o resultado:

 id |   title    |    artist     | release_year 
----+------------+---------------+--------------
  1 | Abbey Road | The Beatles   |         1969
(1 rows)

O mesmo funcionaria para o caractere de sublinhado. Mas, antes de encerrar, vamos complicar as coisas só um pouco mais — porque sim.

Primeiro, vamos atualizar a linha do “Abbey Road” mais uma vez:

UPDATE albums SET artist = 'The\Beatles' WHERE id = 1;

Agora, para usar o LIKE e recuperar uma linha que contenha o caractere de barra invertida, você teria que escrever esta query:

SELECT * FROM albums WHERE artist LIKE '%\\%';

Você precisa escapar o caractere de escape. Não é tão terrível assim, mas talvez você queira escrever uma versão mais legível. Se for esse o caso, é possível escolher um caractere diferente como caractere de escape: basta usar a cláusula ESCAPE:

SELECT * FROM albums WHERE artist LIKE '%$\%' ESCAPE '$';

Com a cláusula ESCAPE, você pode escolher um caractere diferente para servir de escape. Dessa forma — pelo menos na minha opinião — a query resultante fica mais explícita quanto à forma como escapa o wildcard.

Conclusão: LIKE do PostgreSQL — Aprenda e Aproveite

Neste post, você aprendeu sobre o operador LIKE no PostgreSQL: o que é, para que serve, e como funciona, através de vários exemplos. Como você viu, o funcionamento do operador é bem simples assim que você entende como os wildcards funcionam. Também percorremos alguns exemplos de uso, como correspondência a um único caractere e a realização de correspondências negativas.

Para onde ir agora? Para começar, continue aprendendo sobre correspondência de padrões no PostgreSQL. Aqui vão algumas sugestões de tópicos:

SIMILAR TO, uma cláusula mais recente
a função substring()
a função regexp_like()

Obrigado pela leitura, até a próxima!

Construindo o git em Go do zero - Parte 2

Fri, 29 May 2026 00:00:00 +0000

Bem-vindo de volta à minha jornada de construir o git do zero em Go, com o objetivo de aprender mais sobre os dois. Se você não sabe do que estou falando, leia o primeiro post.

Já faz um tempo

Eu postei o primeiro post em 9 de março. O que eu fiquei fazendo, e por que demorei tanto para continuar a série?

A resposta é o que você provavelmente já sabe: eu sou um adulto ocupado e não tenho muito tempo. Além disso, outros projetos pessoais também demandam atenção.

Mas chega de desculpa. Vamos falar sobre o que consegui implementar desde a última atualização.

Comandos Plumbing vs Porcelain

Antes de entrar em detalhes sobre o que implementei, preciso falar rapidinho sobre uma distinção que existe entre os comandos do git.

Quando você pensa em comandos do git, o que provavelmente vem à mente são coisas como git add, git init, git log, git status, e por aí vai. E mesmo isso só vale se você realmente usa a linha de comando. Muita gente usa interfaces gráficas para tudo e nunca aprende nem os comandos básicos.

Esses são os chamados comandos “porcelain”. São os comandos de alto nível, voltados para os usuários finais do git, como você e eu.

Existe outra camada de comandos, conhecida como comandos “plumbing”. Os comandos plumbing são os de baixo nível, que realizam a manipulação de dados que permite aos comandos de alto nível fazer o seu trabalho.

Recentemente, estive implementando alguns desses comandos plumbing que servem de fundação para grande parte do que o git faz. São eles: hash-object e cat-file.

Entendendo o `hash-object` e o `cat-file`

Vou falar rapidamente sobre o que esses comandos fazem antes de contar minha experiência. O hash-object é o comando usado para salvar dados como um blob (binary large object) dentro de um repositório git. Você passa um texto para o comando, ele salva um objeto com aquela informação e te devolve um hash SHA1.

O cat-file faz o oposto. Você passa um hash de objeto e ele retorna o conteúdo (ou o tamanho, ou o tipo, dependendo de como você o chama).

Calculando o hash do seu primeiro objeto

Quer testar? Execute o seguinte comando:

echo hi | git hash-object --stdin

Você deverá ver exatamente este hash como resultado: 45b983be36b73c0788dc9cbcb76cbb80fc7bb057.

ℹ️ Info

Se você está no Linux ou em outro sistema Unix, você provavelmente viu o resultado acima. O mesmo vale para Windows usando o Git Bash. Mas se você está no Windows usando o prompt de comando ou o PowerShell, o resultado provavelmente foi diferente. Isso acontece por causa das diferenças de terminadores de linha entre os sistemas.

O que aconteceu aqui é que o git calculou um hash para a string “hi” e o retornou para você. Usamos a flag --stdin para poder passar o conteúdo pela entrada padrão.

Porém, nada foi salvo em disco. Para de fato gravar os dados, você precisa usar uma versão diferente do comando, e desta vez dentro de um repositório.

Salvando um objeto

Vá para algum lugar, crie uma nova pasta e inicialize um repositório nela:

mkdir testing-commands
cd testing-commands
git init

Pronto. Agora você pode fazer o seguinte:

echo hi | git hash-object -w --stdin

O comando é parecido com o anterior, mas repare na flag extra -w. Ela significa write (escrever) e é o que faz o git salvar o conteúdo em um arquivo. Você ainda receberá o hash SHA1 como resposta, igual a antes, mas agora um novo objeto blob foi salvo em algum lugar. Quer ver?

Vá até a pasta onde o repositório foi criado, dentro de testing-commands. Use um explorador de arquivos, não a linha de comando. Ative as configurações necessárias para visualizar pastas e arquivos ocultos. Você verá uma pasta .git:

Entre nessa pasta e você verá basicamente esta estrutura:

├───hooks
├───info
├───objects   
└───refs
- config
- description
- HEAD

config, description e HEAD são arquivos; os outros são pastas. Entre na pasta objects. Você provavelmente vai encontrar as pastas info e pack lá. Elas não importam pra gente.

O que nos interessa aqui é uma pasta cujo nome tem dois caracteres. Se você executou os comandos acima no Linux ou no Git Bash do Windows, ela deve ser 45. Caso contrário, deve começar com os dois primeiros caracteres do hash que você recebeu ao rodar echo hi | git hash-object -w --stdin.

Entre nessa pasta. Dentro, você vai encontrar um arquivo cujo nome é formado pelo restante dos caracteres do hash. No meu caso, vejo b983be36b73c0788dc9cbcb76cbb80fc7bb057.

Esse é o seu blob. Esse arquivo é o objeto que o git salvou quando você executou o comando hash-object com a flag -w.

Lendo objetos de volta

Tente abrir o arquivo do blob no seu editor de texto favorito. O arquivo abre normalmente, mas o conteúdo é puro lixo que não dá pra ler. Isso porque ele está em formato binário comprimido, não em texto puro.

O que o git faz, em sequência, é o seguinte:

Cria um cabeçalho concatenando a palavra “blob”, um espaço e o tamanho do conteúdo em bytes. Por exemplo, blob 2.
Concatena isso com um caractere nulo.
Concatena o conteúdo real em seguida. No nosso exemplo, “hi”.
Gera o SHA1 da string completa.
Se você não usou a flag -w, o git retorna o SHA1 e para por aí.
Caso tenha usado a flag -w, o git comprime a string completa (cabeçalho + byte nulo + conteúdo).
Pega os dois primeiros caracteres do hash SHA1 e cria um diretório com esse nome dentro de objects.
Por fim, cria um arquivo dentro dessa pasta, com o nome formado pelos caracteres restantes do hash SHA1, e grava nesse arquivo o conteúdo comprimido com zlib.

Para ler esses dados de volta, você usa o comando cat-file com uma de suas flags. Para ler o conteúdo, use cat-file -p, onde -p significa “pretty print”:

git cat-file -p 45b983be36b73c0788dc9cbcb76cbb80fc7bb057

Ao executar o comando acima, você recebe “hi” de volta. Você também pode usar a flag -t para obter o tipo do objeto, ou -s para retornar seu tamanho em bytes:

git cat-file -t 45b983be36b73c0788dc9cbcb76cbb80fc7bb057
blob

git cat-file -s 45b983be36b73c0788dc9cbcb76cbb80fc7bb057
3

Implementação no Go-Gitter

Agora que você entende o que esses dois comandos fazem, vamos falar sobre como os implementei no go-gitter, começando pelo hash-object.

Implementando o `hash-object`

Meu primeiro passo foi implementar a versão mais básica do hash-object, sem a flag -w. O comando conseguiria exibir o hash SHA1 de um texto passado como argumento, mas ainda sem salvar nada em disco.

Como você pode ver no commit, o código está longe de ser um exemplo de código limpo. Ele mistura o parsing de argumentos com a lógica real no mesmo arquivo. Naquele ponto, eu ainda nem tinha criado funções separadas para cada comando, mas fiz isso depois.

A parte do código que realiza o hash em si acabou sendo bem simples, assim que entendi qual deveria ser o formato:

size := len(data)
header := fmt.Sprintf("blob %s%c", strconv.Itoa(size), 0)
content := header + string(data)
hash := sha1.New()
hash.Write([]byte(content))
hashedData := hash.Sum(nil)
hashedString := hex.EncodeToString(hashedData)
fmt.Println(hashedString)

Como você pode ver, criamos o cabeçalho concatenando a palavra “blob” mais um espaço com o tamanho do conteúdo e depois o caractere nulo, representado aqui pelo inteiro zero. Em seguida, hasheamos tudo, codificamos como string e imprimimos.

Precisei pesquisar um pouco para encontrar as bibliotecas necessárias e a sintaxe do Go, já que as regras que eu criei pra mim proíbem o uso de LLMs para geração de código, mas acabou dando certo.

No commit seguinte, adicionei suporte à flag -w. Nesse ponto, como você pode ver, criei uma função para o comando.

A diferença não é grande. O que acrescentei foi um parsing de argumentos bem simples para identificar se o conteúdo deve ser gravado em disco.

Então, o código que efetivamente faz a gravação:

if saveFile {
	// cria o diretório para o blob
	if err := os.Mkdir(".git/objects/"+folderName, os.ModePerm); err != nil {
		log.Fatal(err)
		os.Exit(1)
	}

	// comprime o conteúdo com zlib e salva o arquivo
	var buffer bytes.Buffer
	w := zlib.NewWriter(&buffer)
	w.Write([]byte(content))
	w.Close()
	if err := os.WriteFile(".git/objects/"+folderName+"/"+fileName, buffer.Bytes(), 0666); err != nil {
		log.Fatal(err)
		os.Exit(1)
	}
}

Demorei um pouco para acertar. Em grande parte porque, em determinado momento, eu estava entendendo completamente errado o que o git faz. Achei que deveria comprimir e salvar o hash que calculei. Sim, eu sei, não faz sentido nenhum, mas o que posso dizer?

Depois que entendi o fluxo correto, fazer funcionar foi principalmente uma questão de descobrir como usar a compressão zlib. O Google e a documentação resolveram, como nos bons tempos.

Implementando o `cat-file`

O cat-file foi mais fácil de implementar, porque é essencialmente o caminho inverso. A partir de um hash, localizar o arquivo correspondente, descomprimir o arquivo e ler o conteúdo.

Desta vez, criei uma função dedicada para o novo comando desde o início, como pode ser visto no primeiro commit. Esse commit implementa apenas a flag -p.

Abaixo está uma versão resumida do código desse commit, sem o boilerplate da função e também sem o tratamento de erros:

folderName := h[0:2]
fileName := h[2:]
fullPath := filepath.Join(".git/objects", folderName, fileName)

var contents []byte
var err error
contents, err = os.ReadFile(fullPath)

r, err := zlib.NewReader(bytes.NewReader(contents))

buf := new(strings.Builder)
_, err = io.Copy(buf, r)

uncompressedContents := buf.String()
contentsWithoutHeader := strings.Split(uncompressedContents, "\x00")[1]
r.Close()
fmt.Println(contentsWithoutHeader)

A variável h é o SHA1 recebido pelo comando. A partir dela, extraímos o nome do diretório e do arquivo, que usamos para montar o caminho completo, ler o conteúdo do arquivo e descomprimi-lo.

Por fim, faço um split da string pelo caractere nulo e retorno a segunda parte, que é tudo o que vem depois do cabeçalho.

O commit seguinte implementa as flags restantes. Não vou percorrer linha por linha, já que a parte importante é bem simples:

parts := strings.Split(uncompressedContents, "\x00")
flag := arguments[2]
var result string

switch flag {
case "-p":
    result = parts[1]
case "-t":
    result = strings.Fields(parts[0])[0]
case "-s":
    result = strings.Fields(parts[0])[1]
}

Para os programadores Go que estão lendo isso: eu sei que esse código não seja o mais bonito e idiomático que você já viu, e prometo que, conforme for aprendendo mais sobre a linguagem, vou refatorar. A prioridade no momento era fazer funcionar.

O que aprendi até agora

O objetivo deste projeto é aprender a linguagem Go e também mais sobre a implementação do Git. Então, o que aprendi sobre os dois ao completar esses dois comandos?

Primeiro, o lado do Git. Posso dizer que me surpreendeu a simplicidade com que o git salva objetos. É realmente só o tipo do objeto, um espaço, o tamanho, um caractere nulo como delimitador e o conteúdo. Eu entendia, em alto nível, como o git armazenava objetos, mas implementar de fato me deu uma nova apreciação pela simplicidade e elegância do design.

E sobre o lado do Go? De maneira geral, estou gostando muito. Eu gosto da legibilidade da linguagem. Acho que até alguém com zero experiência em Go conseguiria ler este código e ao menos entender a essência, desde que já seja programador.

Gosto também do fato de Go ser opinativo. Por exemplo, se você tem um if, precisa usar as chaves. Do contrário, o código não compila. Isso elimina mais uma coisa para os programadores brigarem, reuniões sobre padrões de código, regras de linter. Simplifica a vida.

Um aspecto que não gosto é o tratamento de erros. Ter aqueles if verificando err em todo lugar polui o código. Em C#/.NET, quando ocorre um erro que deveria ser absolutamente impossível, eu só deixo a exceção subir até o middleware de tratamento de exceções no nível mais alto, onde ela é logada e o usuário recebe uma mensagem com o nível adequado de detalhes.

Talvez exista alguma forma idiomática de fazer algo assim em Go também, mas por enquanto não conheço. Fora isso, estou gostando muito da linguagem.

O que vem a seguir?

Para o próximo passo vou implementar outro comando plumbing chamado update-index. Ele é necessário para eu poder stagear mudanças e eventualmente fazer commits.

Se quiser experimentar o go-gitter, instale assim:

go install github.com/carlosschults/go-gitter/ggt@latest

Depois é só usar os comandos assim:

echo hi | ggt hash-object --stdin
ggt cat-file -p 45b983be36b73c0788dc9cbcb76cbb80fc7bb057

Você deve conseguir fazer o hash de algo com o git de verdade e ler com o go-gitter, e vice-versa.

Obrigado por ler, e até a próxima atualização.

Suas Mensagens de Commit São Um Lixo. Vou Te Ajudar a Melhorar

Tue, 31 Mar 2026 00:00:00 +0000

Suas mensagens de commit são um lixo. Na melhor das hipóteses, elas são inúteis. Mas geralmente, elas são piores do que nada. Eu não digo isso pra ser babaca. Na verdade, é o contrário. Eu quero te ajudar.

Se você sabe que você é exceção pra isso, você pode parar de ler. É sério, fecha a aba e vai pro YouTube. Pronto, te dei alguns minutos de volta, de nada.

Se você ainda tá aqui, então você sabe que tem um problema. Como eu dizia, suas mensagens de commit não servem pra nada. Não fique ofendido. Isso não é culpa só sua. É bem provável que ninguém nunca te ensinou como escrever boas mensagens de commit, ou nem o porquê disso ser importante. E escrever é realmente muito difícil.

A boa notícia é que agora você finalmente tem alguém pra te ajudar. Nesse post, eu vou explicar tudo que você precisa saber sobre mensagens de commit horríveis, e o que fazer pra escrever as que não são horríveis.

Suas Mensagens de Commit São um Lixo Porque…

Por que a maioria das mensagens de commit é tão ruim? Na minha experiência, os motivos se resumem ao que vou falar agora. Vale lembrar que não tem nada de científico ou baseado em dados aqui. É tudo baseado na minha experiência pessoal.

…Você Só Liga pra Código

Se você é como a maioria dos devs, você só — ou quase só — liga pra codar. É onde a diversão mora, e tudo o mais você vê como perda de tempo. Eu sei também que você provavelmente está sob muita pressão pra performar, pra entregar o máximo de valor o mais rápido possível. Então o que você mais quer é terminar o que está fazendo, mergar o PR e então pegar outro ticket do Jira/Azure/Linear pra começar a implementar.

O que acaba acontecendo é que tudo que não é código é tratado como detalhe secundário e não recebe a devida atenção. Isso inclui testes, documentação, preparar uma revisão da feature implementada pra retrospectiva semanal e, claro, escrever mensagens de commit e descrições de PR.

…Às Vezes Você Não Entende o Que Está Fazendo

Boas mensagens de commit — e boa documentação em geral — devem focar no porquê das coisas. Qual é a motivação por trás das suas mudanças? Qual é o problema que você está tentando resolver, por que vale a pena resolvê-lo, de que forma isso ajuda seu time e sua empresa?

Pode parecer loucura que um programador comece a trabalhar numa tarefa que não entende completamente. Mas eu já fiz isso, e aposto que você também. E claro, como você vai explicar o porquê de uma mudança se nem você mesmo entende direito?

…Escrever é Difícil

Como Phil Karlton disse uma vez¹, só existem duas coisas difíceis em ciência da computação, e dar nome às coisas é uma delas.

Se você parar pra pensar, “dar nome às coisas” é uma forma de escrever. Um subconjunto da escrita, digamos assim. Então sim, escrever mensagens de commit é difícil porque escrever, em geral, é difícil.

…Ninguém Te Ensinou

Acho que a formação de desenvolvedores frequentemente falha em ensinar muita coisa importante que você realmente vai precisar como engenheiro de software. Tratamento de erros de verdade é um exemplo.

Tudo bem, eles vão te ensinar a mecânica de como um try-catch-finally funciona, mas raramente vão te ensinar quando capturar uma exceção, quando não capturar, quando lançar uma exceção, quando logar ou não, e assim por diante.

E escrever mensagens de commit é uma dessas coisas.

…O GitHub Te Ensinou Maus Hábitos

Vamos deixar uma coisa clara: eu uso o GitHub todo dia e gosto muito. O GitHub é o aplicativo matador/killer app do Git, e o Git não teria tido o mesmo nível de adoção sem ele.

Dito isso, acredito que a popularidade do GitHub e dos pull requests fez as pessoas se importarem mais com os PRs do que com os commits individuais. E faz sentido: pull requests suportam discussões que ficam como artefatos históricos do projeto, suportam anexos, texto rico e tudo mais.

Então faz sentido que algumas pessoas não se esforcem muito pra escrever boas mensagens de commit, argumentando que podem escrever descrições ricas no PR.

Claro que o que acaba acontecendo frequentemente é que elas não escrevem as descrições de PR também!

…A Flag `-m` do Git Te Viciou

Acho que a maioria dos programadores nem sabe que mensagens de commit podem ter um corpo com várias linhas. E a culpada aqui é a forma como a maioria das pessoas ensina o comando commit:

git commit -m "Alguma mensagem"

Sem nem mencionar que a flag -m é só uma conveniência pra quando você tem uma mensagem de uma linha, o que deveria ser a exceção, não a regra.

…Você Não Tem Higiene de Commits

Escrever mensagens de commit que não são lixo faz parte de algo mais amplo que algumas pessoas chamam de “higiene de controle de versão.”

É exatamente o que parece: não seja porco na hora de escrever código.

Às vezes você tem dificuldade pra escrever uma mensagem de commit porque trabalha de forma bagunçada. Se suas mudanças são uma salada de correções de bug, refatorações, código morto e ideias de implementação pela metade, claro que você vai ter problema pra escrever uma mensagem descritiva e útil.

Isso costuma ser causado por falta de domínio do Git. Se você não domina ferramentas como stash, reset, rebase interativo e outras, é mais provável que você transforme seu trabalho num caos.

Taxonomia das Mensagens de Commit Ruins

Descobri que mensagens de commit ruins se encaixam em algumas categorias. Vou cobrir algumas delas agora.

A Mensagem de Uma Linha Quase Inútil

Essa é a mensagem de uma linha que dá uma explicação superficial do que foi mudado. Eu chamo de “quase” inútil porque pelo menos o resumo é preciso.

Mas aí ela falha em dar qualquer contexto adicional. Fico com perguntas como:

Qual foi o problema que originou essa mudança?
Por que o autor considerou essa a melhor forma de resolver o problema?
Existe algum issue ou ticket associado a esse trabalho?

Alguns exemplos, com meus comentários:

Added new index to table # que índice? que tabela? com qual propósito?
Enable EF Core execution strategy # o que é essa tal "strategy"? por que você teve que habilitar?
Added Required attribute to model # qual model? isso não é uma breaking change que vai afetar os usuários atuais?

A Mensagem de Uma Linha Inútil

A mensagem de uma linha inútil é… bem, como a quase inútil, mas completamente inútil.

Os exemplos não precisam de mais comentários:

changes
ui
not working
more changes

Quer dizer, no momento em que você escreve “changes” como mensagem de commit, você poderia simplesmente escrever “batata”. Ou contar uma piada. Seria igualmente inútil, mas pelo menos poderia ter graça.

Só a Referência do Sistema de Tickets

É quando as pessoas colocam apenas o id de um issue/ticket/card do sistema de gerenciamento, e nada mais. Alguns exemplos:

JIRA-42
AZ-2234
#125

Acho que essa categoria consegue ser ao mesmo tempo mais útil e mais irritante do que as anteriores. Sim, é mais útil, já que posso sempre ir ao sistema de tickets, procurar o issue, e aprender mais sobre o trabalho. Claro, nada garante que o commit vai conter apenas mudanças relacionadas ao issue em questão, mas isso é conversa pra outro momento.

É mais irritante também porque obriga o leitor a parar e ir a outro lugar pra entender o contexto daquela mudança. Não sei você, mas eu prefiro aprender o motivo por trás de um commit pelo próprio commit, como ~~Deus~~Linus quis.

Além do incômodo, existe um risco maior aqui: a possibilidade de que, um dia, sua empresa migre do sistema de tickets atual e você fique sem aquelas descrições. Todas as empresas em que trabalhei como desenvolvedor fizeram pelo menos uma migração dessas, e tenho certeza que você já passou por pelo menos uma também.

A Mensagem de Uma Linha Enganosa

Às vezes você tem uma mensagem que parece inofensiva, como Add PrintHtmlOutput() method. Aí você vai ver as mudanças e elas também incluem uma breaking change em um endpoint ou alteram a forma como a aplicação interage com o banco de dados.

Você Vai Escrever Boas Mensagens de Commit Quando…

Agora você entende por que escreve mensagens ruins, e como elas são ruins. Pronto pra aprender a melhorar?

…Escrever Suas Mensagens Em Inglês

Um dos posts mais visitados desse blog discute se devemos escrever código em português ou inglês. Eu considero que fiz bons argumentos, mostrando os prós e constras de ambos os lados e deixando meu posicionamento bem claro.

Ainda assim, alguns leitores me acusaram de ficar em cima do muro.

Dessa vez, então, vou falar sem sombra de dúvida: ESCREVA SUAS MENSAGENS DE COMMIT EM INGLÊS. É simplesmente o padrão do mercado, e o quanto antes você se acostumar com isso, melhor.

E é por isso, inclusive, que os exemplos de mensagem de commit deste post estão todos em inglês. Eu escrevi o post originalmente em inglês e agora estou traduzindo para português, mas deixei as mensagens em inglês de propósito mesmo, por causa desse ponto.

…Parar de Escrever Mensagens de Uma Linha

Mensagens de uma linha são ótimas quando o escopo da mudança é pequeno. Se o seu commit só corrige um typo, então Fix typo é uma mensagem de commit válida. Mas na maioria das vezes os commits contêm muito mais mudanças, e nesses casos escrever uma mensagem de uma linha é uma oportunidade perdida de criar uma documentação duradoura.

Então, por favor, pare de usar a flag -m na hora de commitar. Escreva um corpo adequado com mais detalhes na maioria das suas mensagens.

…Começar pelo “O Quê”, Expandir com o “Por Quê” e o “Como”

Agora você sabe que deve escrever um resumo e um corpo na maioria das suas mensagens de commit. O que colocar em cada um?

Simples: comece com o resumo, descrevendo o que você fez. Seja descritivo, mas conciso.

No corpo, descreva qual é o problema que você está tentando resolver, ou o motivo que motivou a mudança. Em seguida, explique como você resolveu, mas de forma macro. Não entre em muito detalhe, porque lembre-se que seu leitor sempre pode ver o diff.

Se necessário, adicione mais informações, como:

trade-offs envolvidos na sua decisão
alternativas que você considerou mas decidiu não usar
links de referência para termos que possam ser desconhecidos (por exemplo, um link para um artigo da Wikipedia, ou para o Catálogo de Refatorações do Martin Fowler)
links de referência para a solução que você aplicou (por exemplo, um link para uma resposta no Stack Overflow)

…Seguir a Regra do 50/72

A regra do 50/72 é o mais próximo que temos de um padrão quando se trata de mensagens de commit. Foi proposta pela primeira vez por Tim Pope² e funciona assim:

Comece com um resumo, com a primeira letra maiúscula, com no máximo 50 caracteres
Adicione uma linha em branco
Em seguida, adicione um corpo, quebrando as linhas em no máximo 72 caracteres

Esses limites podem parecer arbitrários, mas existem razões históricas pra eles terem sido escolhidos. Pra resumir, eles funcionam bem com muitas ferramentas diferentes que trabalham com mensagens de commit.

Outro ponto importante: você deve escrever o resumo no modo imperativo. Ou seja, “Implement password hashing” em vez de “Implemented password hashing”, por exemplo. A princípio isso pode parecer estranho, mas é o padrão que o próprio Git usa. Se não acreditar, use git revert pra reverter um commit e vai ver que a mensagem gerada está no modo imperativo:

Revert "Add line of text"

This reverts commit 5ab08c5d3ee7bfdb334406d418d96f76d08962fe.

Viu? “Revert” em vez de “Reverted.”

Adicionalmente, e de forma opcional, você pode adicionar um trailer ao commit. Trailers são metadados que você pode adicionar no final da mensagem de commit, seguindo a sintaxe Nome: valor. Eles servem pra adicionar metadados úteis, como quem aprovou uma mudança, quem co-autorou algo com você, e também pra associar seu commit a um issue ou ticket.

Por exemplo, se você usa GitHub Issues, você pode adicionar um trailer assim:

Closes: #456

E ele vai automaticamente associar o commit ao issue e fechá-lo. Existem outras palavras-chave que você pode usar, como Fixes, Resolves, Resolved, e assim por diante. Você pode aprender mais sobre como fechar issues do GitHub automaticamente aqui.

…Adotar Commits Atômicos

A ideia dos commits atômicos é simples: um commit deve conter apenas mudanças logicamente relacionadas. É o oposto da falta de higiene de controle de versão que mencionei antes.

Digamos que você está trabalhando numa feature. Aí seu chefe te pede pra parar e corrigir um bug. Você vai lá e corrige o bug, e agora tem aquelas mudanças misturadas com as do início da sua implementação de feature.

Não commita tudo junto! Commita apenas as mudanças do bug fix como uma unidade coesa, com uma mensagem descritiva e de qualidade. Aí você volta pra sua feature e commita aquilo.

Fazer isso exige que você domine as ferramentas do Git. Você precisa saber como fazer stage das mudanças e commitar apenas aquelas em vez de tudo. Precisa saber usar o stash. Com frequência, vai precisar saber como commitar coisas e depois editar esse histórico.

Essas habilidades valem a pena ter. Vai atrás delas!

…Commitar Sempre, Polir Depois

Você não precisa esperar estar “pronto” pra commitar. Pelo contrário, você deve commitar o tempo todo. Trabalhe em incrementos pequenos e commite ao longo do caminho.

Assim, se cometer erros e precisar descartar algum trabalho, você vai reverter apenas alguns minutos de trabalho em vez de horas. Você também tem esses checkpoints pra voltar caso a luz caia ou algo do tipo.

Por exemplo, quem pratica TDD (desenvolvimento orientado a testes)³ frequentemente commita toda vez que chega na fase verde. Ou seja, toda vez que os testes passam.

Também é uma boa ideia manter todos os seus commits limpos. Com isso quero dizer que todos os seus commits, quando aplicados, devem deixar o projeto em um estado onde ele builda com sucesso e todos os testes passam. Isso facilita para você ou outra pessoa usar o git bisect no futuro pra encontrar onde um bug foi introduzido.

Mas se você seguir essa dica, pode acabar com muitos commits pequeninhos que não têm boas mensagens, ou que não representam um conjunto coeso de mudanças. Como resolver isso?

A resposta é: você edita seu histórico pra deixá-lo bonito. Editar o histórico é mal visto — e com razão — quando é uma branch da qual outras pessoas já dependem. Mas se você está trabalhando na sua própria branch isolada e ninguém depende das suas mudanças, você pode fazer o que quiser até aquele ponto. Então commite cedo e com frequência, e depois use amend e rebase até ter um histórico que faça sentido e tenha ótimas mensagens de commit.

Exemplos de Boas Mensagens de Commit

Finalmente chegou a hora de mostrar alguns exemplos de mensagens de commit valiosas que incorporam tudo que cobrimos até aqui.

Por exemplo, em vez de:

Added Required attribute to model

Escreva:

Make PhoneNumber required on /reservations endpoint

The /reservations endpoint originally didn't require a phone number.
The reservations were being accepted but, as data flowed to downstream
systems, the lack of phone number was causing some processes to crash.

We are now adding the [Required] attribute to the PhoneNumber property
on the ReservationRequestModel. This is a breaking change, so that's
why, as part of this changes, we are versioning the endpoint as 2.0

Fixes: AB#456

Veja como fica:

A mensagem começa com um resumo que descreve o que foi feito
O corpo começa com uma descrição do problema, depois explica como a mudança atual o resolve
Por fim, temos um trailer para associar e fechar um ticket no board

Para o segundo exemplo, vamos fazer algo um pouco mais elaborado. Em vez de Enable EF Core execution strategy, você pode usar:

Enable EF Core execution strategy for Azure SQL

After migrating to Azure SQL, save operations started failing
intermittently in production with transient connection errors.
Azure SQL occasionally drops connections during scaling events
and failovers, and Entity Framework does not retry failed
operations by default.

Enabled the built-in SQL Server execution strategy in EF Core,
which automatically retries failed operations using exponential
backoff when a transient error is detected.

An execution strategy is a configurable EF Core component that
intercepts database operations and decides whether to retry
them on failure. The SQL Server provider ships with a strategy
that knows which error codes Azure SQL considers transient.

[1]: https://learn.microsoft.com/en-us/ef/core/miscellaneous/connection-resiliency

Closes: #89

Todas as mensagens precisam ter esse nível de profundidade? Claro que não. Por exemplo, Fix typo é uma ótima mensagem de commit, se tudo que você está fazendo naquele commit é corrigir um typo. O mesmo vale para Remove commented-out code, Remove blank lines, e assim por diante. O tamanho da sua mensagem de commit precisa ser diretamente proporcional ao tamanho e escopo da sua mudança.

A IA Muda Tudo. Ou…Será Que Não?

Eu sei o que você ficou se perguntando durante todo esse tempo. “Mas…mas…mas…e o ChatGPT?”

Minha opinião sincera é que a IA muda pouco, ou nada, do que discutimos até aqui.

Pra começar, com IA ou sem IA, os fundamentos continuam os mesmos:

Boas mensagens de commit ainda devem focar mais no porquê do que no quê e no como.
A regra do 50/72 ainda é uma boa diretriz a seguir.
Usar o modo imperativo nos resumos continua sendo o padrão para muitas ferramentas, incluindo o próprio Git e o GitHub.
Boas mensagens de commit ainda têm imenso valor para leitores futuros, que podem incluir a própria IA.

Mas a IA é ótima pra escrever mensagens de commit. Por que eu deveria me preocupar?

Quando se trata de mensagens de commit, a IA é de fato ótima em uma coisa. E essa coisa é resumir um conjunto de mudanças e escrever, de forma muito bem escrita, gramaticalmente correta, com tom profissional… uma listagem detalhada de todas as mudanças.

Que é exatamente o que você não deveria estar fazendo! Onde a IA falha é exatamente na parte mais importante, que a esta altura você já deve estar cansado de ler: o porquê.

Não estou dizendo que você não deve usar IA pra te ajudar a criar mensagens de commit. Claro que pode. Eu uso bastante. Este é um exemplo de prompt que uso frequentemente com o Claude, com algumas variações:

Write a concise, well-crafted commit message for the diff I'm going to give you.
Make it more high-level, focusing on the why rather than listing all changes in great detail.
Follow these rules:
- Summary
	- Brief description of what was done
	- 50 chars at the most
	- Use imperative mood
	- Do not use conventional commits
- Body
	- Brief description of the "how", but focus more on the reason for the changes
	- Use prose rather than bullet points.
	- Use past tense
	- Lines no longer than 72 chars

Depois eu rodo git diff | clip e colo o resultado junto com esse prompt.

O que eu recebo de volta é sempre uma mensagem muito bem escrita, muito mais detalhada sobre descrever as mudanças do que eu gostaria, e que perde completamente o ponto do porquê estamos fazendo as mudanças. O que não surpreende nada, porque como diabos ela saberia se eu não contei?

O que faço então é explicar os motivos da mudança. E pedir pra tentar de novo, mais alto nível e incluindo a explicação. Às vezes a segunda versão já está boa o suficiente, mas geralmente preciso de pelo menos três até ficar satisfeito.

Entendeu o padrão? Isso é uma colaboração entre a IA e eu. Estamos trabalhando juntos pra criar uma mensagem. Não estou terceirizando 100% pra IA.

Quando uso o Claude Code, essas regras do prompt acima ficam no arquivo Claude.md do projeto. Nesse cenário, ele tende a ir muito melhor em entender o “porquê”, porque tudo começou com um prompt em que eu expliquei o motivo por trás da mudança, e então fizemos uma sessão de planejamento antes de começar a implementar.

Mas mesmo assim, a IA frequentemente ainda precisa de muita orientação até conseguir escrever uma mensagem de commit que realmente foque nos motivos por trás da mudança e que dê informações no nível certo de abstração. Por conta própria, a IA produz mensagens bem escritas que são essencialmente um diff em prosa.

Conclusão

A essa altura, você provavelmente percebeu que este é um post bem opinionado. Algumas das coisas cobertas aqui estão muito perto de ser um padrão, como a regra do 50/72 e a ideia de escrever resumos no modo imperativo.

Porém, algumas coisas que discuti são preferências pessoais. Por exemplo, eu normalmente não uso Conventional Commits. Os motivos pra isso estão além do escopo deste post, mas existem. São motivos bastante pessoais, então não vou te julgar se você gosta de usar Conventional Commits.

A principal lição que quero que você leve deste post é: coloque trabalho nas suas mensagens de commit. Não escreva qualquer coisa; elabore suas mensagens. Trabalhe nelas, aperfeiçoe-as, até não conseguir mais melhorar.

Sim, é difícil. Pode ser frustrante. Pode parecer uma perda de tempo ficar 10, 15 ou até 20 minutos elaborando uma mensagem que o seu LLM favorito teria gerado em segundos.

Mas eu garanto: anos depois, quando você estiver investigando um incidente crítico em produção e se deparar com ótimas mensagens de commit que oferecem insights valiosos sobre o porquê de algumas mudanças terem sido feitas… você vai ficar feliz por ter feito isso.

Obrigado por ler.

Phil Karlton foi engenheiro principal na Netscape nos anos 90. A formulação exata da frase varia dependendo da fonte — Martin Fowler tem uma boa nota sobre sua origem. ↩
Tim Pope é um desenvolvedor open source prolífico, muito conhecido na comunidade Vim por plugins como vim-fugitive (integração com Git) e vim-surround. Seu post de 2008 sobre mensagens de commit continua sendo uma das referências mais citadas sobre o assunto. ↩
O ciclo do TDD é: escrever um teste que falha (vermelho), escrever o mínimo de código para fazê-lo passar (verde), depois limpar o código sem quebrar nada (refatorar). Commitar a cada fase verde gera um histórico granular, sempre funcional, que você pode percorrer com confiança usando o git bisect. ↩

Implementando o git em Go do Zero: Unindo o Útil ao...Agradável?

Mon, 09 Mar 2026 00:00:00 +0000

Recentemente comecei a trabalhar no meu projeto mais novo: construir o git em Go, do zero. Qual é o sentido disso?, você pode estar se perguntando.

Tipo, é um projeto bastante inútil no sentido de que, você sabe, o git existe há 20 anos. (Obrigado, Linus.) Meu objetivo com esse projeto é duplo:

aprender a linguagem Go
aprofundar meu conhecimento sobre os internos do git

Escopo do Projeto

Não pretendo implementar 100% do git. Isso seria muito difícil. O que vou fazer é implementar um subconjunto pequeno de comandos do git, apenas em suas variações mais básicas. Esta é a lista atual do que pretendo implementar:

git init
git add
git status
git commit
git log

Essa lista não é estática. Posso decidir implementar mais comandos, ou menos. Tudo depende de eu decidir que aprendi o suficiente. Vamos ver como isso vai.

Fluxo de Trabalho do Projeto (eu realmente não sabia como chamar essa seção)

Como vou fazer tudo isso, na prática? Já estou fazendo, já que comecei há cerca de uma semana. Então, a forma como estou conduzindo isso é basicamente percorrer essa lista de comandos, implementando um por um, e documentando meus aprendizados neste blog.

Ainda não tenho certeza sobre a cadência das postagens. Sinto que atualizações semanais são demais; já que tenho apenas cerca de 30 a 50 minutos por dia para trabalhar nisso, não quero perder muito tempo escrevendo as atualizações em si.

Então acho que vou começar escrevendo os posts sempre que sentir que acumulei atualizações interessantes o suficiente para compartilhar, e aí compartilho. Pode ser que depois eu estabeleça em uma cadência regular, mas também pode ser que não.

Sobre o Uso de LLMs

Impus algumas regras a mim mesmo para este projeto. A mais importante é que zero linhas de código serão escritas por IA/LLMs. Isso derrotaria o propósito, já que o objetivo é realmente aprender a linguagem.

Isso não significa que não estou usando IA. Estou usando o Claude para me ajudar a planejar o roteiro, por assim dizer. Ele tem me ajudado a decidir a ordem dos comandos que faz mais sentido, quais são os conceitos de Go necessários para construir isso e quais posso pular, e assim por diante.

Para o meu aprendizado de Go em si, estou usando a documentação do Go e a boa e velha busca na web. Como nos velhos tempos.

Construindo o git em Go: A Primeira Atualização

Então, o que fiz até agora? Comecei este projeto na segunda-feira, 2026-03-02. Uma semana atrás no momento em que escrevo. Durante os primeiros três dias, segui o Go Tour para relembrar as poucas coisas que eu sabia sobre a linguagem e aprender mais dos fundamentos.

Na quinta-feira, terminei o tour. Passei pelos conteúdos sobre generics bem rapidamente e pulei completamente os de concorrência. Nesse dia, criei o repositório e escrevi um “Hello World.”

Por algum motivo, não mexi no projeto na sexta-feira. Sábado foi o dia em que implementei de fato meu primeiro comando, e o único implementado até agora: ggt init.

Ah sim, a propósito: meu executável se chamará ggt, porque o próprio projeto se chama go-gitter. Isso é um trocadilho idiota com a expressão em inglês “go-getter”, que se refere a uma pessoa que está sempre em ação, realizando muitas coisas e tal.

Implementar o init foi muito fácil e tenho certeza de que só vai ficar mais difícil a partir de agora. Criar um repositório git é surpreendentemente simples, e é algo que você pode fazer manualmente, sem usar o git em si. Duvida? Ok, vou te ensinar.

Vá a algum lugar no seu computador e crie uma pasta. Entre nessa pasta e crie uma nova chamada .git. Exatamente assim.

Agora, entre em .git e crie um arquivo de texto chamado HEAD. Exatamente assim, sem extensão. Dentro desse arquivo, coloque o seguinte texto e salve:

ref: refs/heads/main

Próximo passo: crie duas novas pastas, objects e refs. Dentro de objects, crie mais duas pastas vazias: info e pack. Dentro de refs, crie heads e tags.

Agora, usando o terminal, vá ao mesmo nível onde a pasta .git está e execute git status. Você verá um resultado assim:

On branch main

No commits yet

nothing to commit (create/copy files and use "git add" to track)

Parabéns! Você acabou de criar um repositório git manualmente. Isso é exatamente o que meu código Go está fazendo.

Acompanhe as Atualizações

As atualizações deste progresso serão rastreadas pela tag go-gitter, então você pode salvar essa página nos favoritos, se quiser. Já vinculei ao repositório, mas aqui está novamente, caso você tenha perdido: go-gitter.

Obrigado pela leitura. Até a próxima atualização.

O Que São Breaking Changes?

Fri, 26 Sep 2025 00:00:00 +0000

Foto por Denis Oliveira no Unsplash

Estou começando uma série de artigos onde vou definir alguns conceitos ou termos que são comuns no desenvolvimento de software, e estou começando com Breaking Changes. Afinal, por que começar com A como uma pessoa normal?

Beleza, mas… por que escrever uma série assim?

Principalmente porque quero criar os recursos que gostaria de ter tido quando estava começando.

Naquela época, me deixava louco quando as pessoas falavam de coisas como se eu já soubesse o que elas significavam.

Olha, eu sou um desenvolvedor ~~velho~~ experiente, o que significa que na minha época eu não tinha um amiguinho de IA pra simplesmente perguntar essas coisas. Sim, o Google já existia, também não sou tão ~~velho~~ experiente assim né, porra.

O problema é que muitas vezes as explicações que você encontrava no Google não eram lá essas coisas. Frequentemente o Stack Overflow ajudava, mas nem sempre. Hoje em dia, claro, você pode perguntar pro seu LLM favorito pra explicar as coisas pra você, se você não se importar com o tom genérico, desprovido de qualquer voz humana autêntica ou anedotas.

Então, estou escrevendo esses artigos pra ajudar os iniciantes por aí a entender um pouco melhor alguns conceitos chave do desenvolvimento de software, um de cada vez, de forma simples e interessante, espero. Tudo cortesia do seu amigo aqui. Vamos começar?

O que é um breaking change?

“Breaking change” significa qualquer mudança que você faz no seu software que pode fazer o código dos seus usuários quebrar, depois que eles fizerem o upgrade. Breaking changes só fazem sentido quando você pensa em software que você cria e de alguma forma distribui para usuários terceiros.

Pense em coisas como:

APIs
bibliotecas/pacotes
frameworks
ferramentas CLI

Vamos ver um exemplo. Enquanto desenvolvia uma aplicação pra sua empresa, você extraiu algumas funcionalidades comuns como uma biblioteca e decidiu publicar isso como um pacote open-source hospedado no https://www.nuget.org.

Depois de um tempo, você publica uma nova versão onde muda o nome de um dos métodos mais importantes e usados dentro do pacote. Os usuários fazem upgrade pra sua versão mais nova e agora o código deles não compila mais, porque ainda se refere ao método usando o nome original. Isso é um breaking change!

ℹ️ NOTA

Importante: pra algo ser um breaking change, não é necessário que 100% dos usuários quebrem quando fazem upgrade. No nosso exemplo, é possível que nem todos os usuários estivessem realmente usando aquele método específico no código deles, o que significa que o código deles não teria quebrado. Mas a mudança ainda é um breaking change, porque o potencial de quebrar está lá.

Exemplos de Breaking Changes

Na prática, que tipos de mudanças são breaking changes?

Eu diria que a mais comum, ou pelo menos o que a maioria das pessoas pensaria como breaking change, seria excluir ou renomear coisas.

Se você renomeia um endpoint de API, uma classe pública ou método do seu pacote, ou um comando do seu CLI, código que usa essas coisas não vai mais funcionar. E, pra todos os efeitos práticos, renomear é a mesma coisa que excluir, porque aquela versão antiga não existe mais.

Cadê o método que estava aqui?

Existem outros tipos de breaking changes, então vamos revisar alguns deles.

Novos Parâmetros Obrigatórios

Se você adiciona novos parâmetros a um método, e eles são obrigatórios, então todo código existente que chama o método vai falhar na compilação. A solução aqui seria adicionar novos parâmetros como opcionais, ou até criar um novo método.

Parâmetros opcionais removidos ou tornados obrigatórios

Essa é uma continuação lógica da anterior. Se você remove um parâmetro opcional, código que chama aquele método passando o parâmetro vai quebrar. Por outro lado, se você torna um parâmetro opcional obrigatório, acontece o oposto: agora todos os lugares que não passam o parâmetro vão quebrar.

Novos Membros Adicionados a Uma Interface

Aqui estou falando especificamente de linguagens estaticamente tipadas que têm o conceito de interface onde você define comportamentos que classes cliente precisam implementar.

Adicionar um novo membro a uma interface é um breaking change porque agora todas as classes que a implementam não teriam implementado o novo membro.

Recentemente, o time do C# resolveu esse problema de uma forma que gerou alguma controvérsia: adicionando a possibilidade de implementar métodos nas próprias interfaces!

Mudou o Tipo de um Parâmetro de Método

Se você muda o tipo de um parâmetro de, digamos, string para int, você está garantindo que muito código cliente vai quebrar.

Mudou o tipo de retorno de um método ou função

Novamente, dependendo dos tipos antigo e novo, isso pode nem quebrar, mas ainda é um breaking change em geral.

Mudou a ordem dos parâmetros

Esse é interessante porque pode quebrar de uma forma diferente dos outros. Para a maioria dos exemplos que eu tenho dado até agora, “quebrar” significa que o código que consome seu código vai falhar na compilação.

Com este, você pode fazer de uma forma que o código ainda compile, mas falhe em funcionar corretamente.

Por exemplo, veja esse código:

public async Task<IReadOnlyList<Product>> GetProductsByCategory(int categoryId, int companyId)
{
// implementação
}

Se você invertesse a ordem entre categoryId e companyId, o código ainda compilaria mas não funcionaria corretamente. Ainda seria um breaking change, mas um que falha de forma mais sutil.

Claro que se os dois parâmetros são de tipos diferentes, então falharia no sentido de falhar na compilação. E é por isso que muita gente argumenta que você não deveria usar primitivos pra coisas como ids, mas criar seus próprios tiny types pra isso.

Comportamento de tratamento de erro modificado (lançando exceções diferentes)

Se o seu método costumava lançar um certo tipo de exceção e agora lança uma diferente, isso é um breaking change, porque código que foi escrito pra capturar aquela primeira exceção específica não vai funcionar pra nova, a menos que ela herde da primeira.

Tornou métodos ou propriedades públicas privadas

Na prática, do pontos de vista do cliente, isso é o mesmo que excluir algo, então é um breaking change óbvio.

Adicionou requisitos de autenticação onde não existiam

Até agora, todos os exemplos foram pra bibliotecas ou pacotes. Agora vamos ver alguns exemplos pra APIs web. O primeiro tem a ver com autenticação: se um endpoint não requeria autenticação mas agora requer, isso é um breaking change, porque código existente que costumava chamar isso agora vai receber um erro 401 Unauthorized.

Adicionou novas propriedades obrigatórias a um payload

Isso é similar a adicionar novas propriedades obrigatórias a um método público, certo? Se seu endpoint agora espera um payload diferente do que esperava antes, código existente vai quebrar, provavelmente recebendo um erro 400 Bad Request.

Renomear ou deletar um endpoint

Esse é auto-explicativo.

O que fazer sobre breaking changes?

Isso deveria ser óbvio agora, mas vamos deixar claro: breaking changes são Uma Coisa Ruim™. Tente ao máximo evitá-las.

Se você distribui qualquer código ou software publicamente e existem pessoas que dependem dele, você não vai querer ficar quebrando os workflows delas frequentemente, ou elas vão ficar bravas com você, e com razão.

Às vezes não tem jeito. Você simplesmente precisa fazer um breaking change, seja removendo um método ou classe que se tornou obsoleta, ou mudando a assinatura de uma função.

Quando você tem que fazer algo assim, algumas coisas são aconselhadas.

Depreciação Gradual

Adicionar um breaking change é algo que você não deveria levar de forma leviana porque pode dramaticamente interromper o workflow dos seus usuários. Além disso, não faça isso de repente, do nada, e de uma vez.

Antes de remover classes/métodos/etc obsoletos, primeiro anuncie publicamente que você está fazendo isso, várias versões antes. Então, você marca aquele artefato como deprecated de alguma forma, mas ainda não remove. Por exemplo, em C# você pode usar o atributo Obsolete.

Então, depois de algumas versões, você finalmente faz seu breaking change.

Adicione Instruções às Suas Release Notes

Se você está publicando software publicamente pra uso de terceiros, você provavelmente tem algum tipo de release notes onde comunica quais foram as mudanças nesta nova versão. Aproveite isso.

Quando for hora de realmente publicar uma versão com breaking change, use suas release notes pra descrever, em detalhes, qual é a mudança e como vai afetar seus usuários.

Geralmente, quando um breaking change consiste em aposentar um método/classe/endpoint, vem acompanhado de uma nova forma de fazer a mesma coisa. Afinal, você não estaria aposentando a forma antiga só porque sim.

Nesses casos, também use suas release notes pra explicar em detalhes como os usuários podem adaptar seu código pra migrar da forma antiga pra nova de fazer a tarefa.

Use Semantic Versioning

Finalmente, use Semantic Versioning e use o número da versão pra comunicar que isso é um breaking change, lançando uma versão major.

Semantic Versioning (ou SemVer pra abreviar) é um padrão de versionamento onde você usa um número de versão neste formato: major.minor.patch.

Quando sua nova versão só contém correções de bugs, e elas não adicionam breaking changes, você incrementa o componente patch.

Por exemplo:

2.0.0 -> 2.0.1

Se a versão contém nova funcionalidade que não quebra compatibilidade, então você incrementa o componente minor e zera o componente patch:

2.0.1 -> 2.1.0

Agora vem a parte mais importante. Quando sua versão contém breaking changes, seja por nova funcionalidade, correções de bugs, ou ambos, você incrementa o número major e zera os outros dois:

2.1.0 -> 3.0.0

Dessa forma, você comunica claramente aos seus usuários a presença ou ausência de breaking changes na sua release mais recente.

Conclusão

Neste post, expliquei o conceito de breaking change, por que geralmente é ruim, e o que fazer sobre isso. Resumo rápido:

Breaking changes são mudanças que quebram o código dos seus usuários, no contexto de software que é distribuído para usuários terceiros.
Evite adicionar breaking changes ao seu software, porque prejudicam a experiência dos seus clientes.
Às vezes você não pode evitar adicionar um breaking change. Nesses casos, use depreciação gradual, comunique claramente o que mudou e como se adaptar, e use semantic versioning.

Acho que é isso. Obrigado por ler, espero que tenha sido útil e nos vemos novamente no próximo episódio desta série, onde provavelmente vou voltar pra letra A, porque sou esquisito assim mesmo.

Como Melhorar a Experiência do Desenvolvedor: 7 Coisas Para Mudar

Tue, 08 Jul 2025 00:00:00 +0000

ℹ️ NOTA

Escrevi este post originalmente para a Nimbus. Você pode ler o original no site deles, em inglês.

O Que é Experiência do Desenvolvedor? Por Que Você Deveria Se Importar?

No desenvolvimento de software, falamos muito sobre experiência do usuário, e com razão. Como é o usuário final que se beneficia diretamente do software que a gente escreve, faz sentido que ele esteja sempre no centro de todos os nossos esforços. Mas recentemente, outro termo começou a ganhar força no contexto de melhorar a qualidade do software: experiência do desenvolvedor, ou developer experience no original em inglês.

É sobre isso que este post trata — experiência do desenvolvedor. Vamos começar explicando o que é experiência do desenvolvedor e por que todas as organizações de software deveriam se importar com isso. A partir daí, vamos partir para a parte prática, apresentando uma lista de sugestões que você pode adotar imediatamente para melhorar a experiência do desenvolvedor na sua equipe ou empresa.

Aqui está minha definição de experiência do desenvolvedor: quão confortável e “desenrolado” é o processo de desenvolvimento de software para uma determinada equipe ou organização.

Por que a experiência do desenvolvedor é tão importante? Por que as pessoas começaram a falar tanto sobre isso recentemente?

Não é difícil de entender. Software é tremendamente valioso, então as pessoas que criam software também são tremendamente valiosas. É do interesse de qualquer empresa que cria software manter seus desenvolvedores felizes e produtivos, especialmente num mercado aquecido onde desenvolvedores recebem oportunidades o tempo todo.

Se você melhorar a experiência do desenvolvedor na sua empresa, é mais provável que você atraia ótimos desenvolvedores e mantenha os que já tem. A produtividade provavelmente vai aumentar, assim como a qualidade do trabalho.

Experiência do Desenvolvedor: Melhore com Essas 7 Dicas

Chega de enrolação, vamos ver sete sugestões práticas que você pode adotar hoje para melhorar a experiência do desenvolvedor na sua empresa ou equipe.

1. Minimize as Interrupções

De forma geral, desenvolvedores de software odeiam interrupções. Não é porque somos uns bichos do mato que não podem ser incomodados com reuniões ou atividades que podem ser descritas como “sociais” (ok, eu admito, alguns são).

O problema com interrupções é que o desenvolvimento de software é uma atividade que requer longos períodos de foco intenso. Como qualquer profissional cuja área exige esse nível de concentração vai dizer, alcançar esse estado demora tempo e esforço. No entanto, perdê-lo é fácil: basta o João da contabilidade ou seu gerente aparecer na sua mesa ou te mandar uma mensagem no Slack para fazer esse foco desaparecer no ar.

Para melhorar a experiência do desenvolvedor, minimize as interrupções. Em termos mais práticos, faça o seguinte:

Use comunicação assíncrona o máximo possível. Tente usar newsletter interno, artigos na wiki e atualizações por e-mail em vez de reuniões e chamadas.
Adote um dia livre de reuniões. Escolha um dia da semana, ou pelo menos meio dia, em que a agenda de todos fica bloqueada e não pode ser reservada. Isso vai dar a todos a chance de ter tempo dedicado para concentração profunda.
Otimize o horário e duração das reuniões. Reuniões são inevitáveis às vezes. Quando esse for o caso, escolha um horário e duração que facilite para as pessoas se concentrarem. Por exemplo, se o horário de trabalho da sua empresa termina às 18h, não agende uma reunião que termina às 17h30. Esses últimos trinta minutos provavelmente serão perdidos, já que não são suficientes para os desenvolvedores alcançarem o foco profundo que precisam.

2. Invista em Excelência Técnica

A maioria dos desenvolvedores quer saber que seu trabalho importa. Eles querem saber que estão trabalhando numa equipe que cria software com os mais altos padrões, usando as melhores práticas disponíveis e encantando usuários com ótimas funcionalidades entregues rapidamente.

Portanto, investir em excelência técnica é uma ótima forma de melhorar a experiência dos desenvolvedores. A lista do que você pode fazer inclui o seguinte:

Adotar testes automatizados e, opcionalmente, TDD (desenvolvimento guiado por testes)
Usar integração contínua (CI) e entrega e deployment contínuos (CD).
Ter um processo de revisão de código ou, em vez, programação em par.
Usar analisadores estáticos e linters para detectar problemas comuns no código.
Coletar e acompanhar métricas de qualidade.

Essas são apenas algumas sugestões sobre o que você pode fazer para fomentar uma cultura de excelência técnica na qual os desenvolvedores sentem orgulho do seu trabalho e sentem que seu trabalho tem propósito.

3. Dê Autonomia aos Desenvolvedores

Autonomia é um grande motivador de produtividade e felicidade no trabalho. Para se sentirem realizadas, as pessoas precisam ter pelo menos algum grau de autonomia sobre a forma como fazem seus trabalhos.

De forma geral, desenvolvedores deveriam receber um alto grau de autonomia sobre como fazem seu trabalho. Permita que as equipes decidam o seguinte:

Qual workflow de branching melhor atende suas necessidades
Se eles estimam usando pontos, tamanhos de camiseta, Fibonacci, horas ou algo completamente diferente
Quão rigorosamente eles querem aderir às cerimônias do seu sabor preferido de agile (por exemplo, se devem ou não ter um daily scrum)

No nível individual, permita que desenvolvedores escolham se querem trabalhar remotamente, no escritório ou de forma híbrida. Dê ao colaborador flexibilidade para montar um pacote de benefícios que faça sentido para ele (algumas pessoas têm filhos, outras não, então benefícios que atendem apenas pessoas casadas com filhos certamente vão alienar uma parte considerável da sua força de trabalho).

4. Remova o Atrito ao Criar Ambientes de Desenvolvimento

Uma coisa que quase todo desenvolvedor odeia é um processo manual, tedioso e propenso a erros ao criar um novo ambiente de desenvolvimento. Esses processos fazem com que desenvolvedores demorem muito tempo até conseguirem contribuir com código para a equipe. Pior ainda, os processos frequentemente não são facilmente reproduzíveis, o que significa que diferenças entre ambientes podem ser introduzidas.

Como consequência, o ambiente de desenvolvimento se afasta do staging e produção, tornando bugs mais prováveis e criando a famosa desculpa “funciona na minha máquina”.

Para melhorar a experiência do desenvolvedor, invista em formas de facilitar a criação de ambientes consistentes e reproduzíveis. Soluções de container como Docker são uma ótima forma de alcançar isso. Alternativamente, você pode aproveitar soluções que oferecem a criação de ambientes de desenvolvimento na nuvem.

5. Invista na Educação dos Desenvolvedores

Debs também têm uma ótima experiência quando sentem que dominam as ferramentas do seu trabalho. A sensação de estar no controle é muito boa. Isso não só leva a um resultado de maior qualidade, mas também é mais prazeroso.

Então, uma forma certeira de melhorar a experiência do desenvolvedor é investir na educação deles. Há várias formas de fazer isso:

Oferecer aos desenvolvedores uma verba mensal ou anual que eles podem usar livremente para investir em cursos, livros ou certificações.
Dar aos desenvolvedores tempo (tempo remunerado da empresa, sim!) durante o qual eles podem estudar e praticar
Oferecer recursos de aprendizado pagos pela empresa, como uma biblioteca da empresa ou serviços como Udemy ou Pluralsight

6. Não Seja Pão-Duro com Ferramentas

Se você quer que seus desenvolvedores façam um ótimo trabalho, você deve dar a eles as ferramentas para fazê-lo. Se seus desenvolvedores não conseguem entregar um ótimo trabalho devido a um computador lento ou falta de licença de software, a culpa é sua.

Seus programadores deveriam ter ótimo hardware, como laptop fornecido pela empresa, monitor, teclado e por aí vai (e até complementos de escritório como uma ótima cadeira).

Você também deveria fornecer o software necessário. Isso inclui licenças de IDE, assinaturas de serviços, plugins e o que mais for preciso. Não importa o que seus desenvolvedores precisam para realizar seu trabalho, a empresa deveria, dentro do razoável, fornecer.

7. Ouça o Feedback dos Desenvolvedores (e Aja Baseado Nele)

Por último, mas não menos importante, aqui está o item final da nossa lista: ouça seus desenvolvedores!

Entende o seguinte: desenvolvedores de software geralmente são pessoas inteligentes que se importam com o que fazem. As chances são de que eles tenham ideias muito boas sobre como melhorar não apenas sua própria experiência, mas a de suas equipes e organizações como um todo.

Ouça seus desenvolvedores. Quando fizer sentido, coloque suas sugestões em prática. Além do benefício criado pela sugestão em si, isso terá o benefício adicional de melhorar o moral da equipe. Seus desenvolvedores vão se sentir valorizados e como parte essencial da equipe. O que, é claro, eles são.

Melhore a Experiência do Desenvolvedor, Melhore Sua Empresa

Se sua organização é uma organização de tecnologia, então desenvolvedores de software são indiscutivelmente seus ativos mais preciosos. Então, melhorar a experiência do desenvolvedor, além de ser uma coisa decente e humana a se fazer, também é um ótimo investimento. É do seu interesse manter seus desenvolvedores felizes e produtivos, e como você viu neste post, isso é algo que você pode alcançar relativamente facilmente.

As sugestões neste post são simplesmente sugestões. Seus resultados podem variar (por exemplo, se você trabalha numa indústria altamente regulamentada, dar aos desenvolvedores um alto grau de autonomia pode não se aplicar). Como sempre, use seu julgamento. Considere a lista neste post como um ponto de partida. Ajuste conforme necessário, corte e adicione a ela. O que importa é que você melhore a experiência do desenvolvedor na sua empresa pelo bem dos seus desenvolvedores, seus usuários finais e a empresa como um todo.

Obrigado pela leitura!

Git Switch Branch: Tudo o Que Você Precisa Saber

Tue, 15 Apr 2025 00:00:00 +0000

ℹ️ NOTA

Escrevi este post originalmente para a Cloudbees. Você pode ler o original, em inglês, no site deles.

Repositórios no Git funcionam de uma maneira fundamentalmente diferente da maioria das outras ferramentas. Um dos exemplos mais marcantes dessas diferenças é o branching. Na maioria das outras ferramentas de controle de versão, criar um branch é uma cerimônia elaborada. Eles fazem um grande alarde sobre isso, e os desenvolvedores acabam desistindo, preferindo fluxos de trabalho que não dependem de muitos branches.

No Git, o oposto é frequentemente verdadeiro: criar branches é tão barato que a maioria das pessoas faz isso muito. As pessoas frequentemente ficam confusas ao tentar gerenciar seus branches. Este post tenta esclarecer parte dessa confusão, oferecendo um guia sobre como fazer o git switch branch de maneira fácil e segura. Antes de chegarmos lá, no entanto, começamos com alguns fundamentos, explicando o que realmente são branches no Git, como funcionam e como você as cria.

Antes de concluir, compartilhamos uma dica bônus, abordando como fazer checkout de branches remotas. Vamos começar!

Como Funcionam os Branches no Git?

Como funcionam os branches no Git? A primeira coisa que você precisa saber é que um repositório no Git é composto por objetos e referências. Os principais tipos de objetos em um repositório Git são commits. Referências apontam para outras referências ou para objetos. Os principais tipos de referências são—você adivinhou—branches.

Objetos no Git são imutáveis. Você não pode alterar um commit de forma alguma ou mover sua posição no histórico. Existem comandos que parecem mudar as coisas, mas na verdade eles criam novos commits. Referências, por outro lado, mudam bastante. Por exemplo, quando você cria um novo commit, a referência do branch atual é atualizada para apontar para ele.

Quando você cria um novo branch, tudo o que acontece é que uma nova referência é criada apontando para um commit. É por isso que criar branches no Git é tão barato e rápido. Falando nisso…

Como Crio um Novo Branch?

Nós já temos um post completo explicando como você pode criar um branch no Git, cobrindo as quatro principais maneiras de fazer isso.

Aqui, vamos apenas cobrir a maneira mais fácil de criar um branch no Git, que é simplesmente usar o comando branch a partir do branch atual. Vejamos um exemplo:

mkdir git-switch-demo
cd git-switch-demo
git init
touch file1.txt
git add .
git commit -m "Create first file"
touch file2.txt
git add .
git commit -m "Create second file"
touch file3.txt
git add .
git commit -m "Create third file"

No exemplo acima, criamos um novo repositório e adicionamos três commits a ele, criando um novo arquivo por commit. Aqui está uma representação visual do estado atual do nosso repositório:

Para criar um novo branch a partir do ponto atual, só precisamos executar:

git branch example

Criamos um branch, mas ainda não mudamos para ele. É assim que nosso repositório se parece agora:

E se adicionássemos um novo commit enquanto ainda estamos no branch master? Isso afetaria o branch example? A resposta é não. Execute os seguintes comandos:

echo "Another file" > file4.txt
git add .
git commit -m "Create fourth file"

Na próxima seção, mostraremos como você pode fazer git switch branch e, em seguida, poderá ver por si mesmo como esse novo branch não contém o quarto commit. Por enquanto, dê uma olhada na representação visual do estado atual do nosso repositório:

Como Você Muda de Branch?

Durante a maior parte da história do Git, o comando checkout era usado para isso. Embora você ainda possa usá-lo, a versão 2.23 do Git adicionou o comando switch (bem como o comando restore) em uma tentativa de ter comandos mais específicos para algumas das muitas tarefas para as quais o comando checkout é usado.

Como Uso o Git Checkout?

A maneira mais antiga e mais conhecida de mudar de branch no Git é usando o comando checkout. Seguindo nosso exemplo, se quiséssemos mudar para o branch “example”, só teríamos que executar:

git checkout example

Após executar o comando, você deverá ver uma mensagem dizendo que mudou com sucesso para o branch example:

Agora você está no novo branch, isso significa que pode adicionar quantos commits quiser, sabendo que o branch master não será afetado. O comando checkout, seguido por um nome de branch, atualiza a árvore de trabalho e o índice, e atualiza a referência HEAD, apontando-a para o branch que você acabou de fazer checkout. E se você tivesse alterações não commitadas no momento da mudança? Essas seriam mantidas para permitir que você as commitasse no novo branch.

O Git permite que você use o comando checkout de diferentes maneiras. Por exemplo, um cenário incrivelmente comum é criar um branch e imediatamente mudar para ele. Na verdade, eu diria que criar um branch e não mudar para ele na hora é a exceção, e não a regra. Então, o Git nos oferece um atalho. Em vez de criar um branch e depois fazer checkout dele, você pode fazer isso em uma única etapa usando o comando checkout com o parâmetro -b.

Então, fazer isso:

git checkout -b new

é equivalente a isso:

git branch new
git checkout new

Checkout não funciona apenas com branches, no entanto. Você também pode fazer checkout de commits diretamente. Por que você gostaria de fazer isso?

Bem, dar uma olhada em como o projeto estava há algum tempo atrás é frequentemente útil, particularmente para fins de teste. Mas há mais. Fazer checkout de um commit coloca seu repositório em um estado chamado “detached HEAD” que permite criar alterações experimentais, adicionando commits que você pode então escolher manter ou descartar.

O Que é Git Switch?

Durante a maior parte da vida do Git, o comando checkout era o único que você usaria para mudar de branch. O problema é que esse comando também faz outras coisas, o que pode levar à confusão, especialmente entre novos usuários.

A versão 2.23.0 do Git resolve isso adicionando dois novos comandos: switch e restore. O comando restore não é relevante para nós hoje. O comando switch, por outro lado, é uma nova maneira de mudar para branches.

A página do manual para o comando lista todas as suas muitas opções. Em sua forma mais básica, você o usa da mesma maneira que o git checkout, apenas trocando o nome do comando:

git switch example

Se você quiser voltar ao branch anterior, pode usar um atalho em vez do nome completo:

git switch -

E se você quiser criar um novo branch e imediatamente mudar para ele? Com checkout, poderíamos usar este atalho:

git checkout -b <nome-do-branch>

O novo comando também oferece um atalho, mas neste caso, usamos a letra “c”:

git switch -c <nome-do-branch>

Vale a pena usar o novo comando? Bem, eu provavelmente continuarei usando o git checkout, desde que eles não o mudem, principalmente por causa da memória muscular. Mas ao ensinar Git para iniciantes? Então eu definitivamente usarei o comando switch. Ele tem um nome que está mais relacionado à tarefa que executa e, portanto, é mais memorável.

Como Faço para Mudar para um Branch Remoto?

Antes de concluir, compartilhamos uma dica final: como mudar para branches remotas?

Para este exemplo, vamos usar um projeto de código aberto chamado Noda Time, que é uma API alternativa de data e hora para .NET. Comece clonando o repositório:

git clone https://github.com/nodatime/nodatime.git

Se tudo funcionou bem, você deve ter uma pasta “nodatime” agora. Entre na pasta e execute o seguinte comando:

git branch -a

O comando branch lista os branches em seu repositório. A opção “-a” significa que você quer ver todos os branches, não apenas os locais. O resultado deve ser parecido com isto:

Como você pode ver, temos apenas um branch local, que é o branch master. Você pode ver, em vermelho, todos os branches remotos. Então, digamos que você queira fazer checkout do branch chamado “slow-test”. Como você faria isso?

Bem, tecnicamente falando, o Git não permite que você trabalhe nos branches de outras pessoas. E é isso que são os branches remotos. O que você realmente faz é criar uma “cópia” local do branch de outra pessoa para trabalhar. Então, vamos ver como fazer isso.

Quando você cria um branch, pode passar um commit ou nome de branch como parâmetro. Então, para criar um branch local a partir do branch remoto “slow-test”, eu só teria que fazer:

git branch slow-test origin/slow-test

No exemplo, estou usando “slow-test” como o nome para o meu branch local, mas eu poderia realmente ter usado qualquer outro nome válido.

Alternativamente, eu poderia ter usado o comando checkout com a opção -b ou o comando switch com a opção -c. Então, as duas linhas a seguir são equivalentes à linha acima:

git checkout -b slow-test origin/slow-test
git switch -c slow-test origin/slow-test

Finalmente, há uma maneira ainda mais fácil. Eu poderia ter simplesmente usado:

git checkout slow-test

e o resultado teria sido o mesmo. Isso funciona porque quando você tenta fazer checkout de um branch e o Git não encontra um branch com esse nome, ele tenta corresponder a um branch remoto de um de seus remotes. Se ele conseguir corresponder com sucesso, as coisas simplesmente funcionam.

Branches do Git: Use com Moderação

Neste post, mostramos como mudar de branch no Git. Mas fomos além disso: explicamos o que são branches e como funcionam. Esperamos que, a esta altura, você esteja mais confortável criando e usando branches no Git.

Antes de irmos, uma ressalva final: só porque você pode fazer algo, não significa que deva. Às vezes, as pessoas ficam tão entusiasmadas com a facilidade de criar branches no Git que acabam usando fluxos de trabalho que dependem de vários branches de longa duração, o que torna seu processo de desenvolvimento muito complexo e propenso a erros, além de atrasar a integração.

Obrigado por ler e até a próxima!

C# Type Safe: Como a IA Generativa Torna os Tiny-Types Viáveis

Tue, 10 Dec 2024 00:00:00 +0000

É estranho como nossa memória funciona, não é? Não consigo lembrar exatamente o que jantei há duas noites, ou o motivo pelo qual deixei de ir à academia em alguns dias da semana passada. Mas me lembro vividamente de um bug específico que corrigi no meu primeiro emprego como programador depois de me formar na faculdade.

Havia este método que não estava funcionando corretamente, e sua assinatura era algo assim:

void ProcessOrder(int orderId, int customerId)

Eu revisei o código e não consegui encontrar nada de errado. Mas quando comecei a debugar, percebi que o local da chamada estava passando os argumentos na ordem errada — ou seja, customerId primeiro e depois orderId.

Erros como este são fáceis de cometer e difíceis de detectar mesmo em revisões de código. Até mesmo os testes podem deixar passar, já que você pode ter o azar de fornecer valores que acidentalmente fazem o código funcionar sem explodir tudo.

Como acontece, existe uma ótima maneira de prevenir problemas como o que acabei de descrever. O problema? A maioria dos desenvolvedores acharia que é trabalho demais para se preocupar.

Tiny Types: A Melhor Técnica de Design de Software Que Ninguém Usa

Eu sei, eu sei. Vou ser o primeiro a admitir que este título é exagerado. “Uma Técnica Interessante de Design de Software Que Muitas Pessoas Não Usam” simplesmente não tem o mesmo impacto, foi mal.

Então, o que é essa coisa de “tiny types”? É uma solução radical para o code smell de obsessão primitiva. Essencialmente, em vez de usar tipos primitivos para conceitos de domínio — por exemplo, usar um int para representar um identificador único — você envolve todos eles usando um objeto de valor extremamente simples.

Usando tiny types, poderíamos reescrever a assinatura do método anterior assim:

void ProcessOrder(OrderId orderId, CustomerId customerId)

Implementando um Tiny Type

Como seria o tipo OrderId?

Para começar, já que OrderId deve envolver um int, ele deve receber um int como parâmetro e armazená-lo em algum lugar. Vejamos:

public class OrderId
{
    private readonly int _value;
    public OrderId(int value)
    {
        if (value <= 0)
        {
            throw new ArgumentOutOfRangeException(
                nameof(value),
                 "Value must be a positive integer!");
        }
        _value = value;
    }
}

Acho que o exemplo acima é um bom começo, você não concorda? Recebemos um int como parâmetro, validamos e lançamos uma exceção em caso de valores zero ou negativos, e então o atribuímos a um campo privado readonly, o que é apropriado, já que OrderId, como um objeto de valor, deve ser imutável.

Você sabe do que mais os objetos de valor — e, por consequência, os tiny types — precisam? Igualdade estrutural. Ou seja, ao compará-los, devemos considerar apenas seus valores, não se suas referências apontam para o mesmo objeto.

Então, vamos começar sobrescrevendo Equals:

public override bool Equals(object? obj)
{
    var other = obj as OrderId;
    if (other == null)
    {
        return false;
    }
    return other._value == _value;
}

(Para um estilo C# mais moderno, poderíamos ter usado pattern matching, mas acho que a abordagem acima é mais clara.)

Agora recebo um aviso do compilador porque meu tipo sobrescreve Equals mas não GetHashCode, então vamos corrigir isso:

public override int GetHashCode()
{
    return _value.GetHashCode();
}

Como OrderId é um tipo simples representando valores únicos e imutáveis, ele deveria realmente ser uma struct em vez de uma classe, de acordo com as Diretrizes de Design de Tipos da Microsoft:

Structs são o caso geral de tipos de valor e devem ser reservadas para tipos pequenos e simples, semelhantes aos primitivos da linguagem.

Mas as diretrizes de design também dizem que todas as structs devem implementar a interface IEquatable<T>, então vamos fazer isso. Aliás, já que estamos aqui, vamos também implementar IComparable<T> e dar overload nos operadores de comparação:

public struct OrderId : IEquatable<OrderId>, IComparable<OrderId>
{
    private readonly int _value;
    public OrderId(int value)
    {
        if (value <= 0)
        {
            throw new ArgumentOutOfRangeException(
                nameof(value),
                 "Value must be a positive integer!");
        }
        _value = value;
    }

    public override bool Equals(object? obj)
    {
        if (obj is OrderId other)
        {
            return _value == other._value;
        }
        return false;
    }

    public bool Equals(OrderId other) => _value == other._value;

    public override int GetHashCode()
    {
        return _value.GetHashCode();
    }

    public int CompareTo(OrderId other) => _value.CompareTo(other._value);

    public static bool operator ==(OrderId left, OrderId right) => left.Equals(right);
    public static bool operator !=(OrderId left, OrderId right) => !(left == right);
    public static bool operator <(OrderId left, OrderId right) => left.CompareTo(right) < 0;
    public static bool operator >(OrderId left, OrderId right) => left.CompareTo(right) > 0;
    public static bool operator <=(OrderId left, OrderId right) => left.CompareTo(right) <= 0;
    public static bool operator >=(OrderId left, OrderId right) => left.CompareTo(right) >= 0;
    
    public override string ToString() => _value.ToString();
}

Existem mais coisas que poderíamos adicionar, como conversões implícitas/explícitas, mas nosso tipo já é funcional como está. Para aqueles que usam C# moderno, poderíamos alcançar o mesmo com uma sintaxe mais concisa:

public readonly record struct OrderId : IComparable<OrderId>
{
    private readonly int _value;

    public OrderId(int value)
    {
        if (value <= 0)
        {
            throw new ArgumentOutOfRangeException(
                nameof(value),
                "O valor deve ser um inteiro positivo!");
        }
        _value = value;
    }

    public int CompareTo(OrderId other) => _value.CompareTo(other._value);

    public static bool operator <(OrderId left, OrderId right) => left.CompareTo(right) < 0;
    public static bool operator >(OrderId left, OrderId right) => left.CompareTo(right) > 0;
    public static bool operator <=(OrderId left, OrderId right) => left.CompareTo(right) <= 0;
    public static bool operator >=(OrderId left, OrderId right) => left.CompareTo(right) >= 0;
    
    public override string ToString() => _value.ToString();
}

Tiny Types São Muito Caros

Meu pequeno tipo OrderId ali ocupa 42 linhas no meu Visual Studio. Sim, existem algumas escolhas estilísticas envolvidas — por exemplo, eu não gosto quando as linhas têm mais de 80 caracteres de comprimento — mas mesmo assim, é bastante trabalho.

A versão mais concisa, que aproveita o recurso record do C# moderno, é mais curta, mas ainda requer uma quantidade razoável de código.

Agora imagine fazer isso para todos os ids em sua aplicação! E não apenas ids, claro. Imagine fazer isso para mais tipos que exigem validação/análise mais complexa:

CEPs
Placas de carro
Números de telefone.

E assim por diante.

Essa é a principal razão pela qual desenvolvedores que conhecem esta técnica não a usam. Mesmo quando gostam da ideia e entendem como ela poderia ser benéfica, eles acham que fazer tudo isso não vale o trabalho.

LLMs ao Resgate

Já se passaram dois anos desde que a OpenAI apresentou o ChatGPT ao mundo, e tenho experimentado com LLMs desde então. Minha opinião atual sobre eles é que sua proposta de valor para desenvolvedores experientes é dupla:

Eles atuam como um substituto do Google ao aprender algo novo
Eles atuam como um gerador de código para coisas mundanas que eu preferiria não fazer.

Há alguns meses, tornei-me um assinante pago do Claude. Tenho usado principalmente como auxílio em um projeto hobby no qual estou trabalhando, e devo dizer que estou muito satisfeito com os resultados que obtenho, já que o Claude é muito melhor que o ChatGPT para tarefas de programação.

Fui ao Claude com o seguinte prompt:

Gere um tipo chamado OrderId. Deve ser um wrapper sobre um int. Não permita valores zero ou negativos. Implemente igualdade, hash code, sobrecarga de operadores de comparação e igualdade.

Não adicione conversões explícitas ou implícitas.

E este é o resultado que obtive:

public readonly struct OrderId : IEquatable<OrderId>, IComparable<OrderId>
{
    private readonly int value;

    public OrderId(int value)
    {
        if (value <= 0)
        {
            throw new ArgumentException("Order ID must be greater than zero", nameof(value));
        }
        this.value = value;
    }

    public override bool Equals(object? obj)
    {
        return obj is OrderId other && Equals(other);
    }

    public bool Equals(OrderId other)
    {
        return value == other.value;
    }

    public override int GetHashCode()
    {
        return value.GetHashCode();
    }

    public int CompareTo(OrderId other)
    {
        return value.CompareTo(other.value);
    }

    public static bool operator ==(OrderId left, OrderId right)
    {
        return left.Equals(right);
    }

    public static bool operator !=(OrderId left, OrderId right)
    {
        return !(left == right);
    }

    public static bool operator <(OrderId left, OrderId right)
    {
        return left.CompareTo(right) < 0;
    }

    public static bool operator <=(OrderId left, OrderId right)
    {
        return left.CompareTo(right) <= 0;
    }

    public static bool operator >(OrderId left, OrderId right)
    {
        return left.CompareTo(right) > 0;
    }

    public static bool operator >=(OrderId left, OrderId right)
    {
        return left.CompareTo(right) >= 0;
    }

    public override string ToString()
    {
        return value.ToString();
    }
}

É um bom começo, mas ainda não estou completamente satisfeito:

Pode torná-lo um record para que a implementação seja mais concisa? Além disso, use métodos com corpo de expressão para as linhas únicas.

E agora o Claude me deu isso:

public readonly record struct OrderId : IComparable<OrderId>
{
    private readonly int value;

    public OrderId(int value)
    {
        if (value <= 0)
             throw new ArgumentException("Order ID must be greater than zero", nameof(value));
        this.value = value;
    }

    public int CompareTo(OrderId other) => value.CompareTo(other.value);

    public static bool operator <(OrderId left, OrderId right) => left.CompareTo(right) < 0;
    public static bool operator <=(OrderId left, OrderId right) => left.CompareTo(right) <= 0;
    public static bool operator >(OrderId left, OrderId right) => left.CompareTo(right) > 0;
    public static bool operator >=(OrderId left, OrderId right) => left.CompareTo(right) >= 0;

    public override string ToString() => value.ToString();
}

Finalmente, fui ao Claude e perguntei isto:

Imagine que existe uma classe Order que precisa ser salva no banco de dados. Usamos Entity Framework. Como garantir que tudo funcione já que este modelo usa o tipo OrderId?

E esta é minha resposta, completa com o modelo e a configuração necessária do EF para lidar com nosso tipo personalizado:

.HasConversion<OrderIdValueConverter>()
                .ValueGeneratedOnAdd(); // Usar auto-incremento do banco de dados
            
            builder.Property(o => o.CustomerName)
                .IsRequired()
                .HasMaxLength(200);

            builder.Property(o => o.TotalAmount)
                .HasPrecision(18, 2);
        });
    }
}

Conclusão

Este post tinha dois objetivos. Primeiro, apresentar o conceito de tiny types para aqueles de vocês que nunca ouviram falar dele. Espero que concordem que, apesar de ser uma ideia simples, o padrão tiny types é algo que pode ajudar você a escrever código mais robusto.

Segundo, e de forma mais ampla, demonstrar como os LLMs podem desempenhar um papel interessante no fomento de um melhor design de software. No passado, muitas técnicas de design de software podem ter sido descartadas por serem consideradas trabalho demais para valer a pena. Agora, com a ajuda do Claude, ChatGPT ou assistentes de código como o Copilot, podemos agilizar a escrita de código “chato”, o que faz com que a economia das técnicas de design, como a que apresentei neste post, faça mais sentido.

Erros de Aprendizado Para Se Evitar Como Desenvolvedor de Software

Tue, 22 Oct 2024 00:00:00 +0000

Foto de Francisco De Legarreta C. na Unsplash

ℹ️ Info

Agradeço ao amigo André Gonçalves da Silva por ler e revisar esboços deste post, e sugerir melhorias.

Se você trabalha com desenvolvimento de software, com certeza já ouviu frases do tipo “Nunca pare de estudar”, “Tem que se atualizar sempre”, “A nossa área muda muito rápido”, e assim por diante.

Claro, todas essas frases estão certas, em algum nível. Mas sair por aí repetindo como um papagaio “nunca pare de estudar” não é a coisa mais útil do mundo no sentido de fornecer um direcionamento para o seu aprendizado.

O que acaba acontecendo na prática é que muita gente, por não ter aprendido a aprender da forma correta, comete muitos erros de aprendizado que comprometem seu desenvolvimento profissional. Esses erros podem levar a um progresso lento, frustração e até mesmo estagnação na carreira - algo que ninguém está a fim de passar.

Por isso, nesse post, resolvi trazer um compilado do que acredito serem os erros mais comuns de aprendizado que devs em geral cometem. Essa lista é fruto de anos de experiência pessoal, observação de colegas desenvolvedores e muitas conversas com gente da área. Eu sei na prática do que estou falando porque muitos desses erros são coisas que eu já cometi.

(Sendo sincero, alguns eu ainda cometo e tô sempre precisando me policiar para parar, mas não conta pra ninguém. ;))

Identificar e entender esses erros é o primeiro passo para superá-los. Ao evitá-los, você pode otimizar seu processo de aprendizado, acelerar seu crescimento profissional e se manter relevante em um campo que está sempre evoluindo.

Então, sem mais delongas, aqui vai a lista dos erros de aprendizado para você evitar. Para cada erro, você vai ver:

a explicação do erro
o problema que ele causa
como remediá-lo

Bora lá?

Índice

Achar Que Apenas Consumo de Conteúdo == Aprendizado
Não Aplicar o Conteúdo dos Recursos de Aprendizado
Falta de Foco
Falta de Consistência
Subestimar a Importância das Bases
Viver Embaixo de Uma Pedra (Não se antenar com o que está acontecendo)
Conclusão

Achar Que Apenas Consumo de Conteúdo == Aprendizado

Comecei a lista com esse que acredito ser o erro de aprendizado mais comum atualmente, pelo simples fato de que a gente vive em uma época onde se produz conteúdo pra caramba.

Por que caímos nessa armadilha?

Consumir conteúdo é fácil, conveniente e(potencialmente) divertido. Vamos entender o porquê:

Fácil: É algo passivo, você não tem que pensar muito ou tomar decisões, e o ser humano tende a procurar o caminho do menor esforço.
Conveniente: Você pode geralmente consumir o conteúdo enquanto faz outras coisas:
- Ouvir um podcast enquanto se exercita ou lava a louça
- Assistir um vídeo enquanto almoça
- Ler posts no Reddit enquanto espera na fila do banco
Divertido: Muitos criadores percebem que, pra engajar o público, precisam adicionar um toque de entretenimento e transformar o conteúdo numa performance que segure a atenção.

Pronto, a armadilha está montada. Aí você vai lá, bola uma estratégia para preencher cada momento livre do dia com o consumo de podcasts, vídeos no Youtube, blog posts, Reddit, e sei lá o que mais.

As consequências desse erro

No fim, você vai ter:

Consumido seu tempo com informações superficiais
Retido quase nada do que consumiu
Um vago sentimento de que “aprendeu” alguma coisa

Mas e na hora de aplicar isso de maneira significativa no seu dia-a-dia? É aí que a conta não fecha.

A longo prazo, as consequências podem ser ainda mais sérias:

Estagnação profissional, pois você não está realmente desenvolvendo novas habilidades
Frustração ao perceber que não está progredindo como esperava
Possível burnout ao tentar constantemente “ficar por dentro” de tudo

Pra deixar bem claro: o erro aqui não é “consumir conteúdo.” E sim achar que apenas o consumo desenfreado de conteúdo é o suficiente para você evoluir como profissional.

Como remediar esse erro

A solução é simples em teoria, o que não necessariamente significa que é fácil. Aqui vai:

Diminua a parcela do seu tempo de aprendizado que você gasta com consumo passivo de conteúdos, e aumenta a parcela gasta com aprendizado prático, principalmente projetos pessoais.

As sugestões aqui são:

Crie ou contribua com um projeto open-source
Faça um site ou aplicativo para uma ONG, entidade assistencial, ou sua igreja
Solucione algum problema que você ou algum familiar tem criando uma automação simples
Reinvente a roda: Implemente uma tecnologia ou ferramenta conhecida (exemplos: git, Docker, um servidor HTTP) simplesmente com o objetivo de aprender.

A lista acima não é exaustiva, mas serve apenas pra começar a te inspirar. Cinco minutos de Google ou de conversa com o Chat GTP vai render muitas ideias de projetos legais para fazer.

Não Aplicar o Conteúdo dos Recursos de Aprendizado

Se você comprar um livro e não o ler, você joga dinheiro fora. Se você comprar o livro, ler, e o aprendizado daquilo não impactar a maneira como você faz seu trabalho, então você desperdiça o seu dinheiro e o seu tempo!

O mesmo se aplica a cursos, tutoriais, e outros recursos de aprendizado. Ser desenvolvedor de software é uma profissão prática; como você espera se beneficiar do que aprendeu, se não o colocar em prática?

Antes que alguém reclame: sim, é claro que existem livros, vídeos, etc., cujo conteúdo não tem uma aplicação prática direta. Talvez você tenha lido O Mítico Homem-Mês pra pegar alguns insights e aprender sobre a história do desenvolvimento de software, mas isso não muda necessariamente como você escreve código. E tá tudo bem, esses casos existem – use seu bom senso.

Como o erro #2 difere do anterior?

A gente pode resumir o primeiro erro como “gastar 100% do seu tempo de aprendizado com o consumo de conteúdo.” Ou seja, você não faz mais nada além de consumir coisas.

Este erro aqui é na linha de “não aplicar o que você aprende com o conteúdo assistido.”

Ou seja, é possível cometer o segundo erro sem cometer o primeiro. Por exemplo, você pode dedicar 60% do seu tempo de aprendizado à criação de projetos pessoais e 40% ao consumo de conteúdo. Mas se ainda sim você não aplicar de nenhuma forma o conteúdo que você aprendeu nesses 40% do tempo, você vai ter cometido o erro #2. Ficou claro?

Motivo Desse Erro

Por que tanta gente (este que vos fala incluso) comete esse erro? Provavelmente o que rola aqui é uma certa pressão psicológica que muitos sentimos, no sentido de atingir números. Quantas pessoas você conhece que criam umas metas assim?

Ler x livros técnicos por ano
Fazer y cursos até o segundo semestre
etc…

Se você se sente realmente a fim de atingir esse tipo de meta, não tem jeito: precisa “gastar” o menor tempo possível com cada conteúdo. Do contrário, a conta não fecha.

Problemas Causados Por Este Erro

Uma consequência grave que você pode sofrer com este erro é a falta de motivação. Você leu todos os livros famosos da área que te indicaram, concluiu todos os cursos no seu PDI, e parece que nada mudou. Assim fica difícil ter a motivação pra insistir no aprendizado, quando a sensação é de que nada disso gera impacto real na maneira como você trabalha.

É essa a tal da frustração com a falta de evolução na carreira, que a gente citou no erro anterior. Outra consequência séria desse erro é o próprio desperdício de tempo, dinheiro e energia: o aprendizado é um investimento que precisa ter um retorno para ser justificado.

Qual a solução?

O remédio para este erro tem dois passos:

Priorizar qualidade ao invés de quantidade
Aplique constantemente o que aprendeu

Então, aqui fica a minha sugestão prática:: só inicie outro curso/livro/etc após ter aplicado o aprendizado do anterior.

Por exemplo, digamos que você está fazendo um curso na Udemy. Após cada aula ou seção, pare e crie um pequeno projeto no qual você exercita o que você acabou de aprender. Não precisa ser um projeto grande, nem mesmo útil. De preferência, jogue fora depois de terminar: o importante é a prática.

Aqui estão mais alguns exemplos:

Após assistir um tutorial de programação, dedique tempo para replicar o projeto por conta própria, sem olhar o vídeo
Leu um artigo sobre uma nova técnica de refatoração? Aplique-a em um projeto pessoal ou no trabalho
Ouviu um podcast sobre boas práticas de código? Revise um projeto antigo e veja onde você pode aplicar essas práticas

Com relação à leitura de livros técnicos, recentemente eu criei uma regra pra mim: quando eu termino um livro, eu só posso começar outro depois que eu tiver aplicado o conteúdo do livro que acabei de ler. Essa aplicação pode ter diferentes formas:

fazer os exercícios do livro, caso tenha
criar um ou mais projetos para exercitar aquele conteúdo
propor/implementar uma nova prática no meu trabalho baseado no que aprendi

No fim das contas, é isso que importa: que você dê um jeito de aplicar o conteúdo aprendido pra melhorar a sua vida profissional. Uma pilha de livros cujo conteúdo não te impactou só serve pra juntar poeira ou de suporte para monitor.

Falta de Foco

Existem muito mais coisas “aprendíveis” do que você tem tempo ou energia para aprender. Você nunca vai saber tudo, e nunca vai zerar a sua fila de coisas para aprender. Isso é um fato e você precisa aceitar e abraçar esse fato, a não ser que você esteja muito a fim de um burnout.

Infelizmente, a gente sente a pressão de “estar sempre estudando”, mesmo que essa frase em si não tenha nenhuma utilidade—não oferece nenhuma ajuda sobre o quê estudar, ou que estratégias usar.

É comum que essa pressão venha das nossas próprias empresas:

Leia o livro x!
Faça esse curso!
Conclua essa trilha!

E essas pessoas são bem intencionadas, mas isso não muda o fato de que você tem uma quantidade limitada de tempo no seu dia e, mais importante, uma quantidade limitada de energia no tempo que você tem disponível

Mas aí você cede à pressão e acaba cometendo o erro desse item: ficar pulando de curso em curso, livro em livro, tutorial em tutorial, sem nunca concluir nada, ou pelo menos atingir algum progresso significativo.

Um Disclaimer

Olha só: eu sei que no dia-a-dia do trabalho, é muito comum a gente se deparar com um número enorme de problemas diferentes que precisam ser resolvidos, e o prazo é sempre pra ontem. Nestas situações, muitas vezes a coisa correta é sim aprender somente o superficial de um assunto para conseguir dar conta da demanda e gerar valor para o usuário o mais rápido possível.

A habilidade de distinguir quando é a hora de investir em um certo item de maneira mais aprofundada e quando um conhecimento superficial basta é algo que é extremamente valioso para a carreira de qualquer profissional, e a única maneira de aperfeiçoar essa habilidade é com a prática.

O erro que eu aponto neste item é uma situação diferente do cenário acima. Mais especificamente, o erro é sobre tentar aprender muitas coisas ao mesmo tempo, de maneira aprofundada, com recursos densos.

Problemas Causados Por Este Erro

O principal problema causado pela falta de foco é que você nunca se aprofunda em nada. Você fica com uma vaga impressão de conhecimento em um milhão de coisas, mas quando rola uma situação crítica no qual o conhecimento aprofundado faria falta, você não tem o que mostrar.

Como eu já disse antes, é impossível se aprofundar em tudo. Mas você deveria, sim, se aprofundar nas coisas que mais importam, aquelas que geram maior valor para sua carreira. Me refiro aos tais dos fundamentos que muita gente fala, mas vou falar mais a respeito disso em outro tópico.

Como Remediar

Este erro talvez seja o mais difícil de remediar, porque a solução envolve uma dose alta de autoconhecimento e um senso muito forte de priorização.

No geral, a dica é: defina UM ponto de evolução para sua carreira, e foque nele por um tempo considerável, até avaliar que fez progresso.

Alguns exemplos de pontos de melhoria:

Melhorar meus conhecimentos de paralelismo, concorrência, e performance
Aprender os principais design patterns e saber aplicá-los em projetos reais
Adquirir habilidades avançadas em SQL
Aprender uma nova linguagem e chegar em um nível produtivo

Não é fácil identificar este ponto de melhoria, mas aqui vão algumas dicas:

Peça feedback dos gestores e colegas.
Converse com algum mentor técnico em quem você confia.
Se você está ativamente participando de processos seletivos para vagas e tem falhado, analise os pontos nos quais foi mal nas entrevistas para identificar onde melhorar.
Se não está ativamente procurando, finja que está. Peça para algum amigo ou mentor fazer uma mock interview com você, e depois peça feedback honesto.

Falta de Consistência

O que é melhor, dedicar 30 minutos por dia pra aprender, todos os dias, ou 5 horas no final de semana, uma vez a cada três meses? A resposta é óbvia.

A nossa profissão é prática, é necessária prática deliberada e consistente para que você internalize as coisas que aprende a saiba usar quando chegar a hora.

Consequências

As consequências aqui são bem óbvias, né? Simplesmente não tem como fazer progresso se você não se esforça com consistência. Isso na verdade se aplica em praticamente qualquer coisa na vida: atividade física, aprendizado de idiomas, tocar um instrumento, e por aí vai.

Se você investe, por exemplo, 1 hora por semana para aprender algo, isso dá um total de cerca de 51 horas no ano. Agora, se você aprender 15 minutos todos os dias, isso dá um total de 5475 minutos no ano, o que dá mais de 91 horas!

Estudar só uma vez por semana tem outra desvantagem. Se surgir algum imprevisto e você precisar faltar, quando voltar já terão se passado duas semanas. Assim, fica complicado manter o ritmo; você precisa lembrar de onde parou 14 dias atrás, e retomar o contexto perdido não é nada fácil.

Como Remediar

Solucionar esse erro requer pensar em estratégias para que o aprendizado se torne uma parte natural da sua rotina diária.

Para começar, defina o tempo **que você vai dedicar diariamente, de forma realista. Não adianta se comprometer com 2 horas de aprendizado diário se a sua rotina simplesmente não permite isso.

Outra coisa essencial é escolher o horário do seu tempo de aprendizado. Pra fixar bem o hábito, o ideal seria que fosse no mesmo horário todos os dias. Ao escolher esse horário, leve em consideração como seus níveis de energia mudam durante o dia. Você é uma pessoa matinal? Coloque seu tempo de aprendizado na parte da manhã. Do contrário, à noite.

Vou dar o exemplo do que funciona pra mim. Eu sei que se for deixar meu tempo de aprendizado para depois do trabalho, vou estar muito cansado e provavelmente não vou fazer. Então, para mim, o melhor é reservar cerca de 50 minutos antes do trabalho para o aprendizado.

Pra fazer do aprendizado um hábito, a chave é integrar na rotina e diminuir o atrito. Sabe aquela galera que dorme de roupa de academia? Mesma ideia pro estudo. Deixe o PC ligado com o VS Code aberto no seu projeto, ou configure o navegador pra abrir direto no curso da Udemy. Quanto mais fácil começar, melhor.

Também é interessante que a hora de decidir o que aprender e a hora de aprender sejam momentos distintos. Se você tem 50 minutos por dia para o aprendizado, mas gasta 20 desses minutos todos os dias decidindo o que vai ler/praticar/assistir, você está desperdiçando 40% do seu tempo.

Então vai a dica: no sábado, você vai definir a sua rotina de aprendizado para a semana seguinte. Você criar uma planilha definindo os dias e o que você vai fazer, ou criar um board no Trello, ou mesmo usar papel e caneta, não importa. O importante é você já ter isso definido de antemão. Aí, nos dias da semana, você simplesmente confere e segue o planejamento feito.

Finalmente, algo que funciona para muitas pessoas é fazer algum tipo de compromisso público. Você declara, publicamente—por exemplo, no seu Linkedin—que vai estudar sem faltar durante x dias. O simples fato de ter feito esse compromisso frequentemente ajuda as pessoas a manterem a rotina sem faltar.

Uma iniciativa legal nesse sentido é o 100 Dias de Código, que incentiva pessoas a codarem durante 100 dias seguidos, sem falta, interagindo com outros participantes no processo.

Subestimar a Importância das Bases

Muita gente subestima a importância de se aprender os fundamentos da computação. Sim, estou falando daquelas coisas chatas que você não gostava de estudar na faculdade: algoritmos e estruturas de dados, teoria da computação, complexidade de algoritmos, e por aí vai.

Esse pessoal argumenta que você não precisa saber dessas coisas todas pra fazer o seu código funcionar. Sim, isso pode ser verdade boa parte do tempo, mas não sempre.

A gente pode pensar na computação como várias camadas que abstraem a camada anterior. Quando você está trabalhando em uma camada, você geralmente não precisa se preocupar com as outras. Isso é uma coisa boa, e é literalmente o motivo pelo qual a gente usa abstrações: “esconder” coisas que não são essenciais, diminuindo a complexidade do que você precisa lidar.

Consequências

Infelizmente, as abstrações não são perfeitas. Como já nos advertiu Joel Spolsky mais de 20 anos atrás, as abstrações em algum momento vazam.

Em outras palavras: só porque você usa um ORM não significa que você não tem que saber SQL. Mesmo quem usa uma linguagem gerenciada como C# ou Java pode se beneficiar de ter um entendimento sobre gerenciamento de memória: no mínimo, você vai ser capaz de escrever código que usa lifetimes de maneira correta, não cria alocações desnecessárias e coloca pressão no garbage collector.

Falta de entendimento de complexidade de algoritmos pode derrubar um sistema. Você testa localmente seu código com algumas poucas centenas de valores, mas quando aquilo vai ao ar e tem que lidar com milhões de itens, ele simplesmente não dá conta.

Em resumo: você consegue fazer algo que “funciona” sem conhecimento de fundamentos. Porém, funciona em parte dos cenários, parte do tempo, com desempenho inaceitável, e sem levar em conta edge cases.

Além dos problemas que a falta de uma base sólida pode causar nos sistemas em que você trabalha, este erro pode trazer outra consequência bem séria para sua carreira.

Sim, estou falando de você não ser capaz de passar nos processos seletivos das empresas. É muito comum que empresas, principalmente as de fora do país, utilizem desafios técnicos que requerem um bom conhecimento em tópicos como algoritmos, estrutura de dados, complexidade, concorrência e paralelismo, o modelo de memória da sua linguagem preferida, entre outros.

Não ter esse conhecimento significa ser reprovado sumariamente nos processos.

Solução

Se você não tem faculdade, recomendo fortemente que estude Ciência da Computação. Caso já tenha terminado a faculdade mas esqueceu todos aqueles tópicos, procure relembrar/reforçar esses conceitos.

Na internet você pode achar de sobra conteúdo sobre Ciência da Computação. Por exemplo, o projeto Teach Yourself Computer Science tem um roadmap de tópicos para aprender, com bibliografia e vídeos de aulas de universidades renomadas.

O NeetCode é um site que traz um roadmap de estudo de algoritmos e estruturas de dados. Também oferece cursos e a funcionalidade de praticar questões reais usadas em entrevistas de emprego.

Viver Embaixo de Uma Pedra (Não se antenar com o que está acontecendo)

Achei que seria interessante que o último erro fosse exatamente o oposto do primeiro. Enquanto o erro que abre a lista era “apenas consumir conteúdo e achar que está aprendendo”, esse aqui é “nunca consumir conteúdo nenhum.”

Por Que Isso é Um Problema?

Nós trabalhamos em uma área que muda constantemente, e cada vez mais rápido. Não se manter atualizado pode levar a:

Obsolescência das suas habilidades
Perda de oportunidades de carreira
Dificuldade em resolver problemas usando abordagens mais eficientes
Falta de inspiração para inovação no seu trabalho diário

Em outras palavras: falta de atualização prejudica seu desempenho no seu trabalho atual, e ao mesmo tempo diminui suas chances de conseguir um potencial novo emprego. Não é isso que você quer, né?

Encontrando o equilíbrio

Por um lado, utilizar cada segundo livre para consumir cada podcast/artigo/vídeo que seja possível não é uma boa estratégia. É como comer muita porcaria que não é nutritiva: você vai se sentir cheio, mas aquela comida não vai trazer os benefícios que seu corpo precisa.

Mas por outro lado, não consumir conteúdo nenhum é igualmente ruim. Como desenvolvedor, é importantíssimo que você tenha pelo menos uma noção do que está acontecendo no mundo do desenvolvimento de software.

O que manter no radar

Aqui vai uma pequena lista de coisas que seria interessante manter no seu radar:

Lançamento de livros técnicos sobre temas que você se interessa, ou de autores que você já acompanha
Novas funcionalidades da versão mais recente da sua linguagem ou framework principais
Ferramentas ou técnicas que podem facilitar a sua vida
Tendências emergentes na indústria (por exemplo, IA.)

Onde encontrar conteúdo relevante

Existem muitas fontes de informação valiosas para desenvolvedores. Aqui estão algumas sugestões:

Reddit:
- r/programming para um apanhado geral
- Subreddits específicas como r/csharp, r/java, r/golang, etc.
Hacker News: Excelente para notícias e discussões sobre tecnologia em geral
YouTube:
- Pesquise por canais relacionados aos seus interesses específicos
- Assista a palestras de conferências de tecnologia
Blogs técnicos:
- De empresas de tecnologia (por exemplo, blog de engenharia do Netflix, Spotify, etc.)
- De desenvolvedores influentes na sua área
Podcasts de tecnologia: Ótimos para consumir informação enquanto faz outras atividades

Conclusão

Chegamos ao fim da lista. Espero que o compilado de erros de aprendizado que você acabou de ler seja útil para sua carreira. Com essa lista eu cobri o que não fazer, mas o que você deve fazer então?

Talvez no futuro eu escreva um post apenas sobre isso: como aprender da maneira correta, e no que focar. Deixa aí nos comentários caso você se interesse em algo assim.

Mas, por enquanto, para saber o que fazer, basta imaginar uma estratégia de aprendizado que seja o contrário dos erros acima:

Aprenda com consistência, de preferência um pouco todos os dias;
Tenha foco: privilegia um ponto principal de melhoria por vez;
Prefira um aprendizado baseado em projetos, suplementado em partes por consumo de conteúdo
Ao consumir conteúdo, sempre aplique o que aprendeu de alguma forma prática
Aprender sobre ferramentas é importante, mas ter fundamentos sólidos é mais importante

Agora vem a dica mais importante que eu posso deixar.

Feito é melhor que perfeito.

Pulou um dia de aprendizado? Não tem importância, continue no próximo. Dedicou 30 minutos ao seu projeto ao invés dos 50 que tinha planejado? Ainda é infinitamente melhor do que não ter feito nada.

Tendências são mais importantes do que data points. Estar indo na direção certa é mais significativo do que metas arbitrárias do tipo “vou ler 6 livros técnicos em 2024”.

É difícil lidar com a pressão de desenvolvimento constante que a gente sente nessa área, eu sei bem disso. Na medida do possível, tente relaxar. Não se martirize demais. Você está indo na direção certa.

Só o fato de ter lido até o final um post de quase 4 mil palavras demonstra que você é muito mais interessado(a) em seu desenvolvimento que a maioria. Por isso, eu lhe agradeço muito. Se precisar de ajuda, não hesite em entrar em contato.

carlos schults / blog

Elaborando Ótimas Mensagens de Commit na Era da IA

Por Que LLMs Não São Automaticamente Boas em Criar Boas Mensagens de Commit

A IA Não Lê Sua Mente

O Que Fazer Então?

Conventional Commits Não É um Bom Padrão

Chegam os Scoped Commits

Chega a Skill do Claude

Meu Veredito?

O Que Você Deveria Fazer?

Operador LIKE do PostgreSQL: Um Guia Detalhado

LIKE do PostgreSQL: Fundamentos

O Que É o LIKE do PostgreSQL?

Qual a Diferença Entre LIKE e ILIKE no PostgreSQL?

LIKE do PostgreSQL: Casos de Uso Práticos

Preparando o Banco de Dados

Correspondendo a um Único Caractere

Correspondências Negativas

Correspondência Sem Diferenciar Maiúsculas de Minúsculas

Escapando os Wildcards

Conclusão: LIKE do PostgreSQL — Aprenda e Aproveite

Construindo o git em Go do zero - Parte 2

Já faz um tempo

Comandos Plumbing vs Porcelain

Entendendo o hash-object e o cat-file

Calculando o hash do seu primeiro objeto

Salvando um objeto

Lendo objetos de volta

Implementação no Go-Gitter

Implementando o hash-object

Implementando o cat-file

O que aprendi até agora

O que vem a seguir?

Suas Mensagens de Commit São Um Lixo. Vou Te Ajudar a Melhorar

Suas Mensagens de Commit São um Lixo Porque…

…Você Só Liga pra Código

…Às Vezes Você Não Entende o Que Está Fazendo

…Escrever é Difícil

…Ninguém Te Ensinou

…O GitHub Te Ensinou Maus Hábitos

…A Flag -m do Git Te Viciou

…Você Não Tem Higiene de Commits

Taxonomia das Mensagens de Commit Ruins

A Mensagem de Uma Linha Quase Inútil

A Mensagem de Uma Linha Inútil

Só a Referência do Sistema de Tickets

A Mensagem de Uma Linha Enganosa

Você Vai Escrever Boas Mensagens de Commit Quando…

…Escrever Suas Mensagens Em Inglês

…Parar de Escrever Mensagens de Uma Linha

…Começar pelo “O Quê”, Expandir com o “Por Quê” e o “Como”

…Seguir a Regra do 50/72

…Adotar Commits Atômicos

…Commitar Sempre, Polir Depois

Exemplos de Boas Mensagens de Commit

A IA Muda Tudo. Ou…Será Que Não?

Conclusão

Implementando o git em Go do Zero: Unindo o Útil ao...Agradável?

Escopo do Projeto

Fluxo de Trabalho do Projeto (eu realmente não sabia como chamar essa seção)

Sobre o Uso de LLMs

Construindo o git em Go: A Primeira Atualização

Acompanhe as Atualizações

O Que São Breaking Changes?

O que é um breaking change?

Exemplos de Breaking Changes

Novos Parâmetros Obrigatórios

Parâmetros opcionais removidos ou tornados obrigatórios

Novos Membros Adicionados a Uma Interface

Mudou o Tipo de um Parâmetro de Método

Mudou o tipo de retorno de um método ou função

Mudou a ordem dos parâmetros

Comportamento de tratamento de erro modificado (lançando exceções diferentes)

Tornou métodos ou propriedades públicas privadas

Adicionou requisitos de autenticação onde não existiam

Adicionou novas propriedades obrigatórias a um payload

Renomear ou deletar um endpoint

O que fazer sobre breaking changes?

Depreciação Gradual

Adicione Instruções às Suas Release Notes

O Que É o `LIKE` do PostgreSQL?

Entendendo o `hash-object` e o `cat-file`

Implementando o `hash-object`

Implementando o `cat-file`

…A Flag `-m` do Git Te Viciou