Niedawno rozmawiałem z przyjacielem o wszystkich dostępnych narzędziach, które są obecnie dostępne na rynku (niektóre darmowe, niektóre open source), które pomagają nam w naszych potrzebach rozwojowych.
Należą do nich takie rzeczy jak:
- Chrząknięcie
- Łyk
- Przędza
- CodeKit
- Kompozytor
- i tak dalej.
Oczywiście, każde z powyższych niekoniecznie jest porównywalne, ponieważ niektóre są narzędziami front-end, inne backendami, a są też takie, które oferują swego rodzaju hybrydę.
Co więcej, niektóre są premium, niektóre są open source, niektóre wydają się być porzucone, a niektóre doprowadziły nawet do zepsutych procesów kompilacji.
Prowadzi to do serii pytań, z których kilka chciałbym omówić. Więc tutaj, jeśli nic innego jak rozmyślanie o nowoczesnych menedżerach pakietów, są rzeczy, o których myślałem.
Nowoczesni menedżerowie pakietów
Pytania, które przyszły mi do głowy (i które omawiałem ze wspomnianym przyjacielem) są następujące:
- skąd mamy wiedzieć, którego użyć,
- kiedy ich używać,
- a czy warto się z nimi trzymać?
Pomyślałem więc, że podzielę się swoimi obecnymi przemyśleniami na temat wspomnianych narzędzi i ich zastosowania tutaj.
Których używamy?
Łatwo jest ominąć tę odpowiedź i powiedzieć „którą chcesz", ale myślę, że odpowiedź jest nieco bardziej zniuansowana.
Na przykład istnieją krzywe uczenia się, pakiety, konserwacja i tak dalej, które są dołączone do każdego z nich. To nie jest dobra ani zła rzecz – to naturalne, czym są.
Pytanie, które bardziej mnie interesuje, brzmi „które z nich najlepiej służy mojemu zespołowi, mojemu projektowi i moim klientom?” A oto dlaczego:
- Jeśli zespół może z łatwością zaadaptować to narzędzie, wtedy nie ma prawie żadnych problemów związanych z uruchomieniem go do pracy.
- Jeśli od samego początku działa dobrze z projektem, powinno ułatwić konserwację w miarę rozwoju i dojrzewania projektu. Jest to ważne, ponieważ w przeciwnym razie ryzykujemy marnowanie cennego czasu i wysiłku, aby przyspieszyć działanie, gdy zmieni się narzędzie (jeśli się zmieni), a to może być szkodliwe dla harmonogramu projektu.
- Uważam, że to, co najlepiej służy klientowi, to jedna z tych sytuacji, w których „diabeł tkwi w szczegółach”. To znaczy, że jeśli dwa pierwsze są zadowolone, klient nie będzie mądrzejszy. Po drugie, kosztowałoby to mniej czasu, zapewniłoby większą wartość i pozwoliło im zainwestować w korzystanie z Ciebie jako dostawcy usług.
To powiedziawszy, nie wierzę, że istnieje pojedynczy przypadek „To jest narzędzie, którego powinieneś użyć”, ponieważ znowu nie znam szczegółów danego projektu. Dlatego nie chcę przepisywać jednego rozwiązania, gdy inne może pasować do przypadku.
A oto przykład:
Używałem Gulp, CodeKit i Yarn w różnych projektach. Czy byłoby miło mieć jedno narzędzie do użycia? Pewnie! I każdy z nich może robić to samo, co inni.
Ale szybkość, z jaką coś się dzieje, przenośność i dostępne pakiety nieco się różnią, a jeśli pracuję nad czymś dla siebie, dla klienta, z zespołem lub sam, to czynniki, które same w sobie wchodzą w równanie .
Wierzę, że z biegiem czasu wypracowujemy intuicję co do tego, który z nich najlepiej pasuje do wymagań projektu i doświadczenia z każdym z powyższych narzędzi.
Tak więc, oczywiście, z góry trzeba zainwestować, aby zapoznać się z wieloma, które uznasz za korzystne dla twojego zespołu i wysiłków, ale może ci to dobrze służyć, gdy będziesz dalej rozwijać się jako programista.
Kiedy ich używamy?
Nie sądzę, aby odpowiedź na to pytanie była tak trudna, jeśli dołożyłaś należytej staranności do ich wypróbowania. Znowu z intuicją, prawda?
Ale oto moje ogólne podejście:
- Jeśli pracuję sam lub muszę szybko się na czymś skupić, CodeKit jest dobrym rozwiązaniem.
- Jeśli pracuję z zespołem i potrzebuję czegoś szybkiego, skalowalnego i dobrze zdefiniowanego, Yarn jest dobrym wyborem.
Nadal uważam, że warto przyjrzeć się używaniu Gulp, ale wydaje się, że jego rozwój i pakiety uległy spowolnieniu. Wygląda na to, że Grunt nie jest obecnie w fazie rozwoju, ale jeśli działa dla Ciebie i pakietów, których potrzebujesz, może nie warto go teraz zmieniać.
Właściwie powiedziałbym, że jeśli nie możesz podać solidnego powodu do zmiany, to po co zawracać sobie głowę? Liczy się praktyczność.
Czy warto się z nimi trzymać?
Nie wiem. Chodzi mi o to, że technologia porusza się tak szybko i pojawiają się nowe narzędzia (które niekoniecznie powinniśmy zawsze stosować), a potem zostają przez jakiś czas.
Być może stagnują. Być może nie osiągają one powszechnej adopcji. Być może są na emeryturze.
Być może najbardziej optymalną odpowiedzią na to pytanie jest dowiedzieć się, co pomoże Ci rozwiązać problem w najskuteczniejszy możliwy sposób, przy wsparciu aktywnej społeczności programistów, a co Ty i Twój zespół możecie najłatwiej zaadaptować?
Konkluzja?
Jeśli już, ten post to nic innego jak osobiste przemyślenia na temat tego, jak podejść do ciągle zmieniającego się krajobrazu narzędzi do budowania i menedżerów pakietów. I jest to sposób na rozumowanie, kiedy do którego z danym rodzajem problemu.
Niekoniecznie chcę jednego rozwiązania, ponieważ uważam, że opcje, które mamy, sprzyjają większej innowacyjności. Jednocześnie może powodować zmęczenie, kiedy trzeba nadążyć.
Tak więc, jeśli nic więcej, przeanalizuj podzbiór najpopularniejszych narzędzi (być może oznaczonych gwiazdką na GitHubie jako przydatne metryki), a następnie przejdź od tego miejsca.