"Não preciso saber estruturas de dados para programar"
Se você já disse essa frase, parabéns! Você faz parte da geração que acredita que programar é só juntar bibliotecas, copiar código do Stack Overflow e esperar que tudo funcione por mágica. Mas a realidade é dura: se você não entende estruturas de dados, você não programa – você apenas escreve código.
O básico que (quase) ninguém quer aprender
Claro, você pode criar aplicações sem saber o que é uma árvore AVL, um heap binário ou um grafo direcionado. Mas eventualmente você vai se deparar com um problema onde um simples for loop não resolve e, adivinhe? Você não vai saber por onde começar.
Se você não entende como funciona uma lista ligada, por que raios está escolhendo entre um ArrayList e um LinkedList no Java? Se não sabe a diferença entre busca binária e busca linear, como vai otimizar suas consultas no banco? Se nunca estudou tabelas hash, como espera lidar com caches eficientes?
O código que você escreve poderia ser melhor
O que acontece quando alguém que "não precisa saber estruturas de dados" tenta resolver problemas complexos? O código vira um pesadelo de loops aninhados, consumo de memória desnecessário e processamento absurdo. No final, alguém mais experiente terá que refatorar tudo para não explodir o servidor em produção.
E não precisa ser algo super avançado. Quer um exemplo básico? Aqui estão duas formas de buscar um item em uma lista:
Método de quem "não precisa saber estruturas de dados"
lista = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
alvo = 7
for item in lista:
if item == alvo:
print("Encontrado!")
Método de quem sabe o básico
lista = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
alvo = 7
if alvo in set(lista):
print("Encontrado!")
O segundo código converte a lista em um conjunto (set), tornando a busca O(1) em vez de O(n). Se você não sabe o que isso significa, aí está o problema.
"Mas eu sou desenvolvedor frontend, não preciso disso!"
Ah, sim. Porque interfaces modernas não precisam manipular grandes volumes de dados, certo? Então por que bibliotecas como React, Vue e Svelte se preocupam tanto com renderização eficiente, atualização de estado e manipulação otimizada do DOM? Você pode até não escrever árvores de busca no dia a dia, mas garanto que saber como funciona um Virtual DOM ou um diffing algorithm vai tornar você um desenvolvedor frontend muito melhor.
Conclusão
Você pode até programar sem entender estruturas de dados profundamente, mas isso significa que sempre dependerá de ferramentas que outras pessoas criaram. Seu código será mais lento, menos eficiente e, quando surgirem problemas reais, você não saberá como resolvê-los.
Então, pare de fugir do aprendizado. Você não precisa se tornar um cientista da computação, mas se quer ser um programador de verdade, aprender estruturas de dados é o mínimo que se espera. Simples assim.
Se o custo de criar o set é O(n), não faz sentido criar um set para fazer uma busca, ainda mais falando sobre uma lista de 10 elementos.
Faz sentido sugerir estudar estrutura de dados, mas é preciso usar exemplos melhores para mostrar a utilidade.
Já falaram isso mas acho importante reforçar: O código de exemplo dado no post é ruim. Na verdade a sua alteração piora a performance ao invés de melhorar.
Concordo plenamente com a mensagem do post, de qualquer forma. Mas toma cuidado que entre a loucura e a genialidade existe uma linha tênue. Você parecia muito confiante que o exemplo que você escreveu era de fato uma melhoria e de fato o código ficou mais performático, quando na verdade é exatamente o oposto e tecnicamente o código ficou "pior".
Dica: Confiança demais cega.
Inclusive, coincidentemente, hoje eu postei um artigo sobre otimização de código no TabNews. Com poucos minutos de diferença da sua publicação, a propósito kkkk.
Se você tem interesse em aprender sobre otimização de código, eu sugiro a leitura:
Eu sugiro que leia o artigo e cuidado ao acreditar nestas supertições sobre otimização de código. É bem comum eu ver gente acreditando nestas coisas e piorando a performance do código enquanto acredita que está "otimizando" ele.
Todo mundo falando que o exemplo é ruim (de fato é). Vou dar um exemplo real.
Numa determinada rotina tinha algo assim (java):
if (!codigos.contains(codigo)) {
codigos.add(codigo);
rotina(codigo);
}
A questão é que códigos acima era um List. Trocamos por um HashSet e o codigo final ficou
if (codigos.add(codigo)) {
rotina(codigo);
}
Ou seja, se add retornar true é porque o elemento não existia no set e foi adicionado então podemos rodar a rotina. Como tinha bastante elementos a diferença foi muito perceptível.
Bom, já que é assim. Quais estruturas de dados você acredita que são as mais importantes para um desenvolvedor aprender?
Concordo que o segundo codigo tem um melhor desempenho em relação ao primeiro, apesar de ambos serem codigo bem simples e que é imperceptível a diferença em ambos, contudo se aumentamos o grau de ficiculdade poderemos então contastar isso. Basta realizar a mesma tarefa com tres listas e três alvos diferente com o intuito de verificar se os três alvos estão nas três lista simultaneamente e poderemos notar o quanto diferente será a performace dos dois codigos. Enquanto o primeiro realizará a dura tarefa de: O(n) x O(n) x O(n) que no caso da listas possuir 10 elementos estaríamos falando de até 1000 interações o segundo realizara a tarefa de O(n) + O(n) + O(n) que no caso da listas possuir 10 elementos estaríamos falando de apenas 30 interações isso claro levando em conta que a conversao da lista em set lhe custe um O(n). O que nos leva a conclusão de que mesmo que haja um custo na conversão da lista para set ela será muito util para um melhor desemepnho ao realizar a busca.
Excelente! Só uma observação:
O tamanho da lista importa quando estamos criando um algoritmo de pesquisa ou manipulação de estruturas de dados.
Recentemente complementei meus estudos em java sobre testes de desempenho e eficiência sobre o uso de LinkedList e ArrayList. Percebi que a disparidade entre ambos é grande conforme seus tamanhos aumentam.
ArrayList geralmente é o melhor pra maioria dos cenários, mas o consumo de memória é terrivel, pois um ArrayList cresce exponencialmente, mas nao diminui na mesma proporção que cresce quando você remove itens, e isso o torna muito grande e lotado de espaços vazios.
Mas, de qualquer forma, estruturas de dados é um tema pra quem realmente gosta, não pra entusiastas da programação que acham que o código trabalha sozinho como um quebra cabeças, sem precisar de intervenção constante e excessiva da mente humana. É um tema que eu particularmente tenho muito apreço.
SIM É IMPORTANTE SABER OS FUNDAMENTOS, DITO ISSO....
Na teoria, você está certo, mas, na prática, as pessoas que você afirma não saber programar estão empregadas, trabalhando diariamente e recebendo seus salários. Enquanto isso, as empresas que contratam esses profissionais continuam faturando milhões com a venda de seus softwares e soluções tecnológicas.
Enquanto você se estressa com essa situação, essas empresas seguem prosperando e expandindo seus negócios, muitas vezes sem se preocupar com a perfeição do código, mas sim com os resultados que ele proporciona. No final das contas, o que realmente importa para as empresas é o lucro, e para os usuários, a entrega de valor.
Se a solução foi desenvolvida com inteligência artificial, low-code, no-code, C#, Python, PHP, Delphi ou até mesmo Assembly, isso pouco importa para o cliente final. Da mesma forma, se a implementação usou dicionários ou listas, esse detalhe técnico não faz diferença para quem está consumindo o produto. No fim das contas, tudo gira em torno da entrega de valor e da resolução de problemas, não necessariamente da pureza do código ou da tecnologia utilizada.
list já é uma estrutura de dados.