Biti front-end developer danas je mnogo zanimljivije nego pre 10 godina. Poslednjih godina ceo ekosistem je eksplodirao i dosta alata, ranije nedostupnih, postalo je deo naše svakodnevnice.

Naši “stekovi” postali su moćniji, razvoj funkcionalnosti postao je jednostavniji i lakši, ali bez obzira na to, inžinjeri i dalje prave iste greške od projekta do projekta.

Bez obzira da li radimo na sledećem fejsbuku ili samo “hendlamo” klijentske projekte, postoje standardni problemi na koje nailazimo.

Inžinjerski timovi su većinom fokusirani na rokove, “dostavljanje” projekata sa što manje defekata moguće. Moramo da priznamo da su to situacije koje mnoge drže zadovoljnim.

Svi mi težimo ka tom stanju, gde sve funkcioniše perfektno, gde je svaki „fičer“ uglancan. Pre ili kasnije, ipak završimo u nekom stanju gde sve počinje da se raspada.

Ali šta ako za to postoji lek, šta ako ipak postoji svetlo na kraju tunela!

Šta je “Patern lajbrari”?

“Patern lajbrari” je termin koji je prethodnih godina bio zastupljen samo u dizajn sferi ali je pronašao svoju namenu i sa development strane.

U dizajn smislu, on predstavlja dizajn pravila koja opisuju kako jedan brend funkcioniše i njegove glavne karakteristike dok sa strane developmenta, predstavlja skup šablona i pravila pri razvoju aplikacija toga Brenda.

https://fractal.build/

Zašto nam je potreban „patern lajbrari“?

Kao inžinjeri, često trošimo vreme na stvari kao što su alati sa kojima radimo, pazimo na dizajn paterne i najbolje prakse. Dok jako retko na ono što dolazi na samom kraju. Kao što su održavanje i dokumentacija.

Što smo bliže završetku projekta sve se više fokusiramo na funkcionalnosti. I u tom procesu često nam se dešava da ostavljamo tragove funkcionalnosti za kasniji “refaktor” ili čišćenje, što se u većini slučajeva ne dogodi.

Mnogo je slučajeva gde nam patern lajbrari može pomoći, ali nekako za većinu projekata benefit dolazi u sledećim situacijama.

“Onboarding” novih developera

Što smo bliži završetku projekta, može se desiti da nam biznis “ubaci” nove kolege kako bi ubrzali stvari što je više moguće.

U tom procesu, odabrani članovi tima moraju da provedu neko vreme sa novim kolegama kako bi ih uputili u sve detalje projekta.

U slučaju kada imamo dobro dokumentovan kod sa jasno definisanim šablonima za izradu funkcionalnosti dobar deo “onboarding” procesa funkcioniše sam od sebe.

Redukovanje tehničkog dug-a

Često se dešava da dok razvijamo nove funkcionalnosti ne istražimo detaljno da li već nešto slično postoji u aplikaciji. Što zbog vremenskih rokova, što zbog toga jer nas mrzi.

Ako isprva ne pronađemo šta nas interesuje, krećemo sa razvijanjem nove funkcionalnosti.

Tako se kreira tehničku dug ( technical debt ) koji je na početku nevidljiv dok ne počne da pravi probleme. A veoma ga je teško iskoreniti jednom kada se nagomila.

Patern biblioteke rade odličan posao kada je prezentovanje komponenti u pitanju. Veoma je jednostavno pretražiti arhivu komponenti/šablona.

https://storybook.js.org/

Dokumentacija

Moje lično mišljenje je da je najbolnija tačka svakog projekta upravo nepostojanje dokumentacije. Nekada nedostatak dokumentacije je bolja solucija od postojanje dokumentacije koja nije ažurirana.

Slažem se sa činjenicom da lepo napisan kod predstavlja dokumentaciju sam po sebi ali koliko zaista inžinjeri imaju vremena da se bave ”lickanjem” koda.

U situacijama kada moramo da se podsetimo kako neka UI komponenta funkcioniše a koja je pisana na samom početku projekta, često se dešava da se vraćamo nazad kroz git i da trošimo dosta vremena da “provalimo” šta se tamo dešava.

Često to nije dovoljno jer je došlo do mnogo izmena od inicijalne implementacije pa se bacamo u eksperimentisanje dok ne dođemo do željenih rezultata.

Jedna od dobrih strana posedovanja patern biblioteke jeste što možemo da kreiramo realni scenario UI komponente i da vidimo kako se ponaša u različitim veličinama ekrana, takođe možemo da se igramo sa njom a da ne moramo da pazimo da ne pokvarimo neki drugi deo aplikacije.

Unificiran način razvoja

Što više developera učestvuje u radu na projektu, to možemo očekivati više stilova kodiranja. Što je scenario sa skoro svim projektima u skoro svim firmama.

Svakako da nam u pomoć mogu priskočiti linteri za kod ali često se oni bave stvarima kao što su formatiranje same sintakse ali ne i proveravanjem načina na koji se grade komponente u strukturnom smislu, ili kako se nazivaju klase u CSS kodu.

Ukoliko kroz samu patern biblioteku uspostavimo jedan standard za ove situacije, lakše je da se prati kada dođe do neke promene koja iskače iz definisanog okvira.

Neretko se dešava da sam tim funkcioniše bolje, jer u građenju ovih šablona potrebno je da ceo tim učestvuje.

Članovi tima dolaze i odlaze a projekat je taj koji ostaje da pati!

https://patternlab.io/

Razvoj van okruženja

Mogućnost razvoja aplikacije daleko od okruženja je jedna od mojih omiljenih funkcionalnosti. Previše puta mi se dešavalo da moram da prođem par koraka kako bih mogao da dođem do situacije u kojem komponenta na kojoj radim ima neki problem.

Situacije kao što su prolaženje par koraka u kreiranju narudžbine kako bih podesio neke karakteristike komponente kao što su senke ili padding, ili logovanje kako bih mogao da proverim da li radio dugmići imaju ispravnu validaciju.

Što se nakon svakog osvežavanja stranice mora uraditi iz početka.

U takvim situacijama inžinjeri ne mogu biti fokusirani 100% na razvoj funkcionalnosti što dovodi do toga da se troši previše vremena.

Zaključak

Patern biblioteke imaju mnogo prednosti koje svakom timu mogu dati dodatne performance. Mnoge od tih prednosti idu dalje od samog iskustva developera.

Prednosti kao što su redukovano vreme razvoja funkcionalnosti, i vremena koje je utrošeno na sam projekat.

Takođe, implementacije ovakve biblioteke dolazi i sa negativnim stranama.

Možemo da očekujemo da će vreme provedeno na razvoju komponenti na početku da bude malo duže zbog upoznavanja sa samim alatom, ali nakon što ceo tim prođe kroz te tehničke stvari, možemo očekivati da projekat bude stabilniji.

Možemo očekivati i da dođe to nekih turbolencija u samom načinu koji tim funkcioniše, kao i da pojedini članovi tima odbiju da prihvate promene.

Svakako, dosta toga zavisi i od agilnosti tima.

Where to start?

Trenutno postoji više “velikih” igrača u ovom polju, u zavisnosti od tehničkog “steka” koji projekat koristi.

U slučaju da koristite neki od popularnih JavaScript frejmvorka kao što su ReactJS, VueJS, EmberJS ili Angular, pogledajte Storybook.js.io.

Za projekte koji nemaju neki od frejmvorka, postoji rešenja kao što su Fractal.build, i patternlab.io koji mogu veoma lako da se implementiraju u bilo koji system.

Pogledajte neke od primera:

• Kanbasu
• City of Boston