鏡O Espelhovinte perguntas pra olhar o próprio código

Olhe primeiro o que está nas suas mãos.

Cinco perguntas sobre o projeto que você abriu agora. Responda em voz alta — quem mente pra si mesmo nunca afia nada.

1. 01

   Qual é a UMA coisa que seu produto faz?

   Se você precisar de duas frases, ele já faz duas coisas. Cuidado.

2. 02

   Você consegue explicar a arquitetura em uma única frase?

   Se a frase começa com "depende", a arquitetura já está overengineered.

3. 03

   Quanto tempo do git clone até a primeira execução?

   Mais de cinco minutos é dívida técnica não amortizada — e o novo dev já desistiu.

4. 04

   Quantos arquivos de configuração existem na raiz?

   Você entende o que cada um faz, sem consultar a internet?

5. 05

   Se você sumir amanhã, quem mantém isso?

   Se a resposta sincera é "ninguém", então você é a impureza — e o projeto não sobrevive a você.

A pilha que você não escolheu, mas carrega.

Cada lib é um pedaço de aço importado. Algumas justificam o peso. Outras estão lá porque alguém empurrou e ninguém parou pra desempurrar.

1. 01

   Quantas deps no package.json? Quantas você realmente usa?

   A diferença é o seu débito invisível — bytes pra rede, tempo pra build, superfície pra CVE.

2. 02

   Tem alguma dependência que sobrou depois que a feature foi cortada?

   Cemitério de imports é o segundo maior tipo de impureza — só perde pra código morto.

3. 03

   Tem ferramenta resolvendo problema que outra ferramenta da pilha já resolve?

   Webpack + esbuild. Lodash + métodos nativos. Axios + fetch. Moment + Date. Pague-se um café e arruma isso.

4. 04

   Você consegue rodar npm install offline e o build passar?

   Se não, sua stack está pendurada num CDN que pode cair amanhã.

5. 05

   Quanto da bundle final é dependência vs código seu?

   Geralmente 90/10 a favor das deps. Pense por quê — e o que daria pra cortar.

O que você sabe que está errado e finge que não vê.

Toda base de código carrega impurezas conhecidas. O dev maduro é quem aponta o dedo pras suas próprias antes de alguém apontar.

1. 01

   Qual feature dos últimos seis meses ninguém usa?

   Você sabe a resposta. Tem coragem de cortar?

2. 02

   Tem código que você tem medo de tocar há mais de um ano?

   Medo é o sintoma — impureza acumulada é a doença.

3. 03

   Tem abstração criada pensando em "necessidades futuras" que nunca chegaram?

   DRY prematuro é overengineering disfarçado de boa prática. Três linhas iguais é melhor que uma fábrica errada.

4. 04

   Tem duplicação que você sabe que existe mas nunca consolidou?

   Três cópias da mesma coisa fingindo ser três coisas — esperando você reconhecer.

5. 05

   Quantos comentários "TODO: refactor later" o repo tem?

   Roda um grep agora. "later" significa "nunca" em qualquer base de código com mais de seis meses.

A disciplina que decide se a lâmina endurece ou enferruja.

Construir todo dia é fácil — qualquer iniciante consegue. Forjar exige coragem de tirar. Coragem é hábito; hábito é tempo agendado.

1. 01

   Quando foi a última vez que você deletou código?

   Não foi escrevendo — foi apagando. Se faz mais de duas semanas, a forja está fria.

2. 02

   Você tem coragem de remover a feature mais antiga se ninguém a usa?

   Tem ou não tem. Sentimentalismo técnico custa em manutenção.

3. 03

   Você tem coragem de trocar a stack se a atual já não serve mais?

   Lealdade à ferramenta é vaidade disfarçada. A lealdade certa é com o problema.

4. 04

   Você sabe quando o projeto está pronto, ou só empilha pra sempre?

   Se a resposta é "nunca está pronto", o projeto está te dirigindo, e não o contrário.

5. 05

   Quanto do seu tempo é forja vs construção?

   Boas lâminas exigem tempo igual nas duas. Quem só constrói acumula impureza. Quem só forja não entrega.

— epílogo do aprendizSe você respondeu mentalmente "não sei" pra mais de cinco perguntas dessas, o próximo passo não é adicionar nada. É abrir o repositório e cortar.

A recompensa não é fama. É dormir.