DEV Community: He4rt Developers

1ª vez trabalhando com git em um time: tudo que você precisa saber

vitoriazzp — Thu, 20 Aug 2026 06:52:21 +0000

Faz mais de 5 anos que eu não abria um PR ou issue técnica no Github, mas essa semana tenho aprendido algumas boas práticas e termos que reuni neste artigo.

Introdução

Essa semana eu fiz uma coisa simples: atualizei o README de um projeto open source, o 4noobs, da comunidade He4rt. Troquei um badge, ajustei o contraste de um logo, organizei umas pastas e adicionei um índice pra facilitar a navegação. Nada muito complexo no fim das contas.

Só que antes de chegar no "nada muito complexo", eu passei um tempo enrolada com uma pergunta boba:

"E se eu mandar isso direto pra branch principal e bagunçar tudo?"

Se tu já sentiu esse friozinho na barriga antes de mexer num repositório que não é só teu, esse artigo é pra ti. Não importa se tu é dev há anos ou se nunca abriu um terminal na vida... A lógica por trás de "como contribuir sem quebrar nada" é a mesma e bem mais simples do que parece.

Definição de Git Colaborativo

Quando eu aprendi git há uns anos, aprendi somente o versionamento e a enviar os arquivos pra dentro do Github, mas ele é bem mais que isso, né?

É através dele que times enormes interagem a respeito de um mesmo projeto de forma organizada, comentando, gerenciando tarefas, sugerindo melhorias e conhecendo o que os outros envolvidos estão fazendo. Isso é a parte do Git Colaborativo.

O Git resolve isso com um conceito central: branches (ou "ramificações"). Cada branch é tipo uma cópia paralela do projeto, onde tu pode mexer à vontade sem afetar a versão "oficial" (geralmente chamada de main ou master). Quando tu termina sua parte, tu propõe que essas mudanças sejam incorporadas de volta pelo Pull Request (PR).

Ou seja, o fluxo básico é:

Tu cria uma branch nova a partir do projeto principal
Faz as alterações lá, no seu espaço isolado
Envia (push) essa branch pro repositório remoto
Abre um Pull Request pedindo pra essas mudanças serem revisadas e, se aprovadas, unidas (merge) à branch principal

Ninguém mexe direto na versão "de produção" do projeto. Isso é o que torna possível centenas de pessoas contribuírem pro mesmo repositório sem o caos se instalar.

Principais Aprendizados

Bom, na prática, foi mexendo que aprendi (e relembrei) algumas coisas que acho que valem ser compartilhadas:

Branch nova não é sobre desconfiança, é sobre segurança. Criar uma branch pra cada contribuição não é burocracia sem sentido — é o que garante que, se algo der errado, o "errado" fica isolado ali, sem afetar o projeto principal. Isso vale tanto pra quem tá contribuindo quanto pra quem revisa.

git push não é a mesma coisa que abrir um Pull Request. Isso me pegou de surpresa: o push só envia sua branch pro GitHub. O PR é um passo separado, onde tu formaliza o pedido de revisão. O próprio terminal, inclusive, já te entrega o link pronto pra criar o PR depois do push.

Não precisa ter issue aberta pra contribuir. Eu fiquei presa nessa por um tempo. Pensei: "Ah, mas ninguém pediu essa melhoria, será que posso mandar mesmo assim?" Pode! Principalmente em documentação: se tu enxergou algo que pode melhorar, a contribuição em si já é a justificativa.

Descrição de PR boa não é uma lista de tudo o que mudou linha por linha. É um resumo categorizado, por exemplo:

o que foi feito,
por quê,
e os principais pontos agrupados por tema. Isso poupa um tempo enorme para quem vai revisar.

A pasta .github pode ser local ao repositório ou um "padrão" pra organização inteira, dependendo se existe um repositório especial chamado literalmente .github na conta. Detalhe pequeno, mas que ajuda a entender por que às vezes umas configurações "aparecem" em vários repositórios sem alguém ter copiado e colado em cada um.

Nenhum desses pontos é complicado isoladamente. O que trava a gente, geralmente, não é a técnica — é o medo.

Gerenciando o medo de fazer errado

Aqui vai a parte que eu acho mais importante desse artigo, sinceramente.

Toda vez que eu vou mexer num repositório que não é só meu, seja um projeto open source, seja no trabalho, bate aquele receio: "e se eu errar? E se eu quebrar algo? E se acharem que eu não sei o que tô fazendo?

E olha, isso não passa de uma hora pra outra. Mas duas coisas mudaram bastante minha relação com esse medo:

Entender a ferramenta tira o poder do medo.

Muito do que a gente teme é o desconhecido. Quando eu entendi que uma branch é literalmente um espaço isolado, que nada do que eu fizesse lá afetaria a main até alguém aprovar um merge, o medo diminuiu bastante. Não é sobre ser corajosa, é sobre saber que o sistema já foi desenhado pra proteger contra erro.

Errar em público faz parte do processo; não é uma falha nele.

A comunidade open source inteira é construída em cima de gente errando, corrigindo, revisando o trabalho umas das outras. Um PR rejeitado ou com pedido de ajuste não é um veredito sobre tua competência, é literalmente o sistema funcionando como devia.

Se tem uma coisa que eu queria ter escutado antes de começar a contribuir, é isso: ninguém espera que tu chegue sabendo tudo. As branches, os PRs, as revisões, tudo isso existe justamente porque errar faz parte.

Então, se tu tá enrolando para abrir aquele primeiro PR por medo de fazer besteira: cria a branch, faz a mudança e manda ver. O pior que pode acontecer é alguém te dar um feedback — e isso, no fim das contas, é como a gente aprende e melhora

Materiais Complementares

Esses são todos os materiais que me foram indicados ou lidos durante as práticas descritas acima. Alguns ensinam sobre estrutura e outros sobre boas práticas. Também tive muita ajuda de amigos e fiz pesquisas com IA pra compreender exatamente termos ou partes de código que eu não estava entendendo.

Se esse artigo te ajudou de alguma forma, deixa o coraçãozinho aí 💜 e conta nos comentários:

qual foi teu primeiro PR ou tua primeira contribuição pra um projeto que não era seu? Bora trocar ideia!

Como criei um agente de IA para selecionar testes automaticamente em PRs (Parte 1)

Alicia Marianne Gonçalves — Tue, 11 Aug 2026 16:22:22 +0000

🇺🇸 You can also read the English version of this article on AWS Community Builders.

Uma das coisas mais comuns em grandes projetos pelos quais já passei são pipelines com muitos testes, levando muito tempo para serem executados. E com isso eu pensei: por que não ter um agente de IA para analisar meus PRs e, a partir das modificações, selecionar apenas os testes que precisam ser executados? Nesse artigo vou te mostrar como eu fiz isso e já adianto que provavelmente isso vai virar uma série de artigos.

(Se você não conhece o termo, o que estou descrevendo aqui é uma versão simplificada de **Test Impact Analysis: em vez de rodar a suíte inteira a cada PR, o objetivo é mapear quais testes realmente têm relação com o que foi alterado.)

Prompts utilizados

Um dos feedbacks que recebi nos meus últimos artigos foi para deixar mais explícitos os prompts que utilizei para criar o projeto, e nesse eu usei apenas dois:

claude poderia me ajudar a fazer um projeto onde vou ter um agente de IA para analisar as linhas de códigos que foram modificadas em um PR e selecionar testes relacionados a essa modificação?

Como resposta para essa primeira pergunta, ele criou pra mim um diagrama de como basicamente isso poderia funcionar, sem nenhuma integração a pipeline ou coisa do tipo:

Depois disso, simplesmente pedi para ele criar um prompt para o Claude Code (a IA que utilizo) e, depois de colar o prompt gerado:

A primeira versão do projeto foi criado no seguinte formato:

main.py                  CLI entrypoint — wires everything together
config.py                Loads & validates ANTHROPIC_API_KEY / GITHUB_TOKEN
src/
  github_client.py       Fetches PR files & metadata from the GitHub API (with retries)
  diff_parser.py         Maps diff hunks to changed functions/classes via AST
  test_discovery.py      Indexes pytest test functions across the repo
  ai_agent.py            Calls Claude to select relevant tests
  reporter.py            Renders results as a table or JSON
tests/                   Unit tests for the parser & discovery modules

Vale destacar o diff_parser.py: em vez de simplesmente olhar quais linhas mudaram no diff, ele usa AST (Abstract Syntax Tree) para entender quais funções e classes foram alteradas. Essa diferença importa bastante — duas linhas modificadas dentro da mesma função valem como uma única mudança de símbolo, o que deixa a seleção de testes mais precisa do que uma comparação puramente textual.

Dando destaque ao nosso ai_agent.py, pois é nele que acontece a mágica, temos alguns argumentos interessantes de entender:

Relevance = Literal["low", "medium", "high"]

Ter um filtro de relevância é importante para auxiliar a IA no momento em que ela for analisar, entre os testes disponíveis, quais realmente precisam ser executados. Na prática, esse filtro também vira um dial de confiança para quem está usando a ferramenta: em um pipeline de CI mais crítico, faz sentido rodar só os testes marcados como high; em uma verificação mais exploratória, pode valer incluir low e medium também.

O prompt utilizado foi esse:

_SYSTEM_PROMPT = """\
You are a senior software engineer who selects which pytest tests are relevant \
to review for a given pull request.

You will receive a JSON object with:
- "min_relevance": the minimum relevance level to include ("low", "medium", or "high")
- "changed_symbols": a list of functions/classes/methods (or whole files) modified in the PR,
  each with file_path, symbol_name, symbol_type, and lines_changed
- "available_tests": a list of test functions discovered in the repository, each with
  test_path, test_name, imports, and source_references

Decide which of the available tests are relevant to the changed symbols by considering:
- Whether a test's source_references directly name a changed symbol
- Whether a test's imports point to the module containing a changed symbol
- One level of transitivity: a test that references something which itself references
  a changed symbol (e.g. a helper that calls the changed function)
- The semantic similarity between test names/paths and changed symbol names

Respond with ONLY a JSON array (no prose, no markdown fences, no text outside the array).
Each element must have exactly this shape:
{
  "test_path": "<string>",
  "test_name": "<string>",
  "relevance": "<low|medium|high>",
  "confidence_score": <float between 0.0 and 1.0>,
  "reason": "<short string explaining why this test is relevant>"
}

Only include tests whose relevance is greater than or equal to the given min_relevance
("low" < "medium" < "high"). If no tests are relevant, return an empty array: []
"""

Um ponto que vale destacar nesse prompt é a "um nível de transitividade": o agente não olha só se um teste referencia diretamente o símbolo alterado, mas também se ele referencia algo que, por sua vez, referencia o símbolo alterado (por exemplo, um helper chamado pela função modificada). Isso ajuda a pegar casos de teste que passariam despercebidos numa busca só por nome.

Seleção do AI Agent

A primeira mudança que fiz foi pedir para a IA adaptar o código de forma que fosse possível passar qual IA utilizar como parâmetro, em vez de deixá-la fixa:

"""Thin wrappers so AIAgent can call Claude, Gemini, or ChatGPT interchangeably."""

from typing import Protocol

from config import Config

class LLMProvider(Protocol):
    """Something that can turn a system + user prompt into a text completion."""

    def complete(self, system_prompt: str, user_prompt: str) -> str: ...

class ClaudeProvider:
    """Calls Anthropic's Claude models."""

    def __init__(self, api_key: str, model: str) -> None:
        from anthropic import Anthropic

        self._client = Anthropic(api_key=api_key)
        self._model = model

    def complete(self, system_prompt: str, user_prompt: str) -> str:
        response = self._client.messages.create(
            model=self._model,
            max_tokens=4096,
            system=system_prompt,
            messages=[{"role": "user", "content": user_prompt}],
        )
        return "".join(block.text for block in response.content if getattr(block, "type", None) == "text")

class GeminiProvider:
    """Calls Google's Gemini models."""

    def __init__(self, api_key: str, model: str) -> None:
        from google import genai

        self._client = genai.Client(api_key=api_key)
        self._model = model

    def complete(self, system_prompt: str, user_prompt: str) -> str:
        from google.genai import types

        response = self._client.models.generate_content(
            model=self._model,
            contents=user_prompt,
            config=types.GenerateContentConfig(system_instruction=system_prompt),
        )
        return response.text or ""

class ChatGPTProvider:
    """Calls OpenAI's ChatGPT models."""

    def __init__(self, api_key: str, model: str) -> None:
        from openai import OpenAI

        self._client = OpenAI(api_key=api_key)
        self._model = model

    def complete(self, system_prompt: str, user_prompt: str) -> str:
        response = self._client.chat.completions.create(
            model=self._model,
            messages=[
                {"role": "system", "content": system_prompt},
                {"role": "user", "content": user_prompt},
            ],
        )
        return response.choices[0].message.content or ""

def create_provider(config: Config) -> LLMProvider:
    """Builds the LLMProvider for config.provider, using the matching API key and model."""
    if config.provider == "claude":
        assert config.anthropic_api_key is not None
        return ClaudeProvider(api_key=config.anthropic_api_key, model=config.claude_model)
    if config.provider == "gemini":
        assert config.gemini_api_key is not None
        return GeminiProvider(api_key=config.gemini_api_key, model=config.gemini_model)
    if config.provider == "chatgpt":
        assert config.openai_api_key is not None
        return ChatGPTProvider(api_key=config.openai_api_key, model=config.chatgpt_model)
    raise ValueError(f"Unknown provider: {config.provider!r}")

O uso do Protocol aqui é o que permite trocar de provedor sem alterar o restante do código: qualquer classe que implemente complete(system_prompt, user_prompt) serve, então AIAgent nunca precisa saber se está falando com Claude, Gemini ou ChatGPT.

Dessa forma, fica a critério de quem está utilizando o pacote selecionar qual IA será usada, podendo isso ser passado como parâmetro no momento da execução:

python main.py --pr 42 --repo owner/repo --provider gemini
python main.py --pr 42 --repo owner/repo --provider chatgpt
python main.py --pr 42 --repo owner/repo               # default: claude

Validando se o que foi gerado realmente está certo

Para a primeira validação, pesquisei alguns repositórios públicos no GitHub e, nesse caso, selecionei este PR: https://github.com/pallets/flask/pull/6043

python main.py --repo pallets/flask  --pr 6043  --provider gemini

E obtive o seguinte resultado:

Só que agora entra a parte complicada, sempre temos nos perguntar quando utilizamos IA:

Essa resposta faz sentido?

E, de cara, dá para ver que não — não está certo. Quando passamos um repositório diferente, ele continua buscando no repositório local, ignorando completamente o repositório do PR informado. Para corrigir isso, precisamos garantir que, sempre que for um repositório externo, o agente acesse as informações diretamente dele e para isso, vamos clonar temporariamente uma branch do repositório:

"""Clones a single branch of a GitHub repository into a temporary directory for local scanning."""

import logging
import shutil
import subprocess
import tempfile

logger = logging.getLogger(__name__)

class RepoFetchError(RuntimeError):
    """Raised when the target repository/branch cannot be cloned."""

class RepoFetcher:
    """Shallow-clones a single branch of a repository so its tests can be scanned locally."""

    def __init__(self, token: str | None = None) -> None:
        self._token = token
        self._tmp_dir: str | None = None

    def fetch(self, repo: str, ref: str) -> str:
        """Clones `repo` (owner/name) at branch `ref` and returns the local checkout path."""
        self._tmp_dir = tempfile.mkdtemp(prefix="ai-test-selector-")
        cmd = [
            "git",
            "clone",
            "--depth",
            "1",
            "--branch",
            ref,
            "--single-branch",
            self._clone_url(repo),
            self._tmp_dir,
        ]
        result = subprocess.run(cmd, capture_output=True, text=True)
        if result.returncode != 0:
            shutil.rmtree(self._tmp_dir, ignore_errors=True)
            self._tmp_dir = None
            raise RepoFetchError(f"Failed to clone {repo}@{ref}: {result.stderr.strip()}")
        return self._tmp_dir

    def cleanup(self) -> None:
        """Removes the temporary checkout, if one was created."""
        if self._tmp_dir:
            shutil.rmtree(self._tmp_dir, ignore_errors=True)
            self._tmp_dir = None

    def _clone_url(self, repo: str) -> str:
        if self._token:
            return f"https://x-access-token:{self._token}@github.com/{repo}.git"
        return f"https://github.com/{repo}.git"

Repare no --depth 1 e --single-branch do clone: como o objetivo aqui é só escanear os testes do repositório naquele ponto específico, não faz sentido trazer todo o histórico de commits — um shallow clone resolve o problema mais rápido e consumindo bem menos espaço em disco.

Rodando o mesmo comando, temos o seguinte resultado:

Em resumo, ele selecionou:

Selected 192/403 tests (avg confidence: 0.76)
pytest tests/test_appctx.py tests/test_async.py tests/test_basic.py tests/test_blueprints.py tests/test_cli.py tests/test_converters.py
tests/test_helpers.py tests/test_json.py tests/test_logging.py tests/test_regression.py tests/test_reqctx.py tests/test_request.py
tests/test_session_interface.py tests/test_signals.py tests/test_subclassing.py tests/test_templating.py tests/test_testing.py
tests/test_user_error_handler.py tests/test_views.py -v

É possível ver que com a IA, ao invés de rodarmos toda a suite, poderíamos rodar apenas 48% dela, reduzindo o tempo de execução e retornando um feedback muito mais rápido para quem está desenvolvendo a feature.

Conclusão

Como o artigo já está ficando grande, vou parar por aqui nesta primeira etapa. Revisando, o foco desta primeira parte foi refinar o prompt utilizado pela IA para gerar o código e, a partir disso, revisar o que foi gerado. Nela tivemos duas mudanças significativas:

Adaptação do código para utilizar diferentes provedores de IA, de forma que o projeto não ficasse preso a um único modelo.
Ajuste na busca dos testes, para que ela considerasse os testes disponíveis no repositório relacionado ao PR informado, e não no repositório local.

Próximos passos

Esse projeto ainda está bem no início, e pretendo continuar evoluindo ele nos próximos artigos. Já durante essa primeira parte, revisando o que foi gerado e testando em repositórios reais, surgiram algumas ideias novas que quero explorar:

Integração com pipelines: hoje o projeto roda de forma isolada, via linha de comando, mas o próximo passo natural é pensar em como plugar isso direto no CI/CD — por exemplo, como uma action do GitHub Actions que roda automaticamente a cada PR aberto e comenta com os testes selecionados, ou até já dispara só o subconjunto relevante.
Performance na parte de IA: com repositórios maiores, o número de testes disponíveis para avaliar cresce bastante, e isso significa prompts maiores e mais tempo de resposta. Quero investigar formas de otimizar essa etapa — seja filtrando os candidatos antes de mandar para a IA, seja quebrando a avaliação em lotes menores, ou até testando modelos diferentes para essa tarefa específica de classificação.

Se você quiser acompanhar a evolução do projeto (ou já colocar a mão na massa também), o código está aberto no meu repositório: ai-agent-test-selector

No próximo artigo, vou focar no prompt utilizado pela IA para selecionar os testes propriamente dito, além de adaptar o wrapper para ler repositórios que não sejam apenas em Python, mas também em outras linguagens.

Ficou alguma dúvida sobre alguma parte do código, do prompt ou da arquitetura? Deixa nos comentários — quero muito saber o que vocês acharam e trocar ideia sobre outros cenários onde isso poderia ser aplicado.

Programação Criativa: Vamos desenhar com código?

Sara Aniceto — Sun, 02 Aug 2026 01:36:54 +0000

Quem acha que a discussão entre arte gerada por computadores começou com a popularização das ferramentas de IA provavelmente perdeu boa parte das discussões envolvidas em arte generativa, arte computacional e design paramétrico que surgiram ainda no século passado. A Programação Criativa, que vamos entender melhor nesse artigo, é uma das formas possíveis de gerar arte a partir de algoritmos que vai muito além de mandar um prompt pra IA e esperar sua arte ser gerada. É construção, linha a linha, onde o programador faz da tela do computador e das linhas de código seu papel e pincel. Vem comigo entender melhor como usar suas habilidades de desenvolvimento para se divertir, experimentar e deixar a criatividade rolar solta.

O que é Programação Criativa?

Uma das coisas mais legais que ouvi me adentrando nos estudos de creative coding (termo em inglês para programação criativa) é que existem muitas pessoas que programam, mas que não são necessariamente "programadoras". A programação não precisa estar presa apenas à sua carreira, ela pode ser uma paixão, um hobby ou um playground lúdico.

A Programação Criativa é exatamente isso: usar o código para desenhar, criar animações e "brincar" com o computador. Em vez de focar apenas na criação de sistemas ou análise de dados o objetivo aqui é a exploração visual.

Você consegue acreditar que a imagem acima foi gerada com 0 linhas de um código Java? Em seguida vou te explicar melhor sobre o Processing e outras ferramentas de programação criativa.

Processing e p5.js: Onde o desenho encontra o algoritmo

Processing e o p5.js são duas das ferramentas mais populares criadas para facilitar o contato de artistas, ilustradores, designers e pessoas não programadoras em geral que queiram criar arte usando código.

A lógica entre eles é a mesma, o que muda são especificidades da sintaxe de cada linguagem.

Processing: Criado em 2001, é baseado em Java e é o "pai" de tudo isso. É um software gratuito, no formato de IDE, no qual você consegue escrever, executar e compilar os seus códigos, ou melhor suas obras (aqui chamadas de sketches).
p5.js: É uma versão do Processing baseada em JavaScript, mais popular atualmente e feita para rodar direto na web.

Hoje em dia também é possível usar o modelo do Processing baseado em Python e para a criação de aplicativos Android. O mais importante é entender que, enquanto no Photoshop você usa o mouse para desenhar, aqui você começa a desenhar escrevendo em uma página em branco.

A Anatomia Básica do Código (Para quem já coda entender)

Diferente de um script tradicional, a estrutura básica nessas ferramentas é muito simples e visual:

setup(): É a função que roda uma única vez assim que o programa inicia. É aqui que você define configurações importantes da sua arte, como o tamanho do seu "papel" (canvas).
draw(): Aqui é onde a mágica acontece. Essa função é um loop infinito. Ela é lida ciclicamente enquanto o programa roda. Se você desenhar algo aqui, pode criar animações ou responder a eventos, como o movimento do mouse.

Com essa estrutura pronta, vale acessar a documentação e entender as inúmeras possibilidades de formas, elementos tipográficos, animações, etc que é possível criar com essas ferramentas. Esse pedaço de código abaixo é o que gerou a imagem que eu mostrei no início do artigo.

void draw(){
  background(255);
  fill(0);
  noStroke();

  float tiles = mouseX/10;
  float tileSize = width/tiles;

  translate(tileSize/2,tileSize/2);

  for(int x = 0; x < tiles; x++){
    for(int y = 0; y < tiles; y++){

      //Picks the color based on the pixel, in which the pixel is the size of the tiles
      color c = img.get(int(x*tileSize),int(y*tileSize));
      float size = map(brightness(c),255,0,0,20);

      ellipse(x*tileSize,y*tileSize,size,size);
    };
  };
}

Uma ferramenta visual de aprendizado de programação

É possível que você ainda não tenha sido convencido de explorar o Processing e a programação criativa para despertar o lado artista que mora em você? Se sim, eu te faço uma pergunta: quando é que você parou de desenhar e virou um adulto chato sem criatividade?

Brincadeiras à parte, talvez então você seja convencido de que a programação criativa pode também servir como um facilitador para o aprendizado técnico porque transforma conceitos abstratos (como laços de repetição e condicionais) em resultados visuais e imediatos na sua tela.

É como um "debug visual". Afinal, ver um for loop gerando 100 bolinhas coloridas na sua tela em tempo real é a melhor forma de "debugar" sua lógica mental.

Conclusão: Experimente!

Se você sente que a programação às vezes fica um pouco "rígida" ou mecânica demais, tente criar um sketch no Processing ou p5.js. É uma forma de usar sua lógica para algo puramente estético e divertido.

Abaixo deixo alguns links para encontrar referências de projetos, materiais gratuitos e comunidades pra quem quiser conhecer mais:

OpenProcessing: Plataforma de hospedagem de projetos em Processing, é o GitHub da Programação Criativa
Curso gratuito de Programação Criativa: Repositório no GitHub de curso por Monica Rizzolli e Alexandre Villares
Código Transcendente : Uma introdução prática à programação e arte gerativa: Livro de Mateus Paresqui Berruezo
Compoética - Encontro Brasileiro de Programação Criativa
Comunidade de Programação Criativa no Brasil no Telegram

Pensar demais nem sempre ajuda e o que eu aprendi com isso

Yuri Souza — Sat, 01 Aug 2026 10:57:53 +0000

Às vezes, a maior barreira para começar um projeto não é a complexidade do problema, mas a busca por uma solução perfeita antes mesmo da primeira linha de código.

Na semana passada decidi criar um pacote Laravel para integrar a API do Asaas.

A ideia parecia simples: construir algo reutilizável para projetos futuros e, de quebra, aprender mais sobre desenvolvimento de pacotes.

Foi então que eu:

Abri a IDE e comecei a criar um cliente HTTP simples para a API da Asaas.
15 minutos depois, eu já estava pesquisando sobre arquitetura de pacotes open source.
Pensei em DTOs.
Pensei em interfaces.
Pensei em Services

O que eu entendia por "perfeito"?

Na minha cabeça, um projeto bem feito precisava nascer parecido com os grandes projetos open source que eu admirava.

Antes mesmo de validar a ideia, eu já pensava na arquitetura, na escalabilidade e em como aquele pacote pareceria para quem abrisse o repositório. E em outros cenários como:

pensar na mesma arquitetura que grandes projetos usam antes de ter o primeiro caso de uso funcionando;
tentar abordar todos os pontos da API da Asaas logo no começo, mesmo sem saber quais eu realmente ia usar;
imaginar os atrativos que meu pacote teria para outros quererem usá-lo, antes de ele fazer qualquer coisa útil.

No papel, parecia que eu estava pensando como alguém mais experiente, mas na prática, eu estava:

apenas adiando a parte mais importante que era escrever código que resolvesse um problema real.

O custo disso na prática

O curioso é que eu terminava o dia com a sensação de que tinha trabalhado bastante. Tinha lido sobre arquitetura, desenhado camadas, esboçado interfaces.

Só que, olhando para o projeto, praticamente nada tinha sido construído: nenhuma requisição enviada, nenhum teste rodando, nenhuma prova de que qualquer uma daquelas decisões fazia sentido.

Com o tempo, isso começou a gerar um padrão:

Mais tempo buscando a estrutura "perfeita" do que resolvendo o problema real;
Código difícil de entender por estar "bem arquitetado" demais, cedo demais;
Medo de refatorar algo que ainda nem tinha provado valor;
Uma frustração crescente por sentir que eu não estava evoluindo, só girando em torno da mesma decisão de design.

Não era falta de qualidade. Era complexidade antecipada.

O que eu estava realmente evitando?

Foi só depois que comecei a me perguntar outra coisa: por que eu estava tão preso nisso?

Algumas hipóteses:

Eu estava evitando escrever código que eu soubesse, de antemão, que ia precisar refatorar depois?
Eu tinha medo de escrever algo "ruim" e isso aparecer publicamente num repositório open source?
Eu queria provar, pra mim mesmo, que conseguia arquitetar "como um sênior" antes mesmo de ter o problema resolvido?

A resposta provavelmente era um pouco de cada uma. E nenhuma delas tinha relação com o problema que o pacote deveria resolver.

Só bem depois entendi que, no fundo, eu confundia complexidade com maturidade técnica.

O aprendizado que começou a aparecer

Enquanto refletia sobre isso, lembrei de uma frase que minha mãe repetia desde que eu era pequeno:

"Antes feito do que perfeito."

Sempre achei que essa frase servia para tarefas do dia a dia, como arrumar o quarto, terminar um trabalho da escola. Nunca imaginei que ela fizesse tanto sentido ao escrever software.

Junto com ela, veio outra ideia:

Bons sistemas não nascem perfeitos. Eles evoluem.

Nenhum dos projetos open source que eu admirava nasceu com a arquitetura que tem hoje; todos passaram por versões mais simples, mais cruas, que foram se modificando à medida que o uso real foi aparecendo.

Qualidade não está em prever todos os cenários.

Qualidade está em escrever código que consiga mudar quando esses cenários realmente aparecerem.

Foi só quando parei de procurar a arquitetura perfeita que finalmente escrevi minha primeira requisição de verdade para a API.

Antes mesmo de escrever a primeira integração, era assim que eu imaginava o pacote:

CustomerService
        ↓
AsaasClient
        ↓
CreateCustomerDTO
        ↓
Response

Mas não comecei com uma arquitetura cheia de camadas. Comecei com algo assim:

$asaas->customers()->create([
    'name' => 'Yuri Souza',
    'cpfCnpj' => '12345678909',
]);

Desde então, passei a repensar algumas atitudes:

resolver o problema atual com clareza antes de pensar no próximo;
manter o código simples, legível e testável;
criar abstrações apenas quando um padrão se repete de fato, não quando eu imagino que ele vai se repetir;
aceitar que refatorar faz parte do processo, não uma falha dele.

Não se trata de abandonar boas práticas, mas de aplicá-las no momento certo.

O equilíbrio que estou buscando hoje

Hoje tento encontrar um equilíbrio entre dois extremos: nem escrever código sem critério, nem criar uma arquitetura complexa antes que ela seja necessária.

No próprio pacote do Asaas isso já mudou a forma como estou trabalhando.

Hoje, a decisão que tomei foi outra: começar pelo caminho mais curto possível.

Primeiro quero que o pacote consiga conversar com a API e validar os casos de uso mais importantes. Só então vou descobrir quais abstrações realmente fazem sentido.

Em vez de tentar prever a arquitetura que o projeto terá daqui a um ano, prefiro deixar que ela se desenvolva à medida que novos problemas surgirem.

Foi aí que entendi uma coisa importante:

Arquitetura não é algo que eu preciso descobrir antes de começar. É algo que o próprio projeto vai mostrando à medida que cresce.

Conclusão

Ainda estou no começo desse pacote, e ainda estou aprendendo isso na prática, errando e ajustando no caminho.

Mas entender que "perfeição antecipada" pode virar um problema já foi um passo importante na minha evolução como desenvolvedor. O projeto do pacote Asaas não precisa da arquitetura perfeita logo de início; precisa apenas da primeira implementação. O resto vai aparecer conforme o uso real for mostrando o caminho.

Hoje prefiro um código simples que aceite mudanças a uma arquitetura impecável que resista a qualquer alteração.

Se você também já caiu nessa armadilha da arquitetura perfeita antes da hora, quero saber: como você percebeu e o que fez para sair dela?

A discussão continua nos comentários. Quero muito conhecer outras experiências e perspectivas sobre esse tema.

Agradecimentos: obrigado a @vitoriazzp pelo feedback sincero e pelas sugestões que ajudaram a tornar este artigo mais claro e útil.

Se eu pudesse recomeçar em TI, evitaria estes erros.

Aline Santana — Wed, 29 Jul 2026 13:39:48 +0000

Prólogo

No início da faculdade, séculos atrás (papo de 2021, foi quando entrei na he4rt developers inclusive) estava extremamente ansiosa e com isso cometi MUITOS ERROS, me levou ao bornout ficando SEM ESTUDAR por meses, até hoje vejo as pessoas cometendo a mesma coisa que eu no passado e isso atrasa MUITO os estudos! Como sempre meus artigos são super rápidos de ler, espero que gostem!

1º Não dê ouvidos as pessoas da área (depende)

Acho que o maior erro na internet, inclusive através de influenciadores, é o alarme negativo pra cima de áreas na tecnologia e até mesmo linguagens de programação, fazendo com que iniciantes tenham incertezas sobre o que está estudando.

Exemplo 1 : "Você estudando frontend? vai passar fome."
Exemplo 2 : "A IA vai roubar teu emprego como desenvolvedor xxx"
Exemplo 3 : "Flutter vai morrer esse ano de xxx"

Sendo bem sincera, nem ligue pra isso, tá? até hoje tem emprego pra COBOL, imagine pra tecnologias super modernas que muitas empresas usam, escolheu frontend (exemplo) ? estude, se esforce, converse com pessoas mais experientes nesse segmento e vai fundo, não desista por terceiros! Escolheu Python? cai dentro, a opinião da galera não pode definir teu futuro não.

2º Não pula de galho em galho

FOCA NO QUE ESCOLHEU E NÃO PULA, pois foi algo que cometi bastante, eu fui de dados até mobile com Flutter (tô escrevendo isso e rindo alto).

Vocês no outro lado da tela : "Aline, o que você faria hoje?"

Simples, como disse no primeiro artigo, autoconhecimento é importante, o que você gosta? isso que você gosta é evidência no mercado? pesquise, sai na busca.

1. Gosta de Matemática? _Ciência de Dados seria uma boa._
2. Gosta de celular? Por que não se envolve com criação de aplicativos?
3. É mais de "arte"? Já ouviu falar de UX/UI?
4. É visual? e desenvolvimento frontend?

Entende isso? é normal se perder com tantas informações e tantas áreas dentro de tecnologia, vai pesquisando com calma e veja qual se identifica.

3º IA é sua amiga, não inimiga, tenha medo não

Não me venha com o argumento : "Aline, não quero ser de TI pois a IA vai roubar meu emprego", vai nada amigo(a), LLMs em geral são feitas dentro de pesquisas e trabalhadas no que chamamos de probabilidade, é mais fácil tu acertar algo do que ela (risos), não vou ser hipócrita em dizer que IA não ajuda em algo, CLARO que ajuda, inclusive quando se trata de automação de tarefas, mas o que quero dizer é que VOCÊ TEM QUE SABER O QUE TÁ FAZENDO E NÃO DEIXAR A BASE DE LADO, ou seja : "Ai, não vou estudar programação, vou pular pro Claudinho", vai nessa, prejuízo é enorme.

"Mas fulano de tal usa", é que o "fulano de tal" já tem uma base muito sólida no conhecimento daquela linguagem, estamos entendidos? quando passei pela stack de Frontend, era um alarme com Inteligência Artificial gigantesco, tive muito medo e troquei de área, me atrasou muito. (na época)

4º Marca Pessoal galera, é importantíssimo!

Depois de um bom período me tratando psicologicamente (depressão), voltarei com o linkedin, mas vejo que muita gente faz descaso com essa rede, principalmente iniciantes! Motivos? talvez timidez (comum), não gosta, preguiça? talvez, eu não sei, só você sabe.

De forma geral, tenha uma marca pessoal trabalhada, isso é importante até mesmo dentro de comunidades, como os recrutadores podem analisar além do seu currículo destacado? acho um cristal quem faz conteúdo de tecnologia nessa rede, lá estão a maioria dos recrutadores e donos de empresas, seja visto!

Dica geral :

Escolha cores que lhe representam ou que você quer transmitir
Traga experiência real nos seus conteúdos
Não seja um personagem

Conclusão

Espero que tenham gostado desse artigo, eu poderia listar TANTAS COISAS que me atrasaram ou podem atrasar vocês, mas listei as mais importantes da minha vivência e que afeta iniciantes como eu.

Agradeço a He4rt Developers por essa iniciativa dentro da comunidade em instigar membros dentro da escrita

2 métodos que usei (E USO) nos estudos de programação.

Aline Santana — Mon, 27 Jul 2026 14:58:19 +0000

Prólogo

Para uma pessoa que tem TDAH (eu), é extremamente difícil e desafiador encontrar uma maneira mais “confortável” de estudar, ainda mais quando tal assunto é de exatas (sou de humanas e tô em TI, pasmem), então resolvi encontrar algumas maneiras e que claro, deu super certo pra mim e espero muitíssimo que dê certo pra vocês.

Observação (dica) : vai testando cada método, não pegue um como verdade absoluta, o que ficar confortável, use <3

Nem todos vão se dar bem com o método X e Y, cada cérebro funciona de uma maneira diferente, alguns de vocês vão se adaptar com vídeos, textos (artigos como esse), presencial ou online, o melhor jeito de encontrar o método “perfeito” é ter autoconhecimento, eu por exemplo : tem que ser mais prática do que teoria, vídeo aula ? tem que ser curto (longo demais me perco), o estudo tem que ser mais ativo do que passivo, revisão ? 0 aplicativo, revisão pra mim é prática.

Vamos ser bem rápidos com os métodos para usar como um mini caderno.

Método Feynman

Criado pelo físico (vencedor do prêmio nobel, tá?) Richard Feynman, seu método é basicamente fazer autoexplicação usando palavras e analogias de forma mais simples, sem esse jargão técnico que pode mais atrapalhar do que ajudar (ainda mais pra nós, meros iniciantes).

1.1 Já pega seu conteúdo que estuda.

O primeiro passo é escolher o que você está estudando, especialmente o que está travando seu cérebro, aquela parte do estudo que mesmo entendendo ainda sente falta de alguma coisa.

1.2 Explique de forma “leiga”.

Imagina que você é uma criança, primo(a), esse momento é importante que tire os conceitos técnicos que possivelmente pode “impedir” de aprender de forma fácil e explique do seu jeitinho, sem conceitos técnicos, sem palavras difíceis. Um prompt que é meme, mas eu uso bastante é : “Explique assunto xxx como se eu fosse uma criança de xxx anos, sem conceitos técnicos para que eu entenda de forma fácil e rápido”, após isso (novamente como disse) explique para si mesmo.

1.3 Lacunas.

Primo(a), em algum momento da explicação vai perceber que teve algumas lacunas na sua explicação (isso é normal, tá? você tá aprendendo, eu lembro que ficava muito chateada também rs), anote essas lacunas e até mesmo suas dúvidas, vamos para o último passo.

1.4 Refinamento.

Último passo (é bem simples), tudo que encontrou de lacunas e dúvidas você vai achar no material que estudou, anote, identifique e volte novamente ao passo 1.2, onde vai explicar com as lacunas preenchidas. (caso ainda tiver dúvida, repita o mesmo processo até aprender).

2° Active Recall - Meu querido (O que eu faço)

Active recall seria o “método ativo”, iria forçar seu cérebro a relembrar assunto que estudou minutos ou horas atrás, um dos exemplos bem legais é o método feynman que expliquei anteriormente, mas vou explicar a forma que faço.

2.1 - Assista o vídeo até determinado ponto.

Se for uma videoaula (ou qualquer material que esteja usando viu), sempre que o professor concluir a explicação de um tópico e iniciar outro, pause o vídeo e anote apenas os principais tópicos.

Exemplo: o professor começa contando como foi a experiência dele na faculdade de Engenharia de Software. Em seguida, ele passa a explicar por que utilizou determinada linguagem de programação durante o curso. Assim que ele concluir esse assunto e antes de iniciar o próximo, pause o vídeo e anot*e os pontos PRINCIPAIS*, não sua explicação ainda.

Exemplo 2 (anotação) : Aqui ele explicou sobre sua experiência na faculdade. (pronto, escreve mais nada)

2.2 - Torra seu cérebro.

Não volte na sua vídeo aula, documentação e afins, olhe para o tópico anotado e tente lembrar com suas próprias palavras o que ele disse, sim, funciona até com código (é muito bom, mas dá um leve estresse kkk), você escolhe se fará anotação ou explicar com suas próprias palavras (feynman).

Conclusão

Na realidade existem vários métodos de estudos para cada cabeça, como disse no prólogo, autoconhecimento na jornada de programação já é um passo maravilhoso, não se cobre ou até mesmo se estressa demais durante os estudos, é NORMAL não saber de primeira, só não desista.

Agradeço a toda comunidade por sempre instigar a compartilhar nossos conhecimentos.

Como eu venci o medo da transição de carreira

Bárbara Martins da Silveira — Sun, 26 Jul 2026 19:12:49 +0000

Migrar de carreira para a área de tecnologia pode parecer difícil no início. O mercado está cada vez mais concorrido, além de estar passando por muitas transformações. Realizar a transição não é um processo fácil, mas é totalmente possível, mesmo que você esteja em uma área completamente diferente, ou atue há muitos anos em outro setor. Nesse artigo, compartilho como foi o meu processo, além de dar algumas dicas para quem está em transição ou pensando em iniciar a mudança de carreira.

Sumário

O início da jornada
Reconhecendo a insatisfação
Os primeiros medos
Lidando com críticas
A conquista da primeira vaga
Dicas para quem está em transição de carreira:

O início da jornada

Nessa semana completo 1 ano da minha transição de carreira. Sei que, para quem acompanha de fora, pode parecer que foi fácil ou que tive sorte em algum momento. Mas quem está na área de TI sabe o quanto esse processo é complexo. Ao olhar para trás, sinto como se passasse um filme na minha cabeça.

Reconhecendo a insatisfação

Desde o começo, a transição foi difícil: reconhecer que eu não estava satisfeita na carreira atual, lidar com rotina dupla, exaustão, críticas de pessoas próximas e o medo de recomeçar. Antes de iniciar meus estudos em tecnologia, minha rotina era insana e eu dormia poucas horas por noite. Até que percebi que não estava evoluindo e que a carreira para a qual me preparava já não fazia sentido. Foi então que decidi tirar do papel uma vontade que surgiu na pandemia, mas que o medo de começar havia travado: estudar tecnologia.

Os primeiros medos

No início, eu tinha medo de tudo: baixar uma IDE, mexer em código, enviar algo para o git, errar e falhar. Criar um post em rede social como o LinkedIn, então? Parecia absurdo compartilhar que eu estava tentando migrar de área. Mas mesmo com medo, iniciei e não deixei que minhas inseguranças me paralisassem. Consegui começar minha graduação online, muito mais flexível e adaptada aos meus horários, e descobri algo novo: a felicidade em evoluir e aprender sobre um assunto que eu realmente gostava.

Lidando com críticas

As críticas vieram. Algumas pessoas diziam que seria apenas um interesse passageiro, que eu estava desperdiçando meu curso anterior na federal, que era loucura iniciar algo novo nessa altura da carreira. Trabalhei isso em terapia e aprendi a ignorar opiniões que não acrescentavam nada.

A conquista da primeira vaga

Depois de 3 meses estudando, comecei a aplicar para processos seletivos, entender como funcionava o LinkedIn, criar posts, realizar conexões e focar nas áreas que realmente me interessavam. Foi um processo construído aos poucos, mas perdi o medo de escrever e meu perfil deixou de ser invisível. Aos poucos, as oportunidades começaram a aparecer e, em 6 meses de busca, conquistei minha tão sonhada vaga (claro que depois de muitos nãos). Mais do que isso: pude ajudar outras meninas que me procuraram em busca de dicas para ingressar na área, e isso é motivo de muito orgulho para mim.

Dicas para quem está em transição de carreira:

Comece com medo mesmo: no início, o processo é assustador, mas comece com medo mesmo. A primeira vaga é a mais difícil de conseguir.
Aceite que nem todos os dias serão bons: cada dia passado é um passo a menos até conquistar seu espaço.
Mantenha o LinkedIn ativo: mesmo que você não goste da rede, hoje praticamente todas as vagas passam por lá.
Invista em networking: em uma área tão concorrida, relacionamentos são até mais importantes que conhecimento técnico.
Participe de comunidades tech: as comunidades tech como a He4rt são espaços de troca de ideias, colaboração, eventos, engajamento e projetos open source. É o melhor lugar para trocar ideias, conversar com pessoas que estão passando pelo mesmo processo que você, além de participar de projetos reais que podem somar muito ao seu currículo.

Se você pensa em migrar de carreira ou está passando por esse momento agora, lembre-se: essa fase exige paciência e persistência, mas cada projeto, cada conexão e cada tentativa te aproximam do tão sonhado sim. Para quem já passou ou está passando pela transição para TI, quais foram seus maiores desafios e aprendizados? Compartilhe nos comentários! A sua experiência pode inspirar outras pessoas.

Começando com Redes: Camadas de uma conexão TCP/IP

Cristian Magalhães — Fri, 24 Jul 2026 12:37:44 +0000

Eae gente bonita, beleza? Depois de um longo período, resolvi voltar aqui e continuar compartilhando a minha trilha de estudos com vocês. Hoje vou começar (tentar pelo menos) uma série sobre redes.

Por que estudar redes

Começaremos com o porquê de aprofundar os estudos em redes. Conforme a sua senioridade vai aumentando, você vai ganhando novas responsabilidades para si e também dentro do ambiente de trabalho. Levando isso em consideração, ter o conhecimento básico de redes para poder ter mais autonomia e autoridade quando falar de cloud, arquitetura e coisas do tipo realmente não me parece ser uma má ideia. "Ah, mas na minha empresa tem devops que cuida disso", ainda assim, é necessário o mínimo de conhecimento teórico para conversar e até mesmo ajudar a entender o seu problema e criar soluções.

TCP/IP

Explicando a sigla basicamente, o modelo TCP/IP é um conjunto de protocolos de comunicação que permite a conexão e a troca de informações na internet.

O conjunto recebe o nome de seus dois protocolos principais:

IP (Internet Protocol) = Responsável pelo roteamento dos pacotes e endereçamento para que as informações cheguem ao seu destino.
TCP (Transmission Control Protocol) = Está presente na camada de transporte garantindo que nenhum pacote seja perdido ou corrompido.

Como funciona o modelo TCP/IP

Gosto muito de sair do escopo macro para o micro. Basicamente, uma conexão ocorre quando duas máquinas estão trocando informações (pacotes) entre si. E não precisa ser sempre dessa forma; também temos o caso (mais comum) em que uma máquina (cliente) pede informações a outra (servidor).

Ficou simples até demais, né? Para que a troca de informações funcione, existe uma série de passos a serem seguidos. Dentro de uma conexão existem algumas camadas, pelas quais a informação passa antes de chegar ao seu destino.

L7 = É a camada de aplicação, onde a aplicação roda e também onde roda o protocolo HTTP, SMTP.

L4 = Camada de transporte: responsável por garantir a entrega confiável dos dados entre a origem e o destino (é aqui que atua o TCP).

L3 = Camada de rede: responsável pelo roteamento dos pacotes e endereçamento até o destino (é aqui que atua o IP).

L2 = Camada de enlace: responsável por transmitir os quadros de dados entre dispositivos dentro da mesma rede, através do endereço MAC.

Isso é uma regra geral. A camada de cima sempre usa os recursos da camada de baixo para enviar as informações.

Importante lembrar: caso uma camada de baixo não funcione, a camada de cima também não funcionará.

O que é um pacote

Basicamente um pacote é uma carta ou mesmo uma "caixa" por onde as informações são trafegadas na internet. Além das informações requisitadas, nele constam também o remetente e o destinatário, da mesma forma que em uma carta.

Por fim...

Hoje falei um pouco sobre como funciona uma conexão, como é estruturada e como funciona todo o processo de troca de informações. Em breve trarei mais tópicos sobre o que existe dentro de uma mensagem HTTP e coisas do tipo.

Se chegou até aqui, me segue lá nas redes vizinhas.

Contribuir para a comunidade: como destacar isso no seu LinkedIn e currículo

vitoriazzp — Wed, 22 Jul 2026 18:11:09 +0000

Como eu mostro que estou contribuindo?
Posso colocar no meu LinkedIn?
E no meu currículo, como faço?

Foi a partir dessas dúvidas que eu elaborei esse guia pra você que quer contribuir do seu jeito e mostrar às empresas e às pessoas, de forma clara e estratégica, o que você está fazendo.

Vamos lá? 👇

Por que eu deveria mostrar no LinkedIn?

LinkedIn é a porta de entrada para o mundo corporativo no Brasil e no mundo. É por meio dele que você mostra "trabalho". E tem mais: não é só experiência remunerada que conta como evidência de que você tem conhecimento e prática, mas também tudo o que você constrói de forma voluntária, seja tirando dúvida de alguém, participando de um projeto open-source ou escrevendo sobre o que aprendeu. Recrutador não lê currículo pensando só em carteira assinada. Lê pensando em capacidade.

Você contribui com algo para a comunidade e quer colocar isso no seu perfil. Existem 3 formas que você pode usar, e elas podem ser usadas todas juntas ou só uma.

Escolha aquela que fizer mais sentido pro seu perfil ou busque por outras pessoas que você admira dentro da comunidade e veja como elas colocaram no próprio perfil.

1. Seção de Experiência

Use como experiência sempre que estiver contribuindo de forma profissional pra uma área que você busca. Se você participa de contribuições no GitHub, seja através de código, documentação ou outra forma, use como experiência.

Pessoas que também estão ajudando na moderação ou administração (community managers) podem destacar as responsabilidades ou resultados das suas ações por aqui.

Exemplo de como preencher no LinkedIn:

Cargo: [cargo que você faz] Open Source
Empresa: [Nome do projeto/organização]
Tipo de emprego: Meio período (ou Voluntário)
Local: Remoto, Brasil

Descrição:
- Contribuí com [X] pull requests na documentação do projeto [Nome],
  focando em clareza para novos contribuidores.
- Revisei issues abertas e sugeri melhorias de acessibilidade em
  componentes de UI usando [ferramenta/stack].
- Participei de reuniões semanais de planejamento com o time core
  do projeto.

Se estiver em dúvida sobre a sua atuação em algum projeto ou até especificamente sobre como colocar, comenta aqui ou chama a gente no Discord; ficaremos felizes em te ajudar.

2. Seção de voluntariado

Esse espaço é um pouco mais livre. Você pode usar pra mostrar que é membro da comunidade, moderador ou outro cargo que faça sentido e descreva sua participação. Não é necessário listar ou descrever o que você faz, só se quiser 🫣

Exemplo simples:

Organização: He4rt Developers
Função: Devloper Advocated
Causa: Ciência e tecnologia
Período: Março de 2025 - Presente

Descrição (opcional):
- Lidero o programa de advocacia da comunidade, conectando
  membros a oportunidades de conteúdo e mentoria.

Exemplo mínimo, sem descrição:

Organização: Friends of Figma Porto Alegre
Função: Voluntária (fotografia e recepção de convidados)
Período: 2025 - Presente

3. Seção de Projetos

Participa de um projeto específico da comunidade? Essa seção é a mais indicada pra você nesse caso, porque dá visibilidade às suas stacks e skills. Por isso é importante estruturar:

Nome do projeto
Prévia (print ou link do repositório)
Descrição do que é
Stacks que você aplica durante as suas contribuições
(opcional) Marque quem está no projeto com você

Exemplo:

Nome do projeto: Plataforma da He4rt 
Link: github.com/he4rt/heartdevs.com

Descrição:
Landing page da comunidade He4rt Developers,
Construída com identidade visual própria (roxo He4rt, dark mode).

Minha contribuição:
Design e desenvolvimento front-end da página, do wireframe
À implementação em PHP.

Stacks: Figma, React, Tailwind CSS, Claude Design

Depara: quem tem experiência x quem não tem

Um erro comum é achar que sem carteira assinada não tem o que mostrar. Não é bem assim. Muda a forma de descrever, não a legitimidade do que você fez.

Nos dois casos, a régua é a mesma: se você fez, pode mostrar. O que muda é o quanto de contexto você precisa dar pra quem está lendo confiar no que está escrito.

Segunda parada: currículo

É importante manter as mesmas informações que você tem no LinkedIn. Caso não tenha experiência formal, mas contribua pra comunidade, pode colocar diretamente na seção de experiência, com pelo menos 2 bullets do que você fez, como fez e qual foi o resultado.

Exemplo:

He4rt Developers (Tecnologia)
UI/UX Designer | Remoto, Brasil | Março 2026 - Presente

- Desenvolvi microcopy e fluxos de UI para funcionalidades internas
  da comunidade, aplicando princípios de acessibilidade e clareza.
- Colaborei com o time de desenvolvimento na construção da landing
  page de artigos, do wireframe em Figma à entrega final em React.

Exemplo pra quem já tem experiência formal em outra área e quer somar a contribuição:

Friends of Figma Porto Alegre (Comunidade)
Voluntária | Porto Alegre, Brasil | 2025 - Presente

- Apoiei a organização de eventos presenciais, atuando na recepção
  de convidados e registro fotográfico do evento.

Um modelo pra chamar de seu

Pra facilitar essa parte do currículo, criei um modelo que passa tanto pela leitura de um recrutador humano quanto por um ATS (o robô que filtra currículo antes de chegar em alguém). Ele serve tanto pra quem já tem experiência formal e quer só organizar melhor, quanto pra quem está usando a comunidade como primeira experiência pra registrar no papel.

Modelo Currículo (com e sem experiência) - Google Docs

docs.google.com

Contribuir pra comunidade é trabalho, mesmo sem salário no fim do mês. E o trabalho merece estar registrado em algum lugar que outras pessoas possam ver.

Se esse guia te ajudou a organizar como colocar sua contribuição no LinkedIn ou no currículo, conta aqui nos comentários:

Qual a sua maior dor hoje pra mostrar as suas contribuições no LinkedIn ou no currículo?

Produto 4 Devs

Renan Vidal Rodrigues — Thu, 16 Jul 2026 13:43:06 +0000

Todo Dev tem que entender que "ou tu aprende sobre Produto e Regras de Negócio ou tu vai ficar pra trás", o código é só 30% da resolução do problema!

Tabela de Conteúdo

1. Prólogo
2. O que é um Produto? (Sem enrolação)
3. Por que um dev deveria se importar?
4. Diferença entre Projeto e Produto
5. Ciclo de vida do Produto
6. O que importa o Dev entender do ciclo de vida do produto?
7. Conclusão
8. Se interessou?

1. Prólogo

Cada vez mais vejo que é essencial para um Dev ou para um time de desenvolvedores entenderem sobre Produtos e Regras de Negócio, pois é isso que mercado espera.

É como o Daniel (He4rt) Reis sempre fala o mercado espera Devs desenrolados que buscam entender as regras de negocio, do produto em si! Pois código é só 30% do trabalho, os outros 70% são a capacidade de entender o produto e debater sobre o mesmo.

Pensando nisso decidi escrever uma série de artigos focados em Produtos para Devs, buscando preencher uma lacuna comum nas equipes de desenvolvimento, buscando aproximar desenvolvimento e produto sem jargões ou excesso de teoria. Para ajudar aqueles que querem aprender sobre e também uma forma de sintetizar meus conhecimentos.

Mas você deve estar ai pensando:

"Mas Renan esse conteúdo faz sentido pra mim que estou começando a estudar programação agora?

E minha resposta é Sim, esse conhecimento é fundamental para você, seja você uma pessoa que começou a estudar programação agora, um júnior, um pleno, um sênior, ou simplesmente alguém que está pensando em migrar de área. E novamente Sim esse conteúdo é para você ai, que quer se destacar e sair na frente de muita gente que pensa que hoje é só vibecodar e tudo vai dar bom!

Portanto vamos começar abordando o tópico que acredito ser o que é mais sentido para iniciarmos essa jornada que é:

2. O que é um Produto? (Sem enrolação)

Mas e ai o que é um produto de verdade? Um produto não é um software, pois um software pode ser apenas uma ferramenta, um produto é o valor real entregue ao usuário! Um produto é resolver um problema de negocio de forma sustentável!

Um Produto sempre, mais sempre mesmo só ira surgir para resolver um problema, uma dor, uma necessidade ou simplesmente satisfazer um desejo de um usuário ou um cliente. Seja esse usuário uma empresa ou um simples cliente.

Mas vale ressaltar que nem todo produto resolve uma dor intensa, muitas vezes alguns apenas amenizam essa necessidade, alguns ganham tempo, outros geram status ou entretenimento. Mas o mais importante é que sempre um produto entregam algum valor ao usuário.

Mas e o produto digital?
Agora que já entendemos o conceito básico de produto, podemos dizer que um Produto digital é qualquer software que tenha usuários e entregam algum tipo de valor a esse.

3. Por que um dev deveria se importar?

Essa é a pergunta de milhões que faz toda diferença e sua resposta é bem simples quando paramos para pensar que decisões técnicas que são tomadas pelo time tech impactam no negócio, que toda divida técnica também é uma decisão de de produto e que a performance, segurança e escalabilidade também são uma entrega de valor.

Tendo isso em vista podemos entender que um dev que se importa em entender as Regras do Negocio e entender o Valor que o Produto busca entregar, consegue enxergar qual caminho deve seguir, quais decisões devem ser levadas em consideração na construção da arquitetura de um produto, quais funcionalidades agregaram mais valor a experiencia do usuário, como um banco de dados deve ser modelado para poder atender a necessidade deste produto.

Além disso essa compreensão permite o dev questionar, debater e a elaborar planos de ação muito mais eficientes e que muitas vezes evitam muito retrabalho e refatoração de código, que muitas vezes aparecem pelo fato de você ter simplesmente ter "codado" uma funcionalidade sem entender todo o escopo do que o produto se propõem através da mesma.

Então jovens lembrem-se, entender o Produto evita retrabalho, e evitar retrabalho significa menos esforço e mais tempo para outras coisas que realmente valem a pena!

4. Diferença entre Projeto e Produto:

Agora que acredito que já desenvolvemos uma visão legal do que é Produto, podemos debater um pouco sobre a diferença entre um Projeto e um Produto. Claro que neste momento você deve estar se questionando: "Mais não é tudo a mesma coisa no final?" e foi esse mesmo pensamento que tive até entender que:

Projeto:

Tem seu escopo é fechado, muito bem delimitado e definido no planejamento, tendo um começo, meio e fim claramente definidos e desenhados, tem um foco na entrega com um caminho bem documentado e claro pode funcionar em cenários previsíveis.

Produto:

Já um produto tem um escopo mais aberto pois seu foco inicial é resolver uma problema e não o como, geralmente ele tem um começo e meio que podem ser identificáveis, mas seu fim não. Seu foco esta no resultado, tendo um objetivo bem definido, e para isso faz uso de experimentação, testes e validação de ideias (Discovery), que servem de guia para o caminho a ser seguido. E é indicado para cenários e contextos voláteis.

Então "não", uma nova funcionalidade não é um novo produto e sim um projeto, um produto é algo maior que vai possuir durante seu Ciclo de Vida alguns projetos (novas funcionalidades).

5. Ciclo de vida de Produto:

Por fim quero aborda um ponto que acho relevante de se ter pelo menos o conhecimento básico sobre. O Ciclo de vida do produto este descreve todas as etapas pelas quais um produto passa dentro do mercado, desde seu lançamento até o seu fim por assim dizer.

Basicamente temos a fase Inovação que engloba desde o desenvolvimento do produto até sua entrada no mercado, onde seu foco inicial no mercado é buscar o Product Market Fit (Bem resumidamente são os clientes que se identificam com o produto), nessa etapa o perfil de usuário é composto por aqueles que são do grupo dos Inovadores (Pessoas que estão usando o produto apenas por ele ser novo ou por apenas querer somente testa-lo) e os do grupo de Primeiros Adeptos (São aqueles que realmente se identificam com o problema que o produto resolve logo de cara e servem muitas vezes como propagadores).

Temos também a fase Crescimento onde o foco é o Growth (Processo contínuo de crescimento do produto no mercado por meio de melhorias no produto, novas funcionalidades e otimização da experiência do usuário). Aqui temos dois grupos de usuários o que chamamos de Maioria Inicial que são aqueles que vem junto logo quando o produto começa a se popularizar no mercado e temos também a Maioria Tardia que são aqueles que chegam depois que o produto já se estabilizou e começou a se consolidar.

E por fim temos a fase de Maturidade aqui nosso produto já se consolidou, mantem uma boa base de clientes fieis e continua entregando valor, deste ponto ou o produto se mantem no mercado ou entra em Declínio.

No processo inicial de um produto logo após a chegada dos Primeiros Adeptos antes da Maioria Inicial, temos um Abismo onde muitos produtos morrem, por não conseguirem cruzar esse abismo. E temos também um abismo após a maturidade uma quarta fase que é quando o produto não consegue seguir inovando e não consegue mais agregar*"valor", que é a fase de *Descontinuar um produto ou Morrer, matar o produto, ou sunset.

6. Mas o que importa o Dev entender do ciclo de vida do produto?

Saber o ciclo de vida do produto pode te ajudar a entender em que fase o produto em que você vai estar trabalhando pode estar e o quanto de esforço e investimento será empregado em cada fase. O quanto o processo de Discovery será necessário para mapear novas funcionalidades e melhorias de fluxos. E o que pra mim faz bastante sentido que é saber quando você pode propor alguma melhoria, nova funcionalidade ou até mesmo a ideia de um novo produto!

Pois um Dev que tem capacidade de ajudar um produto crescer ou até mesmo a capacidade de propor um novo produto, sempre será um Dev diferenciado no mercado! (Claro quando esse tipo de atitude é valorizada)!!!

7. Conclusão:

Nesse artigo entendemos um pouco mais sobre produtos, o que impacta na vida do Dev entender sobre o assunto, a diferença entre um projeto e um produto e compreendemos um pouco sobre o ciclo de vida do produto.

Tudo isso para tentar ajudar você a ser um pouco mais um Dev Desenrolado, que tem uma visão mais macro do processo, que vai muito além do Código.

8. Se interessou?

Eu sou o Renan Vidal, trabalho como Product Owner já a algum tempo e agora estou estudando para migrar mais ainda para a área de produto, e com tudo que venho estudando e com toda experiencia que já tenho de mercado, e posso te dizer com alguma certeza que um Dev que se preocupa entender sobre Produtos e Regras de Negocio está na frente de muita, mas muita gente mesmo.

Espero que tudo que escrevi aqui tenha algum sentido para pelo menos uma pessoa, e no caso de duvidas ou se deseja que eu aborde algum tópico de produto mais aprofundada é só deixar seu comentário!

Métricas de qualidade de software na era da IA

Alicia Marianne Gonçalves — Thu, 16 Jul 2026 00:12:21 +0000

Não é novidade para ninguém que estamos passando por uma transformação na área de desenvolvimento de software, em que a IA está assumindo diversas atividades. E isso me faz pensar: o que vamos medir, ou o que teremos como parâmetro para qualidade de software daqui pra frente? É sobre isso que vou falar neste texto.

Antes das métricas: entenda o momento do seu time

Antes de entrarmos nas métricas em si, precisamos entender o momento em que o nosso time está. É muito fácil eu simplesmente jogar métricas aqui e você aplicá-las ao seu time de maneira automática — mas será que elas fazem sentido para o seu contexto?

Uma coisa que eu falo bastante aos meus alunos da mentoria que dou na He4rt Developers é: pra que eu quero isso? Softwares representam necessidades do mundo real, logo, medir o sucesso e a qualidade deles vai depender muito das necessidades que eles buscam suprir.

Partindo agora para as métricas, eu gosto de dividi-las em dois grupos:

Métricas para stakeholders
Métricas para o time

Qualidade de software não se resume a número de bugs — ela se aplica tanto em como o software é recebido pelo cliente final, quanto em como ele é desenvolvido.

Métricas para stakeholders

Uma coisa que eu aprendi neste tempo na empresa em que tenho atuado, principalmente com a transformação digital, é que mostrar número de bugs abertos ou resolvidos não mostra para o público o que realmente importa: como está a qualidade do produto. E, para me ajudar nisso, eu sempre tento me colocar no lugar de um cliente que não tem conhecimento profundo sobre o ciclo de desenvolvimento de software.

A primeira coisa que eu gostaria de ver quando um QA, ou o time, vier me mostrar os resultados de uma sprint ou de um quarter é: quantos problemas eu tenho em produção — mas não só isso, quanto tempo tenho levado para resolvê-los.

Mean Time to Resolve/Repair (MTTR)

Essa é a famosa métrica que vai mostrar o tempo que leva desde que o problema é identificado até ele ser resolvido em produção. Dependendo de como é o seu processo de desenvolvimento, isso pode ser medido de formas diferentes. Se você tem um processo em que o cliente primeiro reporta para o suporte, o suporte faz uma pré-avaliação e só depois disso o problema vai para o time resolver, você pode medir em dois momentos: o tempo que o suporte leva para avaliar o problema e dar um primeiro parecer, e o tempo em que esse ticket de suporte de fato se torna um bug e entra na esteira de resolução.

Cobertura de testes automatizados

Outra métrica interessante de se mostrar para um time de stakeholders é a quantidade de testes automatizados — porém, não isolada. Acho que você já deve estar cansado de ouvir que ter 99% de cobertura de testes não significa qualidade, mas como posso apresentar essa métrica ao stakeholder de forma que ele veja o valor do investimento em automação que o seu time está fazendo?

Uma coisa importante a analisar nesse contexto é se a cobertura de testes está realmente pegando os cenários importantes do sistema. Exemplo: se, no seu contexto, o seu MTTR está alto mas a sua cobertura de testes está alta, isso significa que a sua cobertura não está cobrindo o que realmente precisa ser coberto.

DORA Metrics

Além dessas, as DORA Metrics são grandes aliadas para auxiliar nesse diagnóstico.

As DORA Metrics (DevOps Research and Assessment, hoje parte do Google Cloud) nasceram para medir a performance de entrega de software, mas, na prática, funcionam como um termômetro da qualidade do processo como um todo — porque times que entregam rápido e com poucos incidentes são times com um pipeline de qualidade (testes, revisão, observabilidade) bem construído.

Fonte oficial: dora.dev — pesquisa contínua do DORA (Google Cloud) sobre as métricas e capacidades que diferenciam times de alta performance. Vale a leitura direta da fonte para acompanhar atualizações do modelo, como a inclusão de Reliability como quinta métrica.

Deployment Frequency (Frequência de Deploy)
Com que frequência o time coloca código em produção. Deploys menores e mais frequentes são mais fáceis de testar e, se algo der errado, mais fáceis de isolar a causa — menos mudanças acumuladas por deploy significa menos variáveis para investigar. Uma frequência de deploy caindo pode ser sintoma de um time com medo de quebrar produção, geralmente por falta de confiança nos testes.

Lead Time for Changes (Tempo entre o commit e a produção)
Tempo desde que uma mudança é commitada até ela estar rodando em produção. Um lead time alto muitas vezes esconde um gargalo em etapas de validação manual demoradas, ou retrabalho por bugs encontrados tarde no ciclo. É uma métrica que expõe se o teste está acontecendo cedo (shift-left) ou só no fim, represando a entrega.

Change Failure Rate (Taxa de Falha em Mudanças)
Percentual de deploys que causam falha em produção (incidente, rollback, hotfix). É, de longe, a métrica DORA mais diretamente ligada à qualidade do processo de teste. Está diretamente relacionada à cobertura de testes: se essa métrica está alta, significa que a sua cobertura de testes está baixa ou, como dito anteriormente, não está cobrindo o que realmente precisa ser coberto.

Time to Restore Service (Tempo de Restauração)
Tempo médio para restaurar o serviço depois de um incidente em produção (rollback, hotfix, correção de configuração). Mede a capacidade do time de reagir quando — não se — algo dá errado. QA pode influenciar diretamente essa métrica ajudando a desenhar testes de rollback, feature flags e smoke tests pós-deploy que aceleram a detecção e a decisão de reverter.

Reliability (Confiabilidade — métrica mais recente do modelo DORA)
O quanto o sistema atende às expectativas de disponibilidade e performance do usuário no dia a dia, não só durante incidentes. Conecta a qualidade percebida pelo usuário com o trabalho de teste não funcional (performance, disponibilidade) — é o lembrete de que qualidade não é só "não ter bug", é o sistema se comportar bem sob uso real.

Métricas para o time

As métricas para stakeholders ajudam bastante o time a ver o estado daquilo que estão produzindo, mas, às vezes, você quer enxergar a qualidade no próprio processo de desenvolvimento do software. Aqui podemos ter métricas mais pontuais.

Root Cause Analysis

São métricas que ajudam a ver os padrões dos problemas que acontecem no software ou durante o desenvolvimento e, a partir delas, pensar em planos de ação. Exemplo: se eu tenho muitos problemas relacionados a falta de requisitos, posso deixar os requisitos mais explícitos nas tarefas e, daqui a 2 ou 3 sprints, validar se esse tipo de root cause se tornou menos frequente ou não.

Bugs identificados antes do lançamento

Existem algumas métricas que você também pode extrair relacionadas a bugs, como: quantos bugs foram identificados antes mesmo de lançarmos a feature em produção? Isso pode ser alimentado tanto pela execução de testes manuais quanto por testes automatizados que falharam ao adicionar uma nova feature.

Retrabalho

É possível também calcular o retrabalho, uma métrica que vai te ajudar tanto a ver se o número de bugs está aumentando ou não quanto no planejamento. Quando o seu time costuma ter uma taxa de retrabalho de 10%, é possível alinhar com os Product Owners 10% de margem dentro de uma sprint para possíveis bugs. Assim, o planejamento se torna mais realista, as expectativas ficam alinhadas, e o cliente e o time ficam mais felizes.

Conclusão

Com essa transformação digital, é importante entendermos que temos métricas que podem nos auxiliar a medir o ciclo de desenvolvimento e a qualidade do produto — e o principal é que nenhuma delas, isoladamente, traz valor. Elas precisam ser lidas em conjunto, cruzadas entre si, e sempre voltando para aquela pergunta inicial: pra que eu quero isso?

Com a IA aumentando a produção de código, a tendência é termos mais código sendo escrito, mais features sendo entregues e mais decisões sendo tomadas em menos tempo. E é justamente por isso que medir vai se tornar ainda mais importante do que já é hoje: se antes um time levava dias para gerar uma quantidade de código que hoje pode ser gerada em horas, os erros também podem se multiplicar na mesma velocidade — só que muitas vezes invisíveis até chegarem em produção.

Por isso, acho que o papel do QA nesse novo cenário não é só testar mais rápido para acompanhar o ritmo da IA, mas também ser a pessoa que garante que estamos olhando para os números certos. Não adianta ganhar velocidade e perder visibilidade sobre o que está sendo entregue. Então, o convite que eu deixo é: olhe para essas métricas não como números para preencher um dashboard, mas como perguntas que elas estão te fazendo sobre o seu processo. E use a IA para te ajudar a responder essas perguntas mais rápido — não para substituir o hábito de perguntar.

Como escolher eventos de tecnologia para participar

vitoriazzp — Mon, 13 Jul 2026 17:45:47 +0000

Quando comecei a ir a eventos de tecnologia, estava na faculdade e ia a todos os gratuitos ou que custavam, no máximo, 100 reais. Porém, eu estava começando em TI e sabia tão pouco sobre a área em que eu queria atuar, logo qualquer evento despertava minha curiosidade.

Os anos passaram e eu me tornei frontend e passei a participar de eventos como front in (sampa, floripa, poa), TDCs, Roadsec (the mind sec) entre outros aí.

Por que ir a esses eventos?

Desde que comecei a fazer freelance e me formei, percebo que é onde eu descubro as tecnologias e os problemas que as pessoas têm percebido. Também é uma forma prática de eu sair da minha zona de conforto e conhecer pessoas, visões de mundo diferentes e voltar com ideias pros meus serviços.

Quando eu estava na faculdade, era muito mais simples ter essas duas "pontes" de comunicação e também de venda de solução. Após me formar e começar a trabalhar, percebi que a prospecção de clientes seria muito mais difícil se eu não estivesse nesses eventos.

Mas Vih, eu estou estudando, não estou mirando em freelance, do que me adianta ir?

Adianta que você conhece pessoas, faz amigos ou pessoas que vão te contratar ou indicar em trabalhos futuros. Além das palestras que podem te mostrar uma área dentro de TI que você ainda não conhecia e pode acabar gostando.

Como eu escolhia os eventos que iam fazer diferença pra mim?

1) Eu tinha uma lista de assuntos e áreas de que eu gostava ou que acompanhava já nas redes sociais, exemplo:

- frontend: flutter, react, html/css, boas práticas, realidade aumentada
- segurança da informação: hacks, boas práticas, curiosidades etc
- backend: qualquer stack pra se atualizar
- design ihc, ux, produto, estratégia, marketing

2) Seguia no Instagram as pessoas dessas áreas, que às vezes eram as mesmas que participavam dos eventos, por exemplo:

@juliallabs
@stherzada
@danielhe4rt
@spacecoding
@nataliafdev
@omarcusdev
@dessadev

Esses são alguns dos exemplos que eu mais acompanhava no Instagram, algumas pessoas também têm perfil nesta plataforma, mas o conteúdo sobre eventos está no Insta!

3) Tinha uma noção do custo de alguns eventos, e quais eu podia arcar, quais eu precisava pra me atualizar ou fazer networking específico:

Conferências até R$ 1.500;
Eventos/meetups de R$ 0 a 600; > Ter a meia-entrada ou o ingresso solidário ajudava a pagar menos; às vezes, a faculdade ou o emprego pagava a entrada em troca de trazer o conteúdo aplicado. Vale consultar a disponibilidade pra economizar.

Mas qual a diferença entre conferência, eventos, meetups?

Conferência costuma ser um evento amplo; faz-se pra apresentar conteúdos específicos, e o público costuma ser de empresas que levam o funcionário ou de pessoas que já estão no mercado e conseguem arcar com o custo do ingresso.
Eventos podem ser pagos ou gratuitos; costumam ser organizados por empresas, mas às vezes comunidades também.
Meetups são frequentemente organizados por comunidades e podem ou não ter custo; depende do lugar em que acontecem.

Onde eu posso achar eventos de tecnologia?

Existem os sites de venda de ingresso como

Summits são mais voltados para empresas ou empreendedores; os valores são bem altos, mas consegue desconto dependendo da tua empresa ou faculdade. Vale a pena se pretende atuar em algum setor muito específico.