Executando verificação de segurança...
5
mateussiilva
2 min de leitura ·

Você é programador ou apenas um montador de blocos?

Nos últimos anos, programar deixou de ser sobre resolver problemas e passou a ser um jogo de encaixar bibliotecas e frameworks. A nova geração de desenvolvedores acredita que basta instalar meia dúzia de pacotes do NPM, importar tudo no código e pronto: temos um sistema funcionando. Mas será que isso é realmente programar?

O vício em bibliotecas

Hoje em dia, para fazer qualquer coisa, tem sempre alguém sugerindo uma biblioteca:

  • Precisa fazer uma requisição HTTP? Instala Axios!
  • Precisa formatar uma data? Instala Moment.js! (mesmo ele estando obsoleto)
  • Precisa somar dois números? Tem uma lib no NPM pra isso!

E o resultado? Projetos gigantes, com milhares de dependências, consumindo recursos de forma absurda e, pior ainda, cheios de vulnerabilidades de segurança porque ninguém sabe o que realmente está rodando por trás.

A dependência cega em ferramentas

Não me entenda mal: bibliotecas e frameworks existem para acelerar o desenvolvimento e evitar retrabalho. O problema é quando o desenvolvedor se torna completamente dependente delas. Você já viu código assim?

import _ from 'lodash';

const array = [1, 2, 3, 4, 5];
const firstElement = _.first(array);
console.log(firstElement);

Sério? Precisava importar o Lodash só para pegar o primeiro elemento de um array? Isso aqui faz a mesma coisa:

const array = [1, 2, 3, 4, 5];
console.log(array[0]);

Menos código, menos dependências, menos problemas. Mas parece que muita gente desaprendeu a lógica de programação e só sabe copiar e colar código pronto sem entender o que está acontecendo.

Quando tudo quebra

Outro grande problema desse vício em bibliotecas é que, quando algo dá errado, poucos sabem como resolver. O que acontece quando o NPM remove um pacote essencial? Ou quando uma atualização quebra o projeto inteiro porque ninguém sabia o que aquela dependência realmente fazia?

Quem não lembra do desastre do left-pad, onde um pacote de apenas 11 linhas foi removido do NPM e quebrou milhares de projetos pelo mundo? Isso aconteceu porque desenvolvedores estavam usando uma biblioteca para algo que poderia ser resolvido com uma simples função nativa.

O que significa ser um programador de verdade?

Programar não é apenas montar blocos e colar bibliotecas no código. Programar é entender problemas, pensar em soluções eficientes e escrever código limpo e performático. Se a primeira coisa que você faz ao iniciar um projeto é procurar quais bibliotecas vai usar antes mesmo de entender os requisitos, você não está programando – está apenas montando um quebra-cabeça.

Então, da próxima vez que for instalar mais uma biblioteca para algo trivial, pare e pense: será que eu realmente preciso disso?

Porque no final do dia, a pergunta é simples: você é um programador ou apenas um montador de blocos?

Carregando publicação patrocinada...
2
saraiva

Tu pegou mesmo essa missão, hein? kkkkkkk

Nos últimos posts eu discordei, mas esse aqui eu tenho que admitir que tô 90% de acordo.
no entanto os 10% que nao concordo é que isso nao deixa de tornar a pessoa um programador, pois pra mim um programador é quem sabe escrever algum codigo que fale com a maquina e mesmo com a lib ele vai precisar. talvez ele ainda seja junior, mas mesmo assim é um programador

No meu time, usar uma lib não é algo que acontece por impulso — tem que ter um motivo muito bem justificado. Eu prefiro gastar tempo ensinando a equipe a fazer algo de forma nativa do que aprovar um PR que adiciona uma dependência desnecessária, tipo uma lib só pra fazer requisição HTTP.

Antes de decidir se vamos ou não usar uma biblioteca, eu sempre faço algumas perguntas essenciais:
1. Fazer nativo realmente dá tanto trabalho assim a ponto de justificar a lib?
2. A lib vem de um fornecedor confiável?
3. Se não for de um fornecedor conhecido, pelo menos tem repositório no GitHub?
• E tu chegou a olhar o código? Porque né, baixar qualquer coisa sem revisar pode ser um baita tiro no pé. Já vi muita gente instalando dependência sem nem saber que tava trazendo código malicioso junto.

Se, depois dessa análise, ainda fizer sentido usar a lib, beleza, a gente segue esse caminho. Mas, sinceramente, hoje em dia tá cada vez mais raro precisar. As ferramentas nativas evoluíram muito, e muitas vezes dá pra resolver tudo sem depender de terceiros.

Agora, se tem uma área onde eu costumo abrir uma exceção, é na hora de gerar gráficos para dashboards. Se for só um gráficozinho simples, eu já fiz até com div (não me julguem, kkkkkkk), embora eu saiba que um canvas faria mais sentido. Mas quando o negócio envolve vários tipos de gráficos diferentes, aí sim eu recorro a uma biblioteca, porque reinventar a roda nesses casos não vale a pena.

Resumindo: lib só quando realmente precisa. O resto, a gente resolve na mão e aprende no processo.

1
mateussiilva
Autor
Autor

Finalmente, um comentário que vale a pena responder. Concordo contigo nos 90%, e nos outros 10%, acho que a diferença é só semântica. Sim, qualquer um que escreve código é, tecnicamente, um programador. Mas a questão aqui não é colocar um rótulo, e sim diferenciar quem entende o que está fazendo de quem só junta pedaços de código sem saber como funcionam.

Sobre o uso de libs, perfeito: justificar antes de adicionar dependências deveria ser regra em todo time sério. Tem muito dev que acha que produtividade é só colar pacotes prontos e sair rodando, mas esquece que cada dependência é um potencial problema de segurança, um ponto de falha e uma dor de cabeça futura. A gente já tem um software inteiro rodando no npm com 500MB de dependências só pra mostrar um "Hello, World!" — precisa de mais prova?

Agora, sobre gráficos: faz sentido abrir exceção. Frameworks de visualização são um caso clássico onde vale mais a pena usar algo pronto do que tentar reimplementar um D3.js do zero. Mas o ponto é exatamente esse: saber onde a abstração faz sentido e onde ela só complica. Quem entende como funciona por baixo sempre vai fazer escolhas melhores do que quem só instala o pacote da moda sem pensar.

Resumindo: se todo mundo tivesse esse critério antes de encher o projeto de dependências, metade dos bugs e exploits de hoje nem existiriam.

2
saraiva

Legal, agora uma curiosidade, responda apenas se quiser claro.

Porque todo essa raiva? aconteceu algo?

Não sei se tu é novo ou não, mas esse tipo de postagem não vai mudar em nada e talvez gere até hate. Talvez uma abordagem mais didática explicando os perigos de usar libs as pessoas estarão mais abertas a ouvir/ler, agora do jeito que está, muitos vão ler as primeiras linhas e guspir ofenças ou discordancias.

A vida é tua, o tempo é teu e a missão de tentar mudar as coisas também, não entenda esse comentário especifico como uma critica a você, mas o ditado (agua mole, pedra dura, tanto bate até que fura) não acredito que funcione com o ser humano. O ser humano é mais facil manipular do que tentar a força mostrar algo.

1
mateussiilva
Autor
Autor

Hahaha, pode crer! Quando o assunto é programação, eu realmente passo um pouco do ponto 😂. É que eu gosto tanto dessa área que, às vezes, vejo certas coisas acontecendo e bate aquela vontade de gritar "NÃO, POR FAVOR, NÃO FAÇA ISSO!" haha. Mas é tudo na paixão mesmo, nada pessoal.

Entendo o que você quis dizer sobre a abordagem. No calor do momento, a gente acaba soltando as coisas sem filtro, mas no final das contas, a melhor forma de convencer alguém é com paciência e um bom argumento, não só com a indignação. Vou tentar segurar a emoção na próxima... ou pelo menos fingir que seguro! 😆

Valeu pelo toque, de verdade! Sempre bom ter alguém pra dar esse tipo de perspectiva.

1