Checklist dev: como preparar o setup antes de voltar a programar

Setembro chegou e, com ele, aquele ritual que todo dev conhece bem: retomar o ritmo. Mas antes de abrir o VS Code ou rodar o git pull na branch principal, vale parar e fazer uma auditoria nos seus dispositivos. Segundo o Sapo.pt, dados internos da iServices mostram que pedidos de transferência de dados entre smartphones e tablets cresceram 69% no primeiro semestre de 2026, enquanto intervenções em computadores saltaram 71%. Não é coincidência — é a realidade de quem vive entre terminais, IDEs e três monitores.

Por que devs precisam de uma checklist de “volta às aulas”

Na minha experiência, o maior gargalo de produtividade raramente é a linha de código em si. É o ambiente. Quando volto de férias e ligo o notebook, descubro que o WSL está desatualizado, o Docker quebrou uma imagem, o ssh-agent esqueceu as chaves e três extensões do VS Code geram conflito. Antes de reclamar do computador lento, é preciso entender o que realmente importa para quem programa.

Um equipamento para dev não é só “ligar e funcionar”. Ele precisa rodar um editor pesado, containers, emuladores, múltiplas abas do Chrome (cada uma consumindo 300MB fácil), um servidor local e, em alguns casos, uma VM completa. A conta de RAM fecha rápido. Por isso, mais importante que pensar em trocar de máquina é otimizar o que você já tem.

Diagnóstico real: o que checar antes de tudo

A iServices recomenda cinco pontos clássicos — espaço, sistema, apps, ficheiros e bateria — e eu concordo com todos. Mas para devs, eu adicionaria mais três que costumo aplicar no meu próprio setup:

• Estado do SSD/HDD: rodar um smartctl -a /dev/nvme0n1 (Linux) ou CrystalDiskInfo (Windows) para ver a saúde do disco. SSDs acima de 90% de uso degradam performance significativamente.
• Saúde da bateria: no Linux, upower -i /org/freedesktop/UPower/devices/battery_BAT0 mostra a capacidade atual vs. a de fábrica. Se estiver abaixo de 80%, considere trocar antes que ela te deixe na mão no meio de um deploy.
• Configurações sincronizadas: Git configs, dotfiles, SSH keys e preferências de IDE precisam estar replicados corretamente.

O script que eu rodo todo início de semestre

Criei um script bash que faz um diagnóstico rápido e me avisa o que precisa de atenção. Funciona em qualquer Linux ou macOS com bash:

#!/bin/bash
# dev-back-to-school.sh — auditoria rápida de setup

echo "=== ESPAÇO EM DISCO ==="
df -h / | awk 'NR==2 {print "Uso: "$5" | Disponível: "$4}'

echo "=== MEMÓRIA ==="
free -h | grep Mem

echo "=== SAÚDE DO SSD (se NVMe disponível) ==="
if command -v smartctl &>/dev/null; then
  sudo smartctl -H /dev/nvme0n1 2>/dev/null | grep -E "SMART|result"
else
  echo "smartctl não instalado — instale com: sudo apt install smartmontools"
fi

echo "=== BATERIA ==="
if command -v upower &>/dev/null; then
  upower -i /org/freedesktop/UPower/devices/battery_BAT0 2>/dev/null | grep -E "capacity|state"
fi

echo "=== ATUALIZAÇÕES PENDENTES ==="
if command -v apt &>/dev/null; then
  apt list --upgradable 2>/dev/null | wc -l | xargs echo "Pacotes apt atualizáveis:"
fi

echo "=== FERRAMENTAS CRÍTICAS ==="
for cmd in git node docker python3 go rustc; do
  if command -v $cmd &>/dev/null; then
    echo "$cmd: $($cmd --version 2>&1 | head -n1)"
  else
    echo "$cmd: NÃO INSTALADO ⚠️"
  fi
done

Rode com chmod +x dev-back-to-school.sh && ./dev-back-to-school.sh. Em cinco segundos, você sabe exatamente o estado real do seu ambiente.

Estratégia de migração de dados que realmente funciona

Transferir fotos e contactos é o básico. Para devs, o verdadeiro tesouro está em outro lugar:

• Repositórios: nunca confie só em uma cópia local. Garanta que tudo está no GitHub, GitLab ou Bitbucket antes de qualquer wipe.
• Dotfiles: versione seus .zshrc, .gitconfig, .tmux.conf e configs de IDE em um repositório dedicado. Eu uso um padrão chamado “dotfiles repo” há anos e me salvou incontáveis vezes.
• Chaves SSH: gere um par novo por dispositivo, adicione ao ssh-agent e cadastre a pública no GitHub. Nunca copie a mesma chave privada entre máquinas — é um risco de segurança real.
• Banco de dados local: se você roda PostgreSQL ou MongoDB local, faça pg_dump ou exporte os dados antes de reinstalar o sistema.

Sincronizando o VS Code entre máquinas

Se você usa VS Code como eu, o Settings Sync é obrigatório. Ative em File > Preferences > Settings Sync e tudo — extensões, configurações, keybindings, snippets e até o estado da UI — fica sincronizado via sua conta Microsoft ou GitHub. Acabei de configurar isso em um notebook novo e, em menos de dois minutos, todo o ambiente estava idêntico ao antigo.

Segurança: o que devs esquecem sempre

Esse é o ponto onde mais vejo erro. Quando o foco é “voltar a funcionar”, a segurança vira prioridade secundária. Mas devs lidam com tokens de produção, chaves de API e acesso a servidores. Não dá para vacilar.

• Gerenciador de senhas: 1Password, Bitwarden ou KeePassXC. Nada de salvar senhas no Chrome sem criptografia forte — já vi devs perderem acesso a repos por isso.
• 2FA obrigatório: habilite autenticação em duas fatories em GitHub, AWS, GCP, Docker Hub e qualquer registry que você usa.
• Tokens de sessão: revise os tokens ativos no GitHub (Settings > Developer Settings > Personal Access Tokens) e revogue o que não usa mais.
• Higienização física: os 53% de aumento em pedidos de limpeza de smartphones que a iServices reportou fazem sentido — keyboards e telas cheias de gordura interferem na digitação e na visibilidade do código em ambientes escuros.

Na prática: checklist definitivo para devs voltando às aulas

1. Backup: git status em todos os projetos ativos, pg_dump nos bancos, snapshot da pasta ~/.ssh (com criptografia).
2. Diagnóstico: rode o script acima. Anote o que está crítico.
3. Sistema: atualize o SO primeiro, depois o kernel se for Linux, e só então as ferramentas de dev. Reiniciar entre cada etapa evita conflitos.
4. Ferramentas: reinstale Node, Python, Docker, Go ou Rust via gerenciador de versão (nvm, pyenv, gvm, rustup). Nunca use a versão do sistema.
5. IDE: restaure o Settings Sync, reinstale extensões críticas (GitLens, Docker, ESLint, Prettier, Remote SSH).
6. SSH e Git: gere chaves novas, configure ~/.ssh/config com aliases para servidores frequentes.
7. Teste de stress: rode uma compilação pesada (projeto React ou Rust mediano) e monitore temperatura e consumo de bateria. Se o notebook desligar por throttling, a pasta térmica precisa de limpeza.

Erros comuns que vejo acontecer todo ano

• Atualizar tudo de uma vez: se uma atualização quebra o ambiente, você não sabe qual foi. Vá por camadas.
• Ignorar a bateria: devs esquecem que rodar Docker, Chrome e VS Code simultaneamente derruba autonomia em 2-3 horas. Se o notebook não aguenta uma aula inteira, o problema é a bateria, não o processador.
• Comprar máquina nova prematuramente: 90% das vezes, uma limpeza de storage, reinstalação limpa do SO e troca de bateria resolve. Antes de gastar R$ 8 mil num novo, faça o básico.
• Não versionar dotfiles: esse é o erro clássico. Sem dotfiles versionados, você recria o ambiente do zero toda vez. Isso custa horas.
• Migrar SSH keys entre dispositivos: perigoso. Cada máquina deve ter sua chave.

Quando o problema é hardware de verdade

Se mesmo após toda otimização o notebook continua lento, provavelmente:

Antes de pensar em máquina nova, tente essas quatro. Na minha experiência, um upgrade de RAM + SSD recupera 80% da percepção de performance.

FAQ — Perguntas que devs realmente fazem

Vale a pena migrar para SSD NVMe se meu notebook ainda usa SATA?

Vale, sim. A diferença de boot e de leitura de projetos é brutal — de 5x a 10x mais rápido em acessos aleatórios. É o upgrade com melhor custo-benefício que existe para qualquer dev.

Como sincronizar configurações do terminal entre Windows, macOS e Linux?

Use o Starship como prompt e versione tudo num repositório de dotfiles. O brew também funciona em Linux e macOS, o que unifica a instalação de pacotes.

É seguro usar o mesmo gerenciador de senhas em vários dispositivos?

Sim, desde que seja um gerenciador com criptografia ponta-a-ponta (Bitwarden, 1Password, KeePassXC). O segredo é nunca esquecer a senha mestra e ter 2FA habilitado na conta.

Quanto de RAM é suficiente para dev em 2026?

16GB é o mínimo absoluto se você roda Docker, IDE e browser. 32GB é o sweet spot confortável. Se trabalha com VMs ou compilações pesadas (Rust, C++, ML), vá direto para 64GB.

Devs devem se preocupar com limpeza física dos equipamentos?

Devem. Poeira na saída de ar é a causa número 1 de throttling. Um notebook que aquece demais reduz clock da CPU para se proteger — o que destrói a performance de compilação. Limpeza a cada 6-12 meses é o ideal.

No fim das contas, voltar às aulas (ou ao trabalho pós-férias) não é só sobre comprar equipamento novo. É sobre garantir que o que você já tem está afinado, seguro e sincronizado. Os números da iServices que o Sapo.pt publicou mostram que isso vale para 100% dos usuários — mas para devs, onde cada minuto de build conta, vale ainda mais.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.