Funderar på moderna pakethanterare
Jag pratade nyligen med en vän om alla tillgängliga verktyg som finns på marknaden för oss idag (några gratis, andra med öppen källkod) som hjälper oss med våra utvecklingsbehov.
Dessa inkluderar saker som:
- Grymta
- Klunk
- Garn
- CodeKit
- Kompositör
- och så vidare.
Naturligtvis är vart och ett av ovanstående inte nödvändigtvis jämförbart eftersom vissa är front-end-verktyg, andra är backend-verktyg, och det finns några som erbjuder en hybrid av sorter.
Vidare är vissa premium, vissa är öppen källkod, vissa verkar vara övergivna och vissa har till och med lett till trasiga byggprocesser.
Detta leder till en rad frågor som jag skulle vilja ta upp flera. Så här, om inte annat än funderingar på moderna pakethanterare, är de saker som jag har funderat på.
Moderna pakethanterare
Frågorna som kom att tänka på för mig (och som jag diskuterade med vännen) är följande:
- hur ska vi veta vilken vi ska använda,
- när man ska använda dem,
- och om det är värt att hålla fast vid dem?
Så jag tänkte dela med mig av mina nuvarande tankar om nämnda verktyg och deras tillämpbarhet här.
Vilka använder vi?
Det är lätt att undvika det här svaret och säga "vilken du vill", men jag tror att svaret är lite mer nyanserat än så.
Till exempel finns det inlärningskurvor, paket, underhåll och så vidare som följer med var och en av dem. Det här är inte bra eller dåligt – det är det naturliga i vad de är.
Frågan jag är mer intresserad av att ställa är "vilken tjänar mitt team, mitt projekt och mina kunder bäst?" Och här är varför:
- Om teamet enkelt kan använda verktyget, så finns det nästan noll friktion för att komma igång med det för sitt arbete.
- Om det fungerar bra med projektet från början bör det underlätta underhållet när ett projekt växer och mognar. Detta är viktigt eftersom vi annars riskerar att slösa bort värdefull tid och kraft för att få fart på saker och ting när verktyget ändras (om det ändras) och detta kan vara skadligt för ett schema för ett projekt.
- Det som tjänar kunden bäst tror jag är en av de där "djävulen är i detaljerna". Det är så att om de två första är nöjda så blir kunden ingen desto klokare. För det andra skulle det kosta mindre tid, ge mer värde och hålla dem investerade i att använda dig som leverantör för sin tjänst.
Som sagt, jag tror inte att det finns ett enda "Detta är verktyget som du bör använda"-fall eftersom jag återigen inte känner till detaljerna i ett givet projekt. Jag vill alltså inte föreskriva en lösning när en annan kan passa fallet.
Och här är ett exempel:
Jag har använt Gulp, CodeKit och Yarn i olika projekt. Skulle det vara bra att ha ett enda verktyg att använda? Säker! Och var och en kan göra relativt samma saker som de andra.
Men hastigheten med vilken det krävs för att få igång något, portabiliteten och tillgängliga paket skiljer sig något åt, och om jag jobbar på något för mig själv, för en kund, med ett team eller ensam är alla faktorer som fungerar in i ekvationen. .
Övertid tror jag att vi utvecklar en intuition om vilken som kan vara bäst med tanke på kraven i ett projekt och ges erfarenhet av vart och ett av verktygen ovan.
Så visst, det finns en del investeringar i förväg som krävs för att bli bekant med hur många du än finner lämpliga för att vara till nytta för ditt team och ansträngningar, men det kan tjäna dig väl när du fortsätter att gå framåt som utvecklare.
När använder vi dem?
Jag tror inte att det här är en lika svår fråga att svara på om du har gjort din due diligence på att testa dem. Återigen med intuitionen, eller hur?
Men här är mitt allmänna tillvägagångssätt:
- Om jag arbetar ensam eller behöver fokusera på något snabbt är CodeKit en bra lösning.
- Om jag arbetar med ett team och behöver ha något snabbt, skalbart och väldefinierat är Yarn ett bra val.
Jag tycker fortfarande att Gulp är värt att ta en titt på att använda men utveckling och paket för det verkar ha saktat ner. Grunt verkar inte vara under utveckling för tillfället, men om det fungerar för dig och de paket du behöver kanske det inte är värt att ändra just nu.
I själva verket skulle jag säga om du inte kan ge en solid anledning till att byta, varför bry sig då? Det praktiska spelar roll.
Är det värt att hålla med dem?
jag vet inte. Jag menar, tekniken går så fort, och nya verktyg kommer in (som jag inte nödvändigtvis tycker att vi alltid ska använda), och sedan stannar de kvar ett tag.
Kanske stagnerar de. Kanske når de inte någon utbredd adoption. Kanske är de pensionerade.
Kanske är det mest optimala svaret på denna fråga att ta reda på vad som hjälper dig att lösa problemet på ett så effektivt sätt som möjligt, som också stöds av en aktiv gemenskap av utvecklare, och som du och ditt team enklast kan adoptera?
Poängen?
Om något är det här inlägget inget annat än personliga funderingar om hur man närmar sig det ständigt föränderliga landskapet av byggverktyg och pakethanterare. Och det är hur man resonerar igenom när till vilken man givet en viss typ av problem.
Jag vill inte nödvändigtvis ha en enda lösning eftersom jag tror att alternativen vi har främjar mer innovation. Samtidigt kan det introducera en nivå av trötthet när du måste hänga med.
Så, om inte annat, undersök en delmängd av de mest populära verktygen (kanske lika stjärnmärkta på GitHub som ett användbart mått) och gå sedan därifrån.