Mieti nykyaikaisia pakettien hallintaohjelmia
Keskustelin äskettäin ystäväni kanssa kaikista saatavilla olevista työkaluista, joita meillä on tänään markkinoilla (osa ilmaisista, osa avoimesta lähdekoodista), jotka auttavat meitä kehitystarpeissamme.
Näitä ovat esimerkiksi seuraavat asiat:
Tietenkään kaikki edellä mainitut eivät välttämättä ole vertailukelpoisia, koska jotkut ovat etupäätyökaluja, toiset ovat taustatyökaluja, ja jotkut tarjoavat erilaisia hybridejä.
Lisäksi jotkut ovat premium-luokan, jotkut avoimen lähdekoodin, jotkut näyttävät hylätyiltä ja jotkut ovat jopa johtaneet rikkoutuneisiin rakennusprosesseihin.
Tämä johtaa joukkoon kysymyksiä, joista haluan käsitellä useita. Joten tässä, jos ei muuta kuin pohdiskelua nykyaikaisista paketinhaltijoista, ovat asioita, joita olen ajatellut.
Nykyaikaiset pakettipäälliköt
Minulle mieleeni tulleet kysymykset (ja joista keskustelin kyseisen ystävän kanssa) ovat seuraavat:
- miten meidän pitäisi tietää, mitä käyttää,
- milloin niitä käytetään,
- ja kannattaako niistä pitäytyä?
Ja siksi ajattelin jakaa tämän hetkiset ajatukseni mainituista työkaluista ja niiden soveltuvuudesta täällä.
Mitä me käytämme?
On helppo väistää tätä vastausta ja sanoa "kumman haluat", mutta mielestäni vastaus on hieman vivahteikas.
Jokaisen mukana tulee esimerkiksi oppimiskäyriä, paketteja, ylläpitoa ja niin edelleen. Tämä ei ole hyvä tai huono asia – se on niiden luonnollista.
Minun kiinnostavampi kysymys on "kumpi palvelee tiimiäni, projektiani ja asiakkaitani parhaiten?" Ja tässä miksi:
- Jos tiimi voi helposti ottaa apuohjelman käyttöön, on lähes nolla kitkaa sen käynnistämisessä työssään.
- Jos se toimii hyvin projektin kanssa alusta alkaen, sen pitäisi helpottaa ylläpitoa projektin kasvaessa ja kypsyessä. Tämä on tärkeää, koska muuten saamme tuhlata arvokasta aikaa ja vaivaa saadaksemme asiat vauhtiin, kun apuohjelma muuttuu (jos se muuttuu), ja tämä voi olla haitallista projektin aikataululle.
- Se mikä palvelee asiakasta parhaiten, on mielestäni yksi niistä "paholainen on yksityiskohdissa" -tilanteista. Tämä on niin, että jos kaksi ensimmäistä ovat tyytyväisiä, asiakas ei ole viisaampi. Toiseksi se maksaisi vähemmän aikaa, tarjoaisi enemmän arvoa ja saisi heidät käyttämään sinua palvelun toimittajana.
En kuitenkaan usko, että on olemassa ainuttakaan "Tämä on apuohjelma, jota sinun pitäisi käyttää" -tapausta, koska en taaskaan tiedä tietyn projektin yksityiskohtia. Siksi en halua määrätä yhtä ratkaisua, kun toinen saattaa sopia tapaukseen.
Ja tässä esimerkki:
Olen käyttänyt Gulpia, CodeKitia ja lankaa eri projekteissa. Olisiko hyvä käyttää yhtä työkalua? Varma! Ja jokainen voi tehdä suhteellisen samoja asioita kuin muut.
Mutta nopeus, jolla jotain saa aikaan, siirrettävyys ja saatavilla olevat paketit vaihtelevat hieman, ja jos työskentelen itselleni, asiakkaalle, tiimin kanssa tai yksin, ovat kaikki tekijöitä, jotka vaikuttavat yhtälöön. .
Ylitöitä uskon, että kehitämme intuitiota siitä, mikä voi olla paras, kun otetaan huomioon projektin vaatimukset ja kokemus kustakin yllä olevista työkaluista.
Tietysti tarvitaan investointeja etukäteen, jotta voit tutustua niin moniin kuin katsot parhaaksi hyödyttääkseen tiimiäsi ja pyrkimyksiäsi, mutta se voi palvella sinua hyvin, kun jatkat eteenpäin kehittäjänä.
Milloin käytämme niitä?
En usko, että tähän kysymykseen on niin vaikea vastata, jos olet kokeillut niitä huolellisesti. Jälleen intuitiolla, eikö niin?
Mutta tässä minun yleinen lähestymistapani:
- Jos työskentelen yksin tai joudun keskittymään johonkin nopeasti, CodeKit on hyvä ratkaisu.
- Jos työskentelen tiimissä ja tarvitsen jotain nopeaa, skaalautuvaa ja selkeästi määriteltyä, Lanka on hyvä valinta.
Olen edelleen sitä mieltä, että Gulpin käyttöä kannattaa katsoa, mutta sen kehitys ja paketit näyttävät hidastuneen. Grunt ei näytä olevan kehitteillä tällä hetkellä, mutta jos se toimii sinulle ja tarvitsemillesi paketeille, sitä ei ehkä kannata muuttaa juuri nyt.
Itse asiassa sanoisin, että jos et pysty antamaan vankkaa syytä muutokselle, miksi vaivautua? Käytännöllisyys ratkaisee.
Kannattaako niihin tarttua?
Minä en tiedä. Tarkoitan, että tekniikka liikkuu niin nopeasti, ja uusia työkaluja tulee käyttöön (jota en välttämättä usko, että meidän pitäisi aina ottaa käyttöön), ja sitten ne pysyvät mukana jonkin aikaa.
Ehkä ne pysähtyvät. Ehkä ne eivät saavuta laajaa hyväksyntää. Ehkä he ovat eläkkeellä.
Ehkä optimaalinen vastaus tähän kysymykseen on selvittää, mikä auttaa sinua ratkaisemaan ongelman mahdollisimman tehokkaalla tavalla, jota tukee myös aktiivinen kehittäjäyhteisö ja jonka sinä ja tiimisi voitte helpoimmin ottaa käyttöön?
Bottom Line?
Jos mitään, tämä viesti ei ole muuta kuin henkilökohtaista pohdiskelua siitä, kuinka lähestyä jatkuvasti muuttuvaa rakennustyökalujen ja pakettien hallinnoijien maisemaa. Ja se, kuinka perustella, milloin mihin tahansa tietyntyyppisen ongelman vuoksi.
En välttämättä halua yhtä ainoaa ratkaisua, koska mielestäni vaihtoehdot edistävät enemmän innovaatioita. Samalla se voi aiheuttaa väsymystä, kun sinun on pysyttävä tahdissa.
Joten jos ei muuta, tutki suosituimpien työkalujen osajoukkoa (ehkä GitHubissa tähdellä merkityt hyödylliset mittarit) ja jatka sitten.