Egyedi fejlesztésű, vagy ismert keretrendszert érdemes használnunk?

Mit gondoltok, megéri-e egyáltalán általánosságban véve keretrendszereket használni? Mik a legjobb PHP oldali, és frontend keretrendszerek, amik közül választhatunk? Ezekre keressük a választ. 

Sok alkalommal, mikor állásinterjúkra megyek el, sokféle elvárással találom magam szembe. Nyilván, sokféle elvárás lehet: általános tudástól, szemlélettől, konkrét technológiai tudásig sokminden, viszont sokszor szembetaláltam magam azzal, hogy a fejlesztés során nem jól ismert keretrendszerekkel kellene dolgozni, hanem egyénileg írt architektúrákkal, melyet teljesen egyedeiek, vagy pedig csupán részben használja más ismert keretrendszerek moduljait.

Jómagam is írtam már kisebb keretrendszert, és készítettem is vele applikációt. Illetve, használtam is már mások által létrehozott egyedi keretrendszert is. Vannak cégek, akik teljes mértékben az egyedi architektúrák felé hajlanak, míg más esetekben egy adott cégnél szinte minden projektet ismertebb keretrendszerekben készítenek el, és szerintük felesleges egyénileg írni egyet. 

A cikk nem csupán programozók számára lehet érdekes, ha te ügyfélként szeretnél egy rendelést leadni, akkor érdemes lehet tudni, hogy milyen hátulütői lehetnek az egyes választási lehetőségeknek.

Éppen ezért felmerülhet: érdemes-e egyedi keretrendszert használnunk? Mik alapján mérlegeljünk, mik lehetnek az előnyei? Hasonlítsuk össze az ismert, és egyedi keretrendszereket egymással.

Az szempontok összehasonlítása

Hivatalos dokumentáció

Az ismertebb keretrendszerek (Laravel, Symfony, Yii 2, CodeIgniter) kivétel nélkül részletes, és hivatalos dokumentációval rendelkeznek. Ezeket rendszeresen frissítik, és ha valami hiba van valahol, akkor azt világosan a tudtunkra fogják adni.

Egy egyedi keretrendszer esetén ez nem feltétlenül mondható el, sokszor nincs dokumentáció hozzájuk, ha a készítő például már nem dolgozik a cégnél, akkor nem biztos, hogy lesz kitől segítséget kérnünk. Egy kezdőbb számára sokkal egyszerűbb lehet egy rendezett, hivatalos dokumentációt használni, mint más kódjában "túrkálni", és kitalálni, hogy melyik függvény mire való.

Community-közösség

Egy ismert keretrendszer esetén, ha valamivel elakadunk, akkor jó eséllyel találni fogunk a Stack Overflowon választ a kérdéseinkre, nagyon sok alkalommal nem nekünk kell "kitalálni", mi lehet a megoldás, mert már számtalan alkalommal botlott valaki ugyanabba a hibába, mint mi.

Egyedi keretrendszereknél igaz, hogy nincs Community-tehát, nem kérhetünk segítséget senkitől egy hibaüzenetet látva-viszont, ha valami hibába ütközünk, akkor sokkal nagyobb esély van rá, hogy mi, a keretrendszer készítői azt megtaláljuk a kódot vizsgálva, mint egy ismert keretrendszer esetén. Ha egy ismert keretrendszerben valami hiba lenne, amire sehol nem találunk választ az interneten, akkor sokkal nehezebb lenne ennek fixálása, mint az egyedi fejlesztésű architektúra esetén.

Személyre szabhatóság

Az előbb feltüntetett ok mellett ez a másik, ami miatt nagyon sokan szeretik az egyedi fejlesztésű keretrendszereket: teljes mértékben személyre szabhatók, az igényeink szerint. Igaz, hogy több időbe telhet a különböző függvényeket, osztályokat rendesen definiálni, viszont soha nem eshetünk bele abba a hibába, hogy nem tudjuk a megfelelő módon személyre szabni azt, amit szeretnénk, amire az ügyfélnek igénye lenne.

Egy ismert, már készen létrehozott keretrendszer esetén egy szükséges módosítás sokkal költségesebb, és nehezebb lehet.

Biztonság

Az ismert frameworkok alapvetően nagyon jó securityvel rendelkeznek, szinte kivétel nélkül. Ennek nyilvánvalóan az az oka, hogy nagyon sok ember használja őket, és ezért maximálisan odafigyelnek arra, hogy ilyen téren ne lehessenek hiányosságok az applikációnkban. Illetve, ha van valami biztonsági rés, azt fixálják, és onnantól kezdve ez egyetlen installált projektben sem fog előjönni többet.

Az egyénileg készített keretrendszerekben sokszor komolyabb biztonsági rések is vannak: jelszavak tárolása, CSRF védelem, XSS támadás, Session kezelés, és a többi. Még ha egy cég sok éve is használ egy egyedileg készített struktúrát, sem lesz olyan jó securityja, mint egy olyan applikációé, melynek az alapját egy olyan rendszer képzi, aminek a folyamatos preparálásáért több száz fejlesztő felel, és kapnak folyamatos visszajelzéseket.

Ez természetesen nem jelenti azt, hogy nem lehetne biztonságos keretrendszert írni, de ilyen szinten az legfeljebb olyan teljesítményt fog nyújtani, mint ismert vetélytársaik.

Méret

Szintén egy komoly érv lehet a mai, jól ismert keretrendszerek ellen, hogy alapból óriási méretűek. Egy felinstallált Laravel keretrendszer például 60-80 MB-nyi helyet foglal el a szerverünkön, és akkor ott még semmilyen package nem került felinstallálásra. Összeségében véve, mindennel együtt meghízhat az applikációnk akár több száz MB-os méretre is.

Egy egyedi keretrendszer, melyet mi készítünk, rosszabb esetben sem fog 1-2 MB fölé lépni. A CodeIgniter például, egy "elég" alap ismert keretrendszernek számít, és és csupán 1-2 MB-nyi méretű alapból.

Az applikáció gyorsasága, optimalizáltság

Az betöltési idő általában véve gyorsabb egyedi keretrendszerek esetében. Mivel kisebb méretűek, ezért kevesebb dolog van, ami lassítja az applikáció működését. Ezen felül, sokkal optimalizáltabbak-pontosabban kevesebb optimalizálási hiba van bennük-mint az ismert keretrendszerekben. A Laravel Eloquentje például nem optimalizált annyira, nem fognak olyan gyorsan működni az adatbázis-lekérések mint egy kisebb, egyedi architektúra esetén lenne ez így.

A fejlesztés gyorsasága

A fejlesztés-véleményem szerint-alapvetően gyorsabb egy ismert keretrendszerben, mint egy egyediben. A Laravel Eloquentje például, amivel adatbázis lekéréseket, módosításokat lehet csinálni, rendkívül sok előre megírt, funkcióval rendelkezik, és mivel az "igények" sokszor nagyon hasonlóak programozók részéről, ezért ezekhez is igazítják az újabb verziókat.

Készített packagek

Az ismert keretrendszerek amellett, hogy egy jó "alapot" nyújthatnak számunkra, rengeteg, előre legyártott, felinstallálható packageval rendelkeznek, például: amivel profin lehet többnyelvű weboldalakat készíteni. Vagy, amivel lehet képek dimenzióban vett méretét meghatározni, a képeket "vágni", illetve méretükre optimalizálni. Ezeket sokkal több idő lehet egy egyéni fejlesztés keretében megvalósítani.

Betanulási idő

Az ismert keretrendszerek "learning curve"-ja sokkal kevésbé meredek, mint az egyedi keretrendszreké lehet. Rengeteg online fórum, oktató videó állhat a rendelkezésünkre az interneten, ha tanulni szeretnénk. Én annak idején, mikor elkezdtem fejlesztőként dolgozni, Laravellel dolgoztam, és nem igazán láttam át, hogy mit jelent az objektumorientált programozás. Egy egyedi keretrendszer megtanulása sokkal időigényesebb, és OOP szemlélet nélkül szinte nem is lehetséges. És pláne, akkor lehet nehezebb dolgunk, ha az architektúra készítője már nem dolgozik a cégnél.

A befektetett energia későbbi megtérülése

Egyszer, mikor arról beszélgettem egy Laravel experttel, hogy érdemes-e egyedi keretrendszert használni, azt mondta, hogy azért nem érdemes, mert a piacon sokkal rosszabb lehetőségeink lesznek később, ha a megszerzett tudásunkat nézzük. Lehetséges, hogy bekerülünk egy munkahelyre, ahol egyedi keretrendszerekkel kell dolgozni, és a cég át szeretne állni ismert architektúrák használatára, viszont a nagyobb projektet, amin éppen mi dolgozunk, még valakinek végig kellene vinnie, és folyamatosan fejlesztenie. 

Egy ilyen helyzetben jó eséllyel az fog történni, hogy felvesznek valakit a céghez, aki ismeri az adott keretrendszert, mi pedig foglalkozhatunk a régivel, ugyanis mi vagyunk azok, akik azon el vagyunk képesek igazodni. És a következő állásinterjún jó eséllyel nem minket fognak választani, hanem azt az embert, akit mellénk felvettek, hogy ismert keretrendszerekkel dolgozzon: ugyanis ez az elvárás a legtöbb helyen.

Összegzés

Összeségében véve arra a kérdésre, hogy melyik a jobb választás, a válasz: attól függ. Attól függ, hogy milyen fejlesztést kellene kivitelezni. Komplexebb projektekre a keretrendszerek használatát sokszor érdemes elvetni, mert lehetséges, hogy valamit nem lehetne vele kivitelezni, amire igénye lenne az ügyfélnek később.

A felsorolás alapján, talán úgy tűnhet, hogy rengeteg munka van egy ilyen egyedi fejlesztésű keretrendszer elkészítésével: viszont ne felejtsük el, hogy ezt elkészíteni csupán EGYSZER kell. Egy cégnél, ahol a projekteket ilyenekben kivitelezik, nyilván az összes projektet ugyanabban, az egyszer megírt keretrendszerben készítik el.

Véleményem szerint egyik sem jobb mint a másik, én inkább ismert keretrendszerekkel szeretek dolgozni. Érdemes lehet tisztában lennünk azzal, hogy melyek a legjobb PHP oldali keretrendszerek, ha éppen backenden gondolkodunk. Frontendre az Angular, React, és Vue valamelyikét szokták javasolni.