Nachdenken über moderne Paketmanager
Ich habe kürzlich mit einem Freund über alle verfügbaren Tools gesprochen, die heute für uns auf dem Markt sind (manche kostenlos, manche Open Source), die uns bei unseren Entwicklungsanforderungen helfen.
Dazu gehören Dinge wie:
Natürlich ist nicht jedes der oben genannten Tools unbedingt vergleichbar, da einige Front-End-Tools sind, andere Back-End-Tools, und wieder andere bieten eine Art Hybrid an.
Darüber hinaus sind einige Premium, einige Open Source, einige scheinen aufgegeben zu sein und einige haben sogar zu fehlerhaften Build-Prozessen geführt.
Dies führt zu einer Reihe von Fragen, von denen ich einige behandeln möchte. Hier sind also, wenn auch nichts anderes als Gedanken über moderne Paketmanager, die Dinge, über die ich nachgedacht habe.
Moderne Paketmanager
Die Fragen, die mir in den Sinn gekommen sind (und die ich mit besagtem Freund besprochen habe) lauten wie folgt:
- Woher sollen wir wissen, was wir verwenden sollen,
- wann man sie benutzt,
- und ob es sich lohnt, bei ihnen zu bleiben?
Und so dachte ich, ich würde meine aktuellen Gedanken zu diesen Tools und ihrer Anwendbarkeit hier teilen.
Welche verwenden wir?
Es ist leicht, sich dieser Antwort zu entziehen und zu sagen „was auch immer Sie wollen”, aber ich denke, die Antwort ist ein bisschen nuancierter als das.
Zum Beispiel gibt es Lernkurven, Pakete, Wartung und so weiter, die mit jedem von ihnen geliefert werden. Das ist weder gut noch schlecht – es ist das Natürliche, was sie sind.
Die Frage, die ich eher stellen möchte, lautet: „Welche dient meinem Team, meinem Projekt und meinen Kunden am besten?” Und hier ist der Grund:
- Wenn das Team das Dienstprogramm einfach übernehmen kann, gibt es so gut wie keine Probleme, damit es für seine Arbeit in Betrieb zu nehmen.
- Wenn es von Anfang an gut mit dem Projekt zusammenarbeitet, sollte es die Wartung erleichtern, wenn ein Projekt wächst und reift. Dies ist wichtig, da wir sonst riskieren, wertvolle Zeit und Mühe zu verschwenden, um die Dinge auf den neuesten Stand zu bringen, wenn sich das Versorgungsunternehmen ändert (falls es sich ändert), und dies kann sich nachteilig auf einen Zeitplan für ein Projekt auswirken.
- Was dem Kunden am besten dient, glaube ich, ist eine dieser Situationen, in denen der Teufel im Detail steckt. Das heißt, wenn die ersten beiden zufrieden sind, wird der Kunde nichts klüger. Zweitens würde es weniger Zeit kosten, mehr Wert bieten und dafür sorgen, dass sie daran interessiert sind, Sie als Anbieter für ihren Service zu nutzen.
Abgesehen davon glaube ich nicht, dass es einen einzigen „Dies ist das Dienstprogramm, das Sie verwenden sollten” gibt, weil ich wiederum die Details eines bestimmten Projekts nicht kenne. Daher möchte ich nicht eine Lösung vorschreiben, wenn eine andere für den Fall geeignet ist.
Und hier ist ein Beispiel:
Ich habe Gulp, CodeKit und Yarn in verschiedenen Projekten verwendet. Wäre es schön, ein einziges Tool zu haben? Sicher! Und jeder kann relativ die gleichen Dinge tun wie die anderen.
Aber die Geschwindigkeit, mit der etwas zum Laufen gebracht werden muss, die Portabilität und die verfügbaren Pakete unterscheiden sich leicht, und ob ich an etwas für mich selbst, für einen Kunden, mit einem Team oder alleine arbeite, sind alles Faktoren, die sich in die Gleichung einbringen .
Ich glaube, dass wir im Laufe der Zeit eine Intuition darüber entwickeln, welches angesichts der Anforderungen eines Projekts und der Erfahrung mit jedem der oben genannten Tools am besten geeignet ist.
Sicher, es sind einige Investitionen im Voraus erforderlich, um sich mit so vielen vertraut zu machen, wie Sie es für nützlich für Ihr Team und Ihre Bemühungen halten, aber es kann Ihnen gute Dienste leisten, wenn Sie als Entwickler weiter vorankommen.
Wann verwenden wir sie?
Ich denke nicht, dass diese Frage so schwer zu beantworten ist, wenn Sie sie mit der gebotenen Sorgfalt ausprobiert haben. Wieder mit der Intuition, oder?
Aber hier ist meine allgemeine Vorgehensweise:
- Wenn ich alleine arbeite oder mich schnell auf etwas konzentrieren muss, ist CodeKit eine gute Lösung.
- Wenn ich mit einem Team arbeite und etwas schnelles, skalierbares und gut definiertes benötigen, ist Yarn eine gute Wahl.
Ich denke immer noch, dass Gulp einen Blick wert ist, aber die Entwicklung und die Pakete dafür scheinen sich verlangsamt zu haben. Grunt scheint sich derzeit nicht in der Entwicklung zu befinden, aber wenn es für Sie und die von Ihnen benötigten Pakete funktioniert, lohnt es sich möglicherweise nicht, es jetzt zu ändern.
Tatsächlich würde ich sagen, wenn Sie keinen soliden Grund für den Wechsel angeben können, warum sollten Sie sich dann die Mühe machen? Praktikabilität zählt.
Lohnt es sich, bei ihnen zu bleiben?
Ich weiß nicht. Ich meine, die Technologie entwickelt sich so schnell, und neue Tools kommen hinzu (von denen ich nicht unbedingt denke, dass wir sie immer übernehmen sollten), und dann bleiben sie eine Weile bestehen.
Vielleicht stagnieren sie. Vielleicht erreichen sie keine breite Akzeptanz. Vielleicht sind sie im Ruhestand.
Vielleicht ist die optimale Antwort auf diese Frage, herauszufinden, was Ihnen hilft, das Problem so effizient wie möglich zu lösen, was auch von einer aktiven Community von Entwicklern unterstützt wird und das Sie und Ihr Team am einfachsten übernehmen können?
Das Endergebnis?
Wenn überhaupt, ist dieser Beitrag nichts weiter als persönliche Überlegungen darüber, wie man sich der sich ständig ändernden Landschaft von Build-Tools und Paketmanagern nähert. Und es geht darum, wie man bei einer bestimmten Art von Problem überlegt, wann man zu welchem gehört.
Ich möchte nicht unbedingt eine einzige Lösung, weil ich denke, dass die Optionen, die wir haben, mehr Innovation fördern. Gleichzeitig kann es zu Ermüdung führen, wenn Sie mithalten müssen.
Also, wenn nichts anderes, untersuchen Sie eine Teilmenge der beliebtesten Tools (vielleicht wie auf GitHub als nützliche Metrik markiert) und gehen Sie dann von dort aus.