DEV Community

pcgustavo7
pcgustavo7

Posted on Edited on

Bibliotecas (Lib): entendendo o que são e como usamos no desenvolvimento

Afinal, o que é uma biblioteca? Por que usamos npm install? E qual é a diferença entre uma biblioteca e um framework?

Se você está começando a programar, provavelmente já encontrou coisas como:

npm install axios
Enter fullscreen mode Exit fullscreen mode

ou:

import React from 'react';
Enter fullscreen mode Exit fullscreen mode

Talvez também já tenha visto alguém falando:

"Essa aplicação utiliza algumas libs."

Mas o que exatamente significa isso?

Neste artigo, vamos entender o que é uma biblioteca (library ou lib), por que ela existe, como podemos utilizá-la em nossos projetos e qual é a diferença entre uma biblioteca, um framework e um código que nós mesmos escrevemos.


1. O problema: precisamos reinventar tudo?

Imagine que você esteja desenvolvendo um sistema.

Em determinado momento, você precisa:

  • formatar datas;
  • fazer requisições HTTP;
  • validar e-mails;
  • criar gráficos;
  • trabalhar com arquivos;
  • gerar PDFs;
  • criptografar informações;
  • manipular imagens.

Uma possibilidade seria escrever tudo do zero.

Mas será que isso faz sentido?

Imagine precisar criar manualmente uma função de validação de e-mail:

function validarEmail(email) {
  // dezenas de regras...
}
Enter fullscreen mode Exit fullscreen mode

Agora imagine que você precise implementar dezenas de outras funcionalidades.

O projeto rapidamente ficaria enorme.

É justamente nesse tipo de situação que as bibliotecas se tornam úteis.


2. Afinal, o que é uma biblioteca?

Uma biblioteca (library ou lib) é um conjunto de códigos reutilizáveis criado para resolver determinados problemas ou fornecer funcionalidades que podem ser utilizadas dentro de outros programas.

Em vez de desenvolver determinada funcionalidade do zero, podemos utilizar algo que já foi implementado.

Uma maneira simples de visualizar:

                 NOSSO PROJETO
                      |
          +-----------+-----------+
          |           |           |
          v           v           v
       Código      Código       Código
       próprio     próprio      próprio
          |
          +----------------------+
                                 |
                                 v
                           BIBLIOTECA
                                 |
                     +-----------+-----------+
                     |           |           |
                     v           v           v
                  Função      Função      Função
                  pronta      pronta      pronta
Enter fullscreen mode Exit fullscreen mode

A biblioteca fornece "peças" que podemos utilizar para construir nossa aplicação.


3. Uma analogia simples

Imagine que você queira construir um carro.

Você poderia fabricar absolutamente tudo:

  • rodas;
  • pneus;
  • parafusos;
  • banco;
  • volante;
  • motor;
  • vidro;
  • sistema de freios.

Seria possível?

Em teoria, sim.

Mas seria extremamente trabalhoso.

Na prática, você utiliza componentes que já foram produzidos.

O desenvolvimento de software segue uma ideia parecida.

Em vez de criar tudo do zero, podemos utilizar componentes e funcionalidades que já existem.

Uma biblioteca é como uma caixa de ferramentas pronta: você escolhe as ferramentas necessárias e utiliza dentro do seu próprio projeto.


4. Biblioteca não é código mágico

Uma coisa importante para quem está começando:

Uma biblioteca não "faz tudo sozinha".

Ela é apenas código.

Código escrito por outras pessoas que foi organizado de forma que outros desenvolvedores possam reutilizá-lo.

Por exemplo:

const resultado = somar(10, 20);
Enter fullscreen mode Exit fullscreen mode

A função somar() poderia ter sido criada por nós:

function somar(a, b) {
  return a + b;
}
Enter fullscreen mode Exit fullscreen mode

Ou poderia estar dentro de uma biblioteca.

A grande vantagem da biblioteca é que funcionalidades mais complexas podem ser disponibilizadas sem que precisemos implementar toda a lógica internamente.


5. Biblioteca na prática

Vamos imaginar que precisamos trabalhar com datas.

Poderíamos escrever diversas funções para:

  • converter datas;
  • comparar datas;
  • adicionar dias;
  • calcular diferenças;
  • formatar datas.

Mas existem bibliotecas especializadas nisso.

Por exemplo, uma biblioteca conhecida no ecossistema JavaScript é o date-fns.

Depois de instalar:

npm install date-fns
Enter fullscreen mode Exit fullscreen mode

podemos utilizar funções fornecidas pela biblioteca:

import { format } from 'date-fns';

const data = new Date();

console.log(format(data, 'dd/MM/yyyy'));
Enter fullscreen mode Exit fullscreen mode

Em vez de implementar toda a lógica de formatação de datas, utilizamos uma função já disponível.


6. O que acontece quando fazemos npm install?

Essa é uma parte muito importante para quem está começando com JavaScript.

Quando executamos:

npm install date-fns
Enter fullscreen mode Exit fullscreen mode

estamos basicamente dizendo:

"Quero adicionar essa biblioteca ao meu projeto."

O gerenciador de pacotes baixa a biblioteca e registra a dependência do projeto.

Normalmente veremos algo parecido no package.json:

{
  "dependencies": {
    "date-fns": "^4.1.0"
  }
}
Enter fullscreen mode Exit fullscreen mode

Agora o projeto sabe que depende dessa biblioteca.


7. O package.json

O arquivo package.json é muito importante no ecossistema JavaScript.

Ele pode armazenar informações como:

  • nome do projeto;
  • versão;
  • scripts;
  • dependências;
  • dependências de desenvolvimento;
  • configurações do projeto.

Por exemplo:

{
  "name": "meu-projeto",
  "version": "1.0.0",
  "scripts": {
    "start": "node index.js"
  },
  "dependencies": {
    "date-fns": "^4.1.0"
  }
}
Enter fullscreen mode Exit fullscreen mode

Observe:

"dependencies": {
  "date-fns": "^4.1.0"
}
Enter fullscreen mode Exit fullscreen mode

Isso significa que date-fns é uma dependência utilizada pelo projeto.


8. Dependência e biblioteca são a mesma coisa?

Não exatamente.

Uma biblioteca é um código reutilizável.

Uma dependência é algo de que o nosso projeto depende para funcionar ou para realizar determinada tarefa.

Uma biblioteca pode ser uma dependência.

Por exemplo:

Meu projeto
     |
     +---- date-fns
     |
     +---- axios
     |
     +---- lodash
Enter fullscreen mode Exit fullscreen mode

Nesse caso, essas bibliotecas podem ser dependências do projeto.

Por isso, os termos aparecem frequentemente juntos.


9. Como usamos uma biblioteca?

Depois de instalada, normalmente precisamos importar aquilo que queremos utilizar.

Por exemplo:

import axios from 'axios';
Enter fullscreen mode Exit fullscreen mode

Depois podemos utilizar a funcionalidade fornecida:

const resposta = await axios.get(
  'https://api.exemplo.com/users'
);

console.log(resposta.data);
Enter fullscreen mode Exit fullscreen mode

Perceba uma coisa interessante.

Nós não precisamos saber exatamente como o Axios implementou internamente toda a comunicação HTTP.

Utilizamos a interface disponibilizada pela biblioteca.


10. O que é uma API de uma biblioteca?

Aqui existe uma confusão comum.

Quando falamos de biblioteca, também podemos falar sobre a API da biblioteca.

Nesse contexto, API significa a forma como nosso código pode interagir com aquela biblioteca.

Por exemplo:

axios.get(...)
axios.post(...)
axios.delete(...)
Enter fullscreen mode Exit fullscreen mode

Essas funções fazem parte da interface disponibilizada pelo Axios.

Podemos imaginar:

                 NOSSO CÓDIGO
                      |
                      v
             axios.get(...)
                      |
                      v
              API DA BIBLIOTECA
                      |
                      v
             IMPLEMENTAÇÃO
                INTERNA
Enter fullscreen mode Exit fullscreen mode

Não precisamos necessariamente conhecer toda a implementação interna para utilizar a biblioteca.


11. Biblioteca é uma "caixa de ferramentas"

Uma biblioteca normalmente possui diversas funcionalidades relacionadas.

Imagine uma biblioteca para trabalhar com datas:

date-fns
   |
   +--- format()
   +--- addDays()
   +--- subDays()
   +--- differenceInDays()
   +--- isBefore()
   +--- isAfter()
Enter fullscreen mode Exit fullscreen mode

Nosso projeto pode utilizar apenas algumas delas.

Por exemplo:

import {
  format,
  addDays
} from 'date-fns';
Enter fullscreen mode Exit fullscreen mode

Podemos utilizar:

const hoje = new Date();

const amanha = addDays(hoje, 1);

console.log(format(amanha, 'dd/MM/yyyy'));
Enter fullscreen mode Exit fullscreen mode

Não precisamos criar todas essas funções.


12. Bibliotecas resolvem problemas específicos

Uma biblioteca normalmente não existe simplesmente para "ser uma biblioteca".

Ela costuma resolver algum problema.

Podemos encontrar bibliotecas para praticamente qualquer área:

Problema Exemplos de bibliotecas
Requisições HTTP Axios
Datas date-fns
Utilidades Lodash
Gráficos Chart.js
Validação Zod
Testes Vitest / Jest
Componentes de interface várias opções
Animações várias opções
Manipulação de arquivos várias opções

A ideia principal é:

Existe um problema recorrente? É possível que exista uma biblioteca que já tenha uma solução para ele.


13. Mas por que não fazer tudo sozinho?

Essa é uma ótima pergunta.

Porque desenvolvimento de software envolve muito mais do que escrever código.

Também precisamos pensar em:

  • tempo;
  • manutenção;
  • testes;
  • segurança;
  • compatibilidade;
  • documentação;
  • bugs;
  • desempenho;
  • atualização.

Imagine que você precise implementar uma biblioteca complexa de datas.

Você poderia gastar dias ou semanas trabalhando em algo que outras pessoas já implementaram, testaram e documentaram.

Isso não significa que devemos instalar uma biblioteca para absolutamente tudo.

Significa apenas que devemos saber quando reutilizar código.


14. Reutilização de código

Um dos conceitos fundamentais por trás das bibliotecas é a reutilização.

Imagine que 10.000 projetos precisem realizar determinada tarefa.

Sem uma biblioteca:

Projeto A → implementa
Projeto B → implementa
Projeto C → implementa
Projeto D → implementa
...
Enter fullscreen mode Exit fullscreen mode

Com uma biblioteca:

                 BIBLIOTECA
                /    |    \
               /     |     \
              v      v      v
         Projeto A Projeto B Projeto C
Enter fullscreen mode Exit fullscreen mode

Uma implementação pode ser utilizada por vários projetos.

É uma das grandes forças do desenvolvimento moderno.


15. Biblioteca vs código próprio

Vamos comparar.

Código próprio

function validarEmail(email) {
  // implementação criada pela equipe
}
Enter fullscreen mode Exit fullscreen mode

Biblioteca

import { z } from 'zod';

const schema = z.object({
  email: z.string().email()
});
Enter fullscreen mode Exit fullscreen mode

Nos dois casos existe código sendo executado.

A diferença é quem implementou aquela solução e como ela é distribuída/reutilizada.


16. Biblioteca vs Framework

Essa é provavelmente uma das dúvidas mais comuns de quem está começando.

Biblioteca e framework não são exatamente a mesma coisa.

Uma maneira simples de pensar:

Biblioteca

"Eu chamo a biblioteca quando preciso dela."

Meu código
    |
    v
Biblioteca
Enter fullscreen mode Exit fullscreen mode

Framework

"O framework fornece uma estrutura na qual meu código funciona."

Framework
   |
   +---- Meu código
   |
   +---- Meu código
   |
   +---- Meu código
Enter fullscreen mode Exit fullscreen mode

Uma explicação bastante usada para essa diferença é a inversão de controle.

Na biblioteca, normalmente nós controlamos quando utilizamos suas funções.

No framework, o framework define boa parte do fluxo da aplicação e chama nosso código nos momentos apropriados.


17. Uma comparação simples

Imagine uma cozinha.

Uma biblioteca seria como uma ferramenta:

Cozinha
  |
  +--- Liquidificador
Enter fullscreen mode Exit fullscreen mode

Você decide quando utilizar.

Já um framework seria mais parecido com uma cozinha estruturada com regras sobre onde cada coisa deve ficar e como o processo deve funcionar.

Framework
   |
   +--- Estrutura
   +--- Regras
   +--- Fluxo
   +--- Convenções
Enter fullscreen mode Exit fullscreen mode

A analogia não é perfeita, mas ajuda a visualizar a diferença.


18. E o React?

React é frequentemente chamado de biblioteca para construir interfaces de usuário.

Um exemplo simples:

function App() {
  return <h1>Olá, mundo!</h1>;
}
Enter fullscreen mode Exit fullscreen mode

Aqui estamos utilizando funcionalidades fornecidas pelo React para construir a interface.

O importante não é decorar se determinada tecnologia é chamada de biblioteca ou framework.

É entender qual responsabilidade ela possui e como ela controla o fluxo da aplicação.


19. E o Angular?

No caso do Angular, temos uma estrutura mais abrangente para desenvolvimento de aplicações.

Ele fornece várias ferramentas integradas para coisas como:

  • componentes;
  • injeção de dependência;
  • roteamento;
  • formulários;
  • HTTP;
  • organização da aplicação;
  • ferramentas de desenvolvimento.

Por isso, Angular é normalmente tratado como um framework.


20. Biblioteca não significa "melhor"

Outro erro comum é pensar:

"Se existe uma biblioteca, então devemos utilizá-la."

Não necessariamente.

Adicionar uma biblioteca também possui custos.

Por exemplo:

Nova biblioteca
      |
      +--- código adicional
      +--- dependências
      +--- atualizações
      +--- possíveis vulnerabilidades
      +--- manutenção
      +--- impacto no projeto
Enter fullscreen mode Exit fullscreen mode

Por isso, antes de instalar uma biblioteca, vale perguntar:

  • Eu realmente preciso dela?
  • Posso resolver isso facilmente com código próprio?
  • Ela é mantida?
  • Possui documentação?
  • É compatível com meu projeto?
  • Existem vulnerabilidades conhecidas?
  • O tamanho dela é adequado?
  • A comunidade utiliza essa solução?

21. Cuidado com o "instalar uma lib para tudo"

Imagine que alguém precise somar dois números.

E decide instalar uma biblioteca:

npm install calculadora-super-ultra
Enter fullscreen mode Exit fullscreen mode

Para depois:

import { soma } from 'calculadora-super-ultra';
Enter fullscreen mode Exit fullscreen mode

Isso provavelmente não faz muito sentido.

Poderíamos simplesmente escrever:

const resultado = 10 + 20;
Enter fullscreen mode Exit fullscreen mode

A biblioteca precisa trazer uma vantagem real.

Uma boa prática não é usar o maior número possível de bibliotecas. É utilizar dependências que realmente agregam valor ao projeto.


22. Bibliotecas também podem depender de outras bibliotecas

Esse ponto é bastante interessante.

Imagine:

Meu projeto
    |
    +---- Biblioteca A
              |
              +---- Biblioteca B
              |
              +---- Biblioteca C
Enter fullscreen mode Exit fullscreen mode

Nós instalamos apenas a Biblioteca A, mas ela pode depender de outras bibliotecas.

Essas são chamadas de dependências transitivas.

Por isso, um projeto moderno pode possuir muito mais pacotes instalados do que aqueles que aparecem diretamente no package.json.


23. node_modules

Depois de instalar dependências em um projeto JavaScript, normalmente encontramos:

node_modules/
Enter fullscreen mode Exit fullscreen mode

Essa pasta contém os pacotes instalados e suas dependências.

Por exemplo:

meu-projeto/
│
├── node_modules/
│   ├── axios/
│   ├── date-fns/
│   └── ...
│
├── package.json
├── package-lock.json
└── index.js
Enter fullscreen mode Exit fullscreen mode

É importante entender:

node_modules não é o lugar onde normalmente editamos nossas bibliotecas.

Ele é o resultado da instalação das dependências.


24. E o package-lock.json?

Além do package.json, é comum encontrarmos:

package-lock.json
Enter fullscreen mode Exit fullscreen mode

Ele registra informações detalhadas sobre as versões das dependências instaladas.

Isso ajuda a tornar a instalação mais previsível em diferentes ambientes.

Por exemplo:

Desenvolvedor A
      |
      v
npm install
      |
      v
mesmas versões

Desenvolvedor B
      |
      v
npm install
      |
      v
mesmas versões
Enter fullscreen mode Exit fullscreen mode

Isso é especialmente importante quando várias pessoas trabalham no mesmo projeto.


25. Biblioteca local vs biblioteca global

No desenvolvimento com Node.js, também podemos encontrar instalações globais.

Por exemplo:

npm install -g alguma-ferramenta
Enter fullscreen mode Exit fullscreen mode

O -g significa instalação global.

Já:

npm install alguma-biblioteca
Enter fullscreen mode Exit fullscreen mode

normalmente instala a dependência no projeto atual.

Para bibliotecas utilizadas diretamente pelo código da aplicação, normalmente faz mais sentido que elas sejam dependências do próprio projeto.

Assim, outro desenvolvedor consegue instalar o projeto utilizando:

npm install
Enter fullscreen mode Exit fullscreen mode

26. Como uma biblioteca chega até nosso código?

Podemos visualizar todo o processo:

Desenvolvedor
     |
     | npm install
     v
Registro de pacotes
     |
     v
Biblioteca
     |
     v
node_modules
     |
     v
Nosso código
     |
     v
import
     |
     v
Funções da biblioteca
Enter fullscreen mode Exit fullscreen mode

No ecossistema JavaScript, o npm é uma das principais formas de distribuir e instalar pacotes.


27. Uma biblioteca também pode ser criada por nós

Aqui está uma ideia importante:

Nós também podemos criar bibliotecas.

Imagine que você criou algumas funções úteis:

export function somar(a, b) {
  return a + b;
}

export function multiplicar(a, b) {
  return a * b;
}
Enter fullscreen mode Exit fullscreen mode

Você poderia organizar esse código e disponibilizá-lo para outros projetos.

A ideia seria:

Projeto A
     |
     v
Minha biblioteca
     ^
     |
Projeto B
Enter fullscreen mode Exit fullscreen mode

Isso é reutilização de código em uma escala maior.


28. Biblioteca pública e biblioteca privada

Nem toda biblioteca precisa ser disponibilizada publicamente.

Uma empresa pode criar uma biblioteca interna para seus próprios projetos.

Por exemplo:

Empresa
   |
   +--- Sistema financeiro
   |
   +--- Sistema administrativo
   |
   +--- Aplicativo mobile
   |
   +--- Site
          |
          v
    Biblioteca interna
Enter fullscreen mode Exit fullscreen mode

Essa biblioteca poderia conter:

  • componentes visuais;
  • funções utilitárias;
  • regras compartilhadas;
  • validações;
  • padrões de comunicação;
  • componentes de formulário.

Isso evita que cada projeto precise implementar as mesmas coisas novamente.


29. Bibliotecas e Design System

Um exemplo bastante interessante é o uso de bibliotecas para criar Design Systems.

Imagine uma empresa com vários sistemas.

Todos precisam utilizar:

Botões
Inputs
Modais
Tabelas
Cards
Menus
Cores
Tipografia
Enter fullscreen mode Exit fullscreen mode

Em vez de cada sistema criar seus próprios componentes, uma biblioteca pode disponibilizar esses elementos.

                 UI Library
                     |
        +------------+------------+
        |            |            |
        v            v            v
     Sistema A    Sistema B    Sistema C
        |            |            |
        +------------+------------+
                     |
              Mesmo padrão visual
Enter fullscreen mode Exit fullscreen mode

Isso facilita a manutenção e mantém consistência entre aplicações.


30. Como escolher uma biblioteca?

Antes de instalar qualquer pacote, podemos fazer algumas perguntas.

1. Ela resolve realmente meu problema?

Se a resposta for não, provavelmente não precisamos dela.

2. Possui documentação?

Uma biblioteca sem documentação pode se tornar difícil de manter.

3. É mantida?

É interessante verificar se existem atualizações e manutenção ativa.

4. Possui comunidade?

Uma comunidade maior pode facilitar a busca por exemplos e soluções.

5. Possui problemas de segurança conhecidos?

Dependências também podem possuir vulnerabilidades.

6. Ela é compatível com meu projeto?

Uma biblioteca pode exigir uma versão específica do Node.js, Angular, React ou outra tecnologia.


31. Biblioteca também tem versão

Imagine:

Biblioteca v1
Biblioteca v2
Biblioteca v3
Enter fullscreen mode Exit fullscreen mode

Uma atualização pode trazer:

  • novas funcionalidades;
  • correções;
  • melhorias de desempenho;
  • correções de segurança;
  • mudanças na API.

Mas também pode alterar comportamentos existentes.

Por isso, atualizar dependências sem analisar o impacto pode causar problemas.


32. O famoso "funciona na minha máquina"

Imagine:

Computador A
    |
    v
Biblioteca versão 1.5
    |
    v
Funcionou!
Enter fullscreen mode Exit fullscreen mode

Enquanto:

Computador B
    |
    v
Biblioteca versão 2.0
    |
    v
Erro!
Enter fullscreen mode Exit fullscreen mode

Esse tipo de situação mostra por que o gerenciamento de dependências é importante.

O package.json, o lockfile e ferramentas como npm ajudam a manter o ambiente mais previsível.


33. Biblioteca não elimina a necessidade de entender programação

Esse é um ponto que considero especialmente importante para iniciantes.

Imagine que você use uma biblioteca para fazer uma requisição:

axios.get('/users');
Enter fullscreen mode Exit fullscreen mode

É possível utilizar isso sem entender profundamente HTTP.

Mas, quando surgir um erro:

404
500
401
403
CORS
Timeout
Enter fullscreen mode Exit fullscreen mode

ter conhecimento sobre HTTP fará muita diferença.

Por isso:

Bibliotecas ajudam a escrever software, mas não substituem os fundamentos da programação.

Quanto mais você entende os fundamentos, melhor consegue utilizar as ferramentas.


34. Um exemplo completo

Vamos criar um pequeno projeto.

Imagine que queremos consultar usuários.

Sem biblioteca:

fetch('https://api.exemplo.com/users')
  .then(response => response.json())
  .then(data => {
    console.log(data);
  });
Enter fullscreen mode Exit fullscreen mode

Agora podemos utilizar uma biblioteca especializada:

import axios from 'axios';

const response = await axios.get(
  'https://api.exemplo.com/users'
);

console.log(response.data);
Enter fullscreen mode Exit fullscreen mode

O código fica diferente, mas o conceito permanece:

Nosso código
     |
     v
Biblioteca
     |
     v
Requisição HTTP
     |
     v
Servidor
     |
     v
Resposta
Enter fullscreen mode Exit fullscreen mode

A biblioteca funciona como uma camada que facilita determinada tarefa.


35. O que acontece por baixo dos panos?

Quando utilizamos uma biblioteca, nosso código não deixa de ser executado.

Imagine:

axios.get('/users');
Enter fullscreen mode Exit fullscreen mode

Internamente, a biblioteca possui diversas funções e regras para transformar essa chamada em algo que o ambiente consiga executar.

Podemos simplificar:

axios.get()
    |
    v
Biblioteca
    |
    v
Preparação da requisição
    |
    v
HTTP
    |
    v
Servidor
    |
    v
Resposta
Enter fullscreen mode Exit fullscreen mode

A biblioteca esconde parte da complexidade.

Isso é uma das grandes vantagens da abstração.


36. Biblioteca é uma forma de abstração

Abstração significa esconder detalhes desnecessários para facilitar o uso de algo.

Por exemplo:

const resposta = await axios.get(url);
Enter fullscreen mode Exit fullscreen mode

Você não precisa escrever manualmente toda a implementação necessária para:

  • abrir a conexão;
  • montar headers;
  • tratar a resposta;
  • converter dados;
  • lidar com vários detalhes da requisição.

A biblioteca fornece uma interface mais simples.

Podemos pensar:

Complexidade interna
████████████████████████

          ↓

Interface simples

axios.get(url)
Enter fullscreen mode Exit fullscreen mode

Uma boa biblioteca transforma uma tarefa complexa em uma interface que podemos utilizar de maneira mais simples.


37. O que aprendemos?

Depois de tudo isso, podemos resumir:

Biblioteca (Lib) é um conjunto de código reutilizável criado para fornecer funcionalidades que podem ser utilizadas por outras aplicações.

Ela pode ajudar a:

  • economizar tempo;
  • reutilizar código;
  • reduzir trabalho repetitivo;
  • abstrair complexidade;
  • padronizar soluções;
  • acelerar o desenvolvimento.

Mas também precisamos considerar:

  • manutenção;
  • segurança;
  • versões;
  • tamanho;
  • dependências;
  • documentação;
  • compatibilidade.

38. Biblioteca em uma única imagem mental

Se você lembrar apenas de uma coisa deste artigo, lembre disso:

              NOSSO PROJETO
                    |
                    v
          +-------------------+
          |       LIB         |
          |                   |
          |  Código pronto    |
          |  Funções          |
          |  Utilidades       |
          |  Abstrações       |
          +-------------------+
                    |
                    v
            Resultado desejado
Enter fullscreen mode Exit fullscreen mode

Nós não precisamos reinventar tudo.

Podemos aproveitar soluções existentes e concentrar nosso esforço naquilo que realmente torna nossa aplicação única.


Conclusão

No início da programação, é comum pensar que ser um bom programador significa saber escrever absolutamente tudo sozinho.

Na prática, desenvolvimento de software é muito mais sobre saber resolver problemas do que sobre escrever cada linha do zero.

Bibliotecas fazem parte dessa realidade.

Quando precisamos trabalhar com datas, requisições HTTP, validação, gráficos, testes ou diversas outras tarefas, podemos utilizar soluções que já foram desenvolvidas e disponibilizadas para reutilização.

Mas existe uma diferença importante entre:

"Eu instalei uma biblioteca."

e

"Eu entendo por que estou utilizando essa biblioteca."

A segunda situação é muito mais importante.

Uma biblioteca não substitui o conhecimento do programador. Ela é uma ferramenta.

E quanto melhor entendemos programação, mais capazes somos de escolher as ferramentas certas.

Problema
   |
   v
Preciso implementar uma solução?
   |
   +---- Sim ----> Código próprio
   |
   +---- Existe uma boa solução?
                    |
                    v
                Biblioteca
                    |
                    v
              Nosso projeto
Enter fullscreen mode Exit fullscreen mode

No final, a ideia é simples:

Uma biblioteca é código reutilizável que podemos incorporar ao nosso projeto para resolver problemas sem precisar reinventar a roda.

E talvez essa seja uma das maiores ideias por trás do desenvolvimento moderno:

não precisamos construir tudo sozinhos — precisamos saber como combinar as peças certas.


Para continuar estudando

Depois de entender bibliotecas, alguns conceitos fazem bastante sentido como próximos passos:

  • O que é um pacote?
  • O que é npm?
  • O que é package.json?
  • O que é node_modules?
  • O que é uma dependência?
  • O que são dependências transitivas?
  • O que é um framework?
  • O que é uma API?
  • O que é SDK?
  • O que é gerenciamento de versões?
  • O que é Semantic Versioning (SemVer)?

Esses conceitos estão diretamente relacionados e ajudam a entender melhor como os projetos modernos são construídos.

Top comments (0)