Meditando sobre gerenciadores de pacotes modernos
Eu estava conversando recentemente com um amigo sobre todas as ferramentas disponíveis que estão no mercado para nós hoje (algumas gratuitas, algumas de código aberto) que nos ajudam com nossas necessidades de desenvolvimento.
Estes incluem coisas como:
- Grunhido
- Gole
- Fio
- CodeKit
- Compositor
- e assim por diante.
É claro que cada uma das opções acima não é necessariamente comparável porque algumas são ferramentas de front-end, outras são ferramentas de back-end e há algumas que oferecem um tipo híbrido.
Além disso, alguns são premium, alguns são de código aberto, alguns parecem ser abandonados e alguns até levaram a processos de compilação quebrados.
Isso leva a uma série de perguntas, várias das quais eu gostaria de abordar. Então aqui, se nada mais do que reflexões sobre gerenciadores de pacotes modernos, estão as coisas sobre as quais estive pensando.
Gerenciadores de Pacotes Modernos
As perguntas que me vieram à mente (e que eu estava discutindo com o referido amigo) são as seguintes:
- como devemos saber qual usar,
- quando usá-los,
- e se vale a pena ficar com eles?
E então pensei em compartilhar meus pensamentos atuais sobre essas ferramentas e sua aplicabilidade aqui.
Quais Usamos?
É fácil fugir dessa resposta e dizer “qual você quiser", mas acho que a resposta é um pouco mais sutil do que isso.
Por exemplo, existem curvas de aprendizado, pacotes, manutenção e assim por diante que vêm com cada um deles. Isso não é uma coisa boa ou ruim – é natural do que eles são.
A pergunta que estou mais interessado em fazer é “qual deles atende melhor minha equipe, meu projeto e meus clientes?” E aqui está o porquê:
- Se a equipe puder adotar facilmente o utilitário, haverá quase zero atrito para começar a trabalhar com ele.
- Se funcionar bem com o projeto desde o início, deve facilitar a manutenção à medida que o projeto cresce e amadurece. Isso é importante porque, caso contrário, corremos o risco de desperdiçar tempo e esforço valiosos para acelerar as coisas quando a utilidade mudar (se mudar) e isso pode ser prejudicial para o cronograma de um projeto.
- O que serve melhor ao cliente, acredito, é uma daquelas situações de “o diabo está nos detalhes”. Isso é para que, se os dois primeiros estiverem satisfeitos, o cliente não será mais sábio. Em segundo lugar, custaria menos tempo, forneceria mais valor e os manteria investidos em usá-lo como fornecedor para o serviço deles.
Dito isso, não acredito que exista um único caso “Este é o utilitário que você deve usar” porque, novamente, não conheço os detalhes de um determinado projeto. Assim, não quero prescrever uma solução quando outra pode se encaixar no caso.
E aqui está um exemplo:
Eu usei Gulp, CodeKit e Yarn em projetos diferentes. Seria bom ter uma única ferramenta para usar? Claro! E cada um pode fazer relativamente as mesmas coisas que os outros.
Mas a velocidade necessária para fazer algo acontecer, a portabilidade e os pacotes disponíveis diferem um pouco, e se estou trabalhando em algo para mim, para um cliente, com uma equipe ou sozinho são fatores que entram na equação .
Com o tempo, acredito que desenvolvemos uma intuição sobre qual deles pode ser o melhor dado os requisitos de um projeto e dada a experiência com cada uma das ferramentas acima.
Então, com certeza, há algum investimento inicial que é necessário para se familiarizar com quantos você achar adequado para ser benéfico para sua equipe e esforços, mas pode ser útil para você à medida que você continua avançando como desenvolvedor.
Quando os usamos?
Eu não acho que esta seja uma pergunta tão difícil de responder se você fez a devida diligência em testá-los. Novamente com a intuição, certo?
Mas aqui está minha abordagem geral:
- Se estou trabalhando sozinho ou preciso me concentrar em algo rapidamente, o CodeKit é uma boa solução.
- Se estou trabalhando em equipe e preciso ter algo rápido, escalável e bem definido, o Yarn é uma boa escolha.
Eu ainda acho que vale a pena dar uma olhada no Gulp, mas o desenvolvimento e os pacotes para ele parecem ter desacelerado. O Grunt não parece estar em desenvolvimento no momento, mas se funcionar para você e para os pacotes que você precisa, pode não valer a pena mudar agora.
Na verdade, eu diria que a menos que você possa fornecer uma razão sólida para mudar, então por que se preocupar? A praticidade importa.
Vale a pena ficar com eles?
Não sei. Quer dizer, a tecnologia se move tão rápido, e novas ferramentas chegam (que eu não necessariamente acho que devemos sempre adotar), e então elas permanecem por um tempo.
Talvez eles estagnam. Talvez eles não alcancem ampla adoção. Talvez estejam aposentados.
Talvez a resposta mais ideal para essa pergunta seja descobrir o que o ajudará a resolver o problema da maneira mais eficiente possível, que também esteja sendo suportado por uma comunidade ativa de desenvolvedores e que você e sua equipe possam adotar com mais facilidade?
A linha inferior?
Se alguma coisa, este post nada mais é do que reflexões pessoais sobre como abordar o cenário em constante mudança de ferramentas de construção e gerenciadores de pacotes. E é como raciocinar sobre quando para qual deles determinado tipo de problema.
Não quero necessariamente uma solução única porque acho que as opções que temos promovem mais inovação. Ao mesmo tempo, pode introduzir um nível de fadiga quando você precisa acompanhar.
Então, se nada mais, examine um subconjunto das ferramentas mais populares (talvez com estrela no GitHub como uma métrica útil) e depois vá a partir daí.