Réflexion sur les gestionnaires de packages modernes
Je parlais récemment avec un ami de tous les outils disponibles sur le marché pour nous aujourd’hui (certains gratuits, d’autres open source) qui nous aident avec nos besoins de développement.
Ceux-ci incluent des choses comme :
Bien sûr, chacun des éléments ci-dessus n’est pas nécessairement comparable car certains sont des outils frontaux, d’autres sont des outils principaux, et certains offrent une sorte d’hybride.
De plus, certains sont premium, certains sont open source, certains semblent être abandonnés et certains ont même conduit à des processus de construction cassés.
Cela conduit à une série de questions dont plusieurs que j’aimerais couvrir. Donc, voici, si rien d’autre que des réflexions sur les gestionnaires de paquets modernes, sont les choses auxquelles j’ai pensé.
Gestionnaires de packages modernes
Les questions qui me sont venues à l’esprit (et dont je discutais avec ledit ami) sont les suivantes :
- comment sommes-nous censés savoir lequel utiliser,
- quand les utiliser,
- et si ça vaut le coup de rester avec eux?
Et donc j’ai pensé que je partagerais ici mes réflexions actuelles sur ces outils et leur applicabilité.
Lesquels utilisons-nous ?
Il est facile d’esquiver cette réponse et de dire "celui que vous voulez", mais je pense que la réponse est un peu plus nuancée que cela.
Par exemple, il existe des courbes d’apprentissage, des packages, une maintenance, etc. qui accompagnent chacun d’eux. Ce n’est pas une bonne ou une mauvaise chose – c’est naturel de ce qu’ils sont.
La question qui m’intéresse le plus est "laquelle sert le mieux mon équipe, mon projet et mes clients ?" Et voici pourquoi :
- Si l’équipe peut facilement adopter l’utilitaire, alors il n’y a pratiquement aucune friction pour se mettre en route et l’utiliser pour son travail.
- Si cela fonctionne bien avec le projet dès le départ, cela devrait faciliter la maintenance à mesure que le projet grandit et mûrit. Ceci est important car sinon nous risquons de perdre un temps et des efforts précieux pour mettre les choses à jour lorsque le service public change (s’il change) et cela peut nuire au calendrier d’un projet.
- Ce qui sert le mieux le client, je crois, c’est l’une de ces situations où «le diable est dans les détails ». C’est ainsi que si les deux premiers sont satisfaits, le client n’en sera pas plus avisé. Deuxièmement, cela coûterait moins de temps, apporterait plus de valeur et les maintiendrait investis dans l’utilisation de vous en tant que fournisseur pour leur service.
Cela dit, je ne crois pas qu’il y ait un seul cas "C’est l’utilitaire que vous devriez utiliser" car, encore une fois, je ne connais pas les détails d’un projet donné. Ainsi, je ne veux pas prescrire une solution quand une autre peut convenir au cas.
Et voici un exemple :
J’ai utilisé Gulp, CodeKit et Yarn dans différents projets. Serait-il agréable d’avoir un seul outil à utiliser? Bien sûr! Et chacun peut faire relativement les mêmes choses que les autres.
Mais la vitesse à laquelle il faut faire avancer quelque chose, la portabilité et les packages disponibles diffèrent légèrement, et si je travaille sur quelque chose pour moi, pour un client, avec une équipe ou seul sont tous des facteurs qui s’intègrent dans l’équation .
Au fil du temps, je crois que nous développons une intuition sur ce qui peut être le mieux compte tenu des exigences d’un projet et de l’expérience acquise avec chacun des outils ci-dessus.
Donc, bien sûr, il y a un investissement initial qui est nécessaire pour se familiariser avec le nombre que vous jugez bon pour être bénéfique pour votre équipe et vos efforts, mais cela peut vous être utile pendant que vous continuez à avancer en tant que développeur.
Quand les utilisons-nous ?
Je ne pense pas qu’il soit aussi difficile de répondre à cette question si vous avez fait preuve de diligence raisonnable en les essayant. Encore une fois avec l’intuition, non?
Mais voici mon approche générale :
- Si je travaille seul ou si j’ai besoin de me concentrer sur quelque chose rapidement, CodeKit est une bonne solution.
- Si je travaille avec une équipe et que j’ai besoin de quelque chose de rapide, évolutif et bien défini, Yarn est un bon choix.
Je pense toujours que Gulp vaut la peine d’être utilisé, mais le développement et les packages semblent avoir ralenti. Grunt ne semble pas être en développement pour le moment, mais si cela fonctionne pour vous et les packages dont vous avez besoin, cela ne vaut peut-être pas la peine de changer pour le moment.
En fait, je dirais qu’à moins que vous ne puissiez fournir une raison solide pour changer, alors pourquoi s’embêter ? L’aspect pratique compte.
Vaut-il la peine de rester avec eux ?
Je ne sais pas. Je veux dire, la technologie évolue si vite et de nouveaux outils arrivent (que je ne pense pas nécessairement que nous devrions toujours adopter), puis ils restent pendant un certain temps.
Peut-être stagnent-ils. Peut-être n’atteignent-ils pas une adoption généralisée. Peut-être sont-ils à la retraite.
Peut-être que la réponse la plus optimale à cette question est de savoir ce qui vous aidera à résoudre le problème de la manière la plus efficace possible, qui est également pris en charge par une communauté active de développeurs, et que vous et votre équipe pouvez adopter le plus facilement ?
La ligne de fond ?
Au contraire, cet article n’est rien de plus que des réflexions personnelles sur la façon d’aborder le paysage en constante évolution des outils de construction et des gestionnaires de packages. Et c’est comment raisonner à quel moment donné un certain type de problème.
Je ne veux pas nécessairement une solution unique parce que je pense que les options que nous avons favorisent plus d’innovation. En même temps, cela peut introduire un niveau de fatigue lorsque vous devez suivre le rythme.
Donc, au moins, examinez un sous-ensemble des outils les plus populaires (peut-être comme une métrique utile sur GitHub), puis partez de là.