Reflexionando sobre los administradores de paquetes modernos
Hace poco estaba hablando con un amigo sobre todas las herramientas disponibles en el mercado para nosotros hoy (algunas gratuitas, otras de código abierto) que nos ayudan con nuestras necesidades de desarrollo.
Estos incluyen cosas como:
- Gruñido
- Trago
- Hilo
- Kit de código
- Compositor
- y así.
Por supuesto, cada uno de los anteriores no es necesariamente comparable porque algunas son herramientas de front-end, otras son herramientas de back-end y hay algunas que ofrecen una especie de híbrido.
Además, algunos son premium, algunos son de código abierto, algunos parecen estar abandonados y algunos incluso han dado lugar a procesos de compilación rotos.
Esto lleva a una serie de preguntas, varias de las cuales me gustaría cubrir. Así que aquí, si nada más que reflexiones sobre los administradores de paquetes modernos, están las cosas en las que he estado pensando.
Administradores de paquetes modernos
Las preguntas que me vinieron a la mente (y que estuve discutiendo con dicho amigo) son las siguientes:
- ¿Cómo se supone que vamos a saber cuál usar?
- cuando usarlos,
- y si vale la pena quedarse con ellos?
Entonces pensé en compartir mis pensamientos actuales sobre dichas herramientas y su aplicabilidad aquí.
¿Cuáles usamos?
Es fácil eludir esta respuesta y decir "cualquiera que quieras", pero creo que la respuesta es un poco más matizada que eso.
Por ejemplo, hay curvas de aprendizaje, paquetes, mantenimiento, etc. que vienen con cada uno de ellos. Esto no es algo bueno o malo, es lo natural de lo que son.
La pregunta que más me interesa hacer es "¿cuál sirve mejor a mi equipo, mi proyecto y mis clientes?" Y he aquí por qué:
- Si el equipo puede adoptar fácilmente la utilidad, entonces hay casi cero fricción para ponerse en marcha con ella para su trabajo.
- Si funciona bien con el proyecto desde el principio, debería facilitar el mantenimiento a medida que el proyecto crece y madura. Esto es importante porque, de lo contrario, corremos el riesgo de perder tiempo y esfuerzo valiosos para acelerar las cosas cuando cambia la utilidad (si cambia) y esto puede ser perjudicial para el cronograma de un proyecto.
- Creo que lo que mejor sirve al cliente es una de esas situaciones en las que “el diablo está en los detalles". Eso es para que si los dos primeros están satisfechos, el cliente no será más sabio. En segundo lugar, costaría menos tiempo, proporcionaría más valor y los mantendría interesados en utilizarlo como proveedor de su servicio.
Dicho esto, no creo que haya un solo caso de "Esta es la utilidad que debe usar" porque, nuevamente, no conozco los detalles de un proyecto determinado. Por lo tanto, no quiero prescribir una solución cuando otra puede encajar en el caso.
Y aquí hay un ejemplo:
He usado Gulp, CodeKit e Yarn en diferentes proyectos. ¿Sería bueno tener una sola herramienta para usar? ¡Por supuesto! Y cada uno puede hacer relativamente las mismas cosas que los demás.
Pero la velocidad a la que se necesita para que algo funcione, la portabilidad y los paquetes disponibles difieren ligeramente, y si estoy trabajando en algo para mí, para un cliente, con un equipo o solo, todos son factores que se integran en la ecuación. .
Con el tiempo, creo que desarrollamos una intuición sobre cuál puede ser mejor según los requisitos de un proyecto y dada la experiencia con cada una de las herramientas anteriores.
Entonces, seguro, se requiere cierta inversión por adelantado para familiarizarse con la cantidad que considere adecuada para que sea beneficiosa para su equipo y sus esfuerzos, pero puede serle útil a medida que continúa avanzando como desarrollador.
¿Cuándo los usamos?
No creo que esta sea una pregunta tan difícil de responder si ha hecho su debida diligencia al probarlos. De nuevo con la intuición, ¿no?
Pero aquí está mi enfoque general:
- Si estoy trabajando solo o necesito concentrarme en algo rápidamente, CodeKit es una buena solución.
- Si estoy trabajando con un equipo y necesito tener algo rápido, escalable y bien definido, Yarn es una buena opción.
Todavía creo que vale la pena echarle un vistazo a Gulp, pero el desarrollo y los paquetes parecen haberse ralentizado. Grunt no parece estar en desarrollo en este momento, pero si funciona para usted y los paquetes que necesita, puede que no valga la pena cambiarlo ahora.
De hecho, diría que a menos que pueda proporcionar una razón sólida para cambiar, ¿por qué molestarse? La practicidad importa.
¿Vale la pena quedarse con ellos?
No sé. Quiero decir, la tecnología avanza muy rápido y aparecen nuevas herramientas (que no necesariamente creo que debamos adoptar siempre), y luego se quedan por un tiempo.
Quizás se estancan. Quizás no alcancen una adopción generalizada. Tal vez estén jubilados.
Tal vez la respuesta más óptima a esta pregunta es descubrir qué lo ayudará a resolver el problema de la manera más eficiente posible, que también esté respaldado por una comunidad activa de desarrolladores y que usted y su equipo puedan adoptar más fácilmente.
¿La línea de fondo?
En todo caso, esta publicación no es más que reflexiones personales sobre cómo abordar el panorama en constante cambio de las herramientas de compilación y los administradores de paquetes. Y es cómo razonar cuándo a cuál dado cierto tipo de problema.
No necesariamente quiero una solución única porque creo que las opciones que tenemos fomentan más innovación. Al mismo tiempo, puede introducir un nivel de fatiga cuando tienes que seguir el ritmo.
Entonces, al menos, examine un subconjunto de las herramientas más populares (quizás como una estrella en GitHub como una métrica útil) y luego continúe desde allí.