Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
Tem hora que uma mudança técnica não parece tão grande assim.
Aí ela entra no fluxo real de um time e muda a conversa inteira.
No caso de node.js, o ponto não é só se a ideia é boa. A pergunta melhor é outra: o que fica mais difícil de manter quando todo mundo começa a usar isso como atalho?
---
A parte sedutora é sempre a mesma: mais velocidade, menos atrito, uma sensação de que o time finalmente saiu do lugar.
Só que velocidade sem critério costuma cobrar juros.
Às vezes aparece no review. Às vezes no suporte. Às vezes seis meses depois, quando ninguém lembra por que aquela decisão foi tomada.
---
Eu não começaria perguntando se a ferramenta é boa.
Perguntaria onde ela quebra.
Quem revisa? Quem opera? O que acontece quando o resultado parece certo, mas está só bem escrito? E quanto tempo o time leva para voltar atrás se perceber que comprou uma complexidade nova?
Essa é a parte menos bonita da discussão. E provavelmente a mais útil.
Mais do que novidade, vale observar o que deixa uma ideia facil de testar, citar, explicar e manter quando ela sai da apresentacao e entra na rotina.
Eu levaria isso como um lembrete simples: antes de comprar velocidade, olha quem segura a manutenção depois.
No meu time eu tentaria achar onde teste pequeno entra no fluxo real. Sem esse recorte, fica fácil vender ganho e esquecer manutenção.
👍
Se o time tivesse que medir uma coisa aqui, seria manutenção ou risco em produção?
aham, ajudou pra cacete quando o time mede o antes e depois. Sem isso, vira só sensação boa de demo.
Eu levaria para um piloto bem limitado. Se risco não melhorar sem piorar risco em produção, melhor parar cedo.
teste pequeno e risco em produção precisam aparecer nessa conta
real, pra mim isso depende muito de quem vai cuidar quando sair do post e virar rotina do time.