Mást sem látni az álláshirdetési portálokon csak, hogy #keretrendszer #MVC #Laravel #Spring #Codeigniter #Yii #Angular #React. Mostani cikkünkben átbeszéljük mi is ez, miért jó, vagy miért rossz ez, illetve az is kiderül, hogy szükséges-e egyedi keretrendszert megalkotni a mai „keretrendszerekkel teli” világba.
Nézzük, miről lesz ma szó:
- Kezdő programozók és a keretrendszerek kapcsolata. Ezért ne ugorj fejest egyből egy keretrendszerbe.
- Milyen keretrendszerek léteznek? Mindet meg kell tanulnom? Honnan tudjam, hogy melyiket érdemes megtanulni?
- Az IT típusú álláshirdetések leggyakoribb kritériuma: keretrendszer ismeret, MVC
- Beszéljünk kicsit a szoftverarchitektúrákról (vagy mondhatnám, hogy a szoftver architektúra mintákról)
Kezdő programozók és a keretrendszerek kapcsolata. Ezért ne ugorj fejest egyből egy keretrendszerbe.
Néhány évvel ezelett a cég ahol dolgoztam több pályáját kezdő programozónak is lehetőséget biztosított a tapasztalatszerzésre, így megindult az érdeklődők interjúztatása.
Néhány hét alatt összesen 16 kezdő, illetve junior szintű tudással rendelkező PHP fejlesztőt interjúztattam, ami azért fontos, mert jó tanulságokkal gazdagodtam az interjúk álta.
Ugyebár kezdő fejlesztőként, adott esetben az első interjúkon részt vevő lelkes fejlesztők érkeznek az állásinterjúkra. Van aki megfelelő alapokkal rendelkezik PHP nyelvből, mások Java programozási nyelvből, esetleg valakinek a JavaScript lett az útja.
Amikor ez a tudás tényleg magabiztos és készség szintű az már egy nagyon jó kiindulási alap, biztos sokat hallottad, hogy „lehet rá építeni”. Ez valóban így van. Ez kedő fejlesztőnél elsősorban azt nézik a felvételnél, hogy mennyire lehet építeni az alaptudásra.
Apropó, ha most kezded a programozás tanulást, mindenképp olvasd el 6 tanácsunkat a programozás tanulás sikerességéhez, hogy valóban jó alaptudás alakuljon ki benned a tanulmányaid során.
Volt egy nagyon elszánt, kezdő programozó jelentkezőnk, akitől megkérdeztem, hogy esetleg a tanulmányai, vagy példaprojektjei során használt-e valamilyen keretrendszert. A következő választ kaptam:
Nem használtam keretrendszert, nem nagyon értem mire jó az, én mindent megoldok sima kódolással, szerintem semmi értelme vele elbonyolítani a kódot.
Azt mondanom sem kell, hogy a kicsit „nem érdekli a dolog” stílus lepett meg, nem az, hogy még nem ismerkedett meg a keretrendszerekkel. Úgy utasított el egy számára még nem ismert technikai tudást, hogy azt valójában nem is ismerte. Kicsit azért próbáltam meggyőzni és a következő kérdéseket tettem fel neki:
- A projektjeid, mintaalkalmazásaid osztályai (leegyszerűsítve kódot tartalmazó fájl) hány sorból állnak?
- Kis idő elteltével, ha valami javítani kell a kódban, akkor mennyi idő megy el a kód újraértelmezésével?
- Ha átadnád a kódod egy programozó kollégádnak, szerinted ő mennyire tudna eligazodni rajta?
Sajnos már az első válasszal meg is válaszolta önmagának, hogy többek között miért is célszerű és hasznos a keretrendszerek alkalmazása. A válasz a következő volt: Az egész kód egy index.php fájlban van, ami 3000 soros. Ezt kezdőként is biztosan érezzük, hogy ez így nem a legmegfelelőbb.
Ezért (is) alkalmazunk keretrendszereket az IT iparban.
Ott akkor abban a pillanatban nem tudtam kifejteni a részletes válaszom az időbeli keretek miatt (napokig lehetne a témáról értekezni), de most ez pótolom és megosztom minden érdeklődővel, hogy miért is olyan felkapott a keretrendszerek alkalmazása a programozás során.
- Ún. boilerplate kódok (olyan kódrész, ami nagyon gyakran előjön minden projekt esetén) lefejlesztésével nem kell húznunk az időt. Napokat, heteket spórolunk meg ezeknek a kész kódrészeknek a felhasználásával. Ilyen például: a request – response kezelés, a routing kezelés – clean url-ek alkalmazása, adatbázis – és fájlabsztrakciós műveletek, alkalmazás biztonság (pl.: SQL Injection, XSS védelem), stb… Kismillió ilyet lehetne felsorolni, de nem is ez a cél most.
- Egy kicsit kiemelném a biztonságot. Az SQL és XSS támadások, mappavédelmek, azonosítással elérhető tartalmak leggyakoribb hibalehetőségeit, a request / response manipulálást megakadályozó műveleteket mind-mind biztosítja egy keretrendszer. Míg egy core nyelven (pl.: PHP, Java) megírt alkalmazásban ezeket mind–mind magunknak kell lefejleszteni, ami viszont kezdőként elképesztően nagy erőfeszítést jelent. Ugyanakkor azt állítom, hogy egyszerűen nem rendelkezünk kezdőként olyan tapasztalatokkal, hogy ezt megfelelő minőségben megalkossuk. És valljuk be, az egyik legfontosabb a szoftver biztonsága.
- A másik fontos jellemzője az OOP és MVC alkalmazása. Őszinte leszek, én még olyan keretrendszert sem PHP sem Java nyelven nem láttam, ami nem OOP (Java-nál más nem is lehet) és nem MVC alapú. Az OOP objektum – orientált programozást jelent, amiről most kezdőként nekünk elegendő annyi, hogy az alkalmazás működése egymással kommunikáló objektumok halmaza. Az MVC-t pedig lejjebb kifejtsük.
- Amit nagyon szeretek a keretrendszerekben, hogy egy centralizált, jól átlátható adatbázis kezelési művelettel rendelkezik és egy megfelelően menedzselt adatbázis absztrakciós réteget biztosít az adateléréshez és adatfeldolgozáshoz. Pl.: php esetén az eloquoent, java esetén pl.: Hibernate, MyBatis. Egy üzleti alkalmazásnál pedig beláthatjuk, hogy az alkalmazás random pontjain nyitott adatbázis csatlakozások, a natív PDO műveletek rengeteg kódismétléshez és „elfogyó” adatbázis kapcsolatokhoz vezetnek. És még az adatbázis migrációs műveletekről nem is beszéltem.
- Végül az egyik, ha nem a legfontosabb. Amikor egy fejlesztő csapatba új tag kerül, akár hónapokkal gyorsabban is bele tud tanulni a rendszerbe, ha egy ismert keretrendszeren alapszik az alkalmazás. Gondoljunk bele, egy teljesen egyedi, vagy natív kódbázisú alkalmazásnak még az eredeti programozójának is kihívás, mikor visszatér rá.
Még biztosan sok előnyt, könnyebséget fel lehetne sorolni, de most nem feltétlen írnék erről hosszasan, hiszen hamarosan úgyis biztosan kapcsolatba kerülsz Te is egy keretrendszerrel, vagy már lehet, hogy valamelyiket használod is.
Inkább foglaljuk most össze, hogy mi az a programozási keretrendszer, framework: A programozási keretrendszerek olyan natív nyelven megírt alkalmazások / kódrészek, melyek alkalmazása a valós üzleti életből vett projektek esetén szinte kivétel nélkül előfordul.
Ne a keretrendszerekkel kezdjük a tanulmányainkat
Ami viszont nagyon fontos, hogy ha most kezded a programozói tanulmányaidat egy jó ideig ne is kezdj bele a keretrendszerek témába. Mondom miért.
Amíg nem ismered a natív nyelv alapjait, addig a keretrendszer logikáját, architektúráját nem fogod érteni, nem lesz rálátásod, nem tudod, hogyan működik. Ez nagymértékben rombolja a tanulmányi kedvet és az ember hajlamos lehet a feladásra.
Úgy szoktam mondani, hogy át kell esni a natív nyelv nehézségein, szellemi erőforrásigényes megismerésén. Ugyanis a nagy keretrendszerek is mind-mind a natív nyelv alapjaira vezetjők vissza. Ezért nagyon fontos, hogy előbb lásd és értsd az alapokat, majd aztán tudsz tovább lépni az alapokon nyugvó, haladóbb technikákra.
Milyen keretrendszerek léteznek? Mindet meg kell tanulnom? Honnan tudjam, hogy melyiket érdemes megtanulni?
Elsősorban azt kell megállapítani, hogy frontend, vagy backend fejlesztéssel foglalkozol. Ha esetleg a fullstack (mind frontend, mind backend feladatok elvégzésére alkalmas) irányt képviseled, akkor ajánlott legalább 1 frontend és legalább 1 backend keretrendszert is ismerned.
Frontend fejlesztés keretrendszerek
A legnépszerűbb frontend fejlesztési keretrendszerek, amikkel az állásportálok is tele vannak: React, Angular, Vue.js, de érdemes megnézni a 10 legnépszerűbbet, előnyeiket, hátrányaikat, mielőtt valamelyikbe csak úgy hirtelen belecsapunk.
Véleményem szerint az Angular nehezebben tanulható a React – nál, a Vue.js pedig könnyebben tanulható mind az Angular-nál, mind a React-nál. Amivel pedig annó én kezdtem az a jQuery (bár ezt inkább mondanám függvénykönyvtárnak, mint teljes értékű keretrendszernek), de kétségtelen, hogy a mai napig méltán népszerű.
Amit a tapasztalatok és az állásportálok mutatnak az kétségtelenül az, hogy valóban, ügyes képzett frontend fejlesztőket elképesztően nehéz találni, ezért beszélhetünk már junior – ként is nagyon komoly kezdő fizetésekről.
Ha a frontend a Te irányod, rendelkezel magabiztos JavaScript ismeretekkel, akkor ajánlom, hogy egy népszerű keretrendszerrel kezdj el foglalkozni, illetve „húzz még rá egyúttal” egy stílusfejlesztéssel kapcsolatos nyelvet is (SCSS, SASS, LESS) és biztos vagyok benne, hogy egy olyan ütős páros lesz a kezedben, amivel a mostani munkahelyemen is rögtön 3 embert felvenne a cég. De nagyon fontos, hogy az alapokkal, azaz a natív nyelvvel kezd frontend esetén is: JavaScript, CSS, HTML.
Backend fejlesztés keretrendszerek
Nekem ez a kedvenc témám, de ez most másodlagos. Nézzük, hogy mivel vannak elárasztva a hazai állásportálok backend területen.
Először nézzünk néhány népszerű PHP keretrendszert: Laravel, Symfony, Yii, Codeigniter, Phalcon, Zend
És néhány Java keretrendszer: Spring, JSF, Vaadin
Én személy szerint a Laravel-t, Lumen-t, Yii-t használom, Java esetén pedig kivétel nélkül a Spring-et. A jó hírem, hogy kezdőként nem kell többet ismerned a fentiek közül. Ha PHP fejlesztőként szeretnél elhelyezkedni, akkor nincs szükség Java keretrendszerre és ez fordítva is igaz.
Az évek során, mikor már több éve dolgozol úgyis előfordulhatnak olyan esetek, hogy esetleg megtanulsz egy új nyelvet is. Ilyenkor azon a nyelven is biztosan el fogsz mélyülni egy új keretrendszerben.
Az, hogy éppen melyik keretrendszert érdemes megtanulni, arról a munkaerő kereső portálok adnak naprakész információt, de én biztos vagyok benne, hogy a PHP – Laravel, vagy a Java – Spring páros az mindig egy jó párosítás lesz.
De tudod mi a legjobb ezekben a keretrendszer dolgokban? Ha egyet becsülettel megtanulunk, akkor a következőt már nagyságrendekkel egyszerűbb lesz megtanulni. Ez azért van, mert alapvetően mind az MVC tervezési mintára épül, alkalmazzák a tanulmányok során oly sokszor előkerülő S.O.L.I.D elveket és programtervezési mintákat.
Így, ha az alapelveket ismerjük, nagyjából már csak az adott keretrendszer sajátosságait kell kiismernünk, ami egy – egy példaprojekttel tökéletesen abszolválható.
Az IT típusú álláshirdetések leggyakoribb kritériuma: keretrendszer ismeret, MVC
Amikor fellapozunk egy álláshirdetés portált a legtöbb fejlesztői pozíciónál a következő kulcsszavakkal biztosan találkozni fogunk:
- Legalább egy keretrendszer magabiztos ismerete
- MVC tervezési minta ismerete
Ezek a kritériumok elég alapnak számítanak és bizony érthető is. Ha még most nem is látod teljesen, hogy ez miért hasznos, biztos vagyok benne, hogy ha beleásod magad ebbe a témába azt fogod mondani magadnak, hogy bárcsak előbb tanulmányoztam volna ezeket a keretrendszereket.
Talán az egyik legfontosabb ezen kritériumok megléte, hogy egy olyan szoftvertermék álljon elő a fejlesztők által, amit egy másik fejlesztő is gond nélkül, rövid időn belül fel tud térképezni, átlátja és folytatni tudja a termék fejlesztését.
Nagyon nagy anyagi erőforrás lenne egy munkáltatónak, hogy egy szoftvert a nulláról újrakezdjen csak azért, mert az új munkatárs nem ismeri az alap kritériumokat és nem tud eligazodni a kódban.
Ugyanakkor azt is hozzá kell tenni, hogy a programozói lustaság sajnos jelen van. Hiába a keretrendszer, hiba az MVC, hiába az alap programozási paradigmák, ha a fejlesztők nem tartják annak szabályaihoz magukat.
Beszéljünk kicsit a szoftverarchitektúrákról, mi az az MVC
Már a cikkünkben is több helyen előjött az MVC betűszó, de tegyük most ezt helyre, hogy mi is ez. Ahhoz, hogy ezt megértsük, kicsit beszélnünk kell a szoftverarchitektúra fogalmáról.
Minden piaci szoftver fejlesztésének kezdetét (jobb esetben) a szoftver architektúra megtervezése előzi meg. Ezt leginkább a senior fejlesztők, architektek alkotják meg, figyelembe véve a vízionált szoftver sajátosságait.
A tervezés során nem magunktól kell kitalálni kódstruktúrát és szoftverarchitektúrális modelleket, hanem vannak olyan előre definiált szoftverarchitektúrális minták, melyek jó eséllyel ráilleszthetők a készülő szoftverre.
A szoftverarchitektúrális minták (figyelem: nem keverendő a programtervezési mintákkal!) olyan a készülő szoftver szerkezeti felépítését, az egyes alrendszerek kommunikációjának módját és eszközét, szabályait határozzák meg.
A megfelelő mintának a kiválasztása a nagy feladat, de nézzünk is meg párat:
- Layered pattern: Egymással kommunikáló rétegek halmaza, ahol minden réteg speciális feladatot hajt végre, amit az utána következő réteg felhasznál.
- Client – Server pattern: Ebben az esetben vagy egy szerverállomás, aki figyeli a rá csatlakozó kliensek kéréseit és kiszolgálja azokat. Egyfajta üzenetváltás zajlik le: a kliens azt mondja, hogy „add ide ezt az adatot”, a szerver pedig azt mondja, hogy „kliens, itt az adat, amit kértél”
- Master – Slave pattern: Ebben az esetben van egy kitüntett szerepű entitás (főnök), ami megmondja a „dolgozóknak”, hogy mire van szükség. Minden dolgozó minden információval 100%-ban rendelkezik, így mindig releváns adatot adnak a „főnöknek”, aki összeállítja a végeredményt.
- Broker pattern: Ilyen az ún. bróker pontosan tudja, hogy az általa menedzselt szerverek mire képesek, milyen feladatot tudnak végrehajtani. Amikor jön egy kérés, azt megnézi a bróker, látja mi a feladat és azt továbbadja a megfelelő brókernek, ezzel elérve egyfajta terhelés elosztást.
- MVC pattern: Az egyik legsűrűbben használt és emlegetett szoftverarchitektúra, amit kicsit részletesebben tárgyalunk.
Az MVC tervezési minta
Először is az MVC az egy rövidítés, ami a Model – View – Controller kifejezésből származik. Nézzük mit mond a Wikipédia az MVC fogalmáról:
Összetett, sok adatot a felhasználó elé táró számítógépes alkalmazásokban gyakori fejlesztői kívánalom az adathoz (modell) és a felhasználói felülethez (nézet) tartozó dolgok szétválasztása, hogy a felhasználói felület ne befolyásolja az adatkezelést, és az adatok átszervezhetők legyenek a felhasználói felület változtatása nélkül. A modell-nézet-vezérlő ezt úgy éri el, hogy elkülöníti az adatok elérését és az üzleti logikát az adatok megjelenítésétől és a felhasználói interakciótól egy közbülső összetevő, a vezérlő bevezetésével. Forrás: Wikipédia
A fenti „definíció” tökéletesen lefedi az MVC jelentését, de kezdőként azért érdemes ezt egy kicsit kirészletezni: olyan szoftverarchitektúráról van szó, ami éles határ húz az adatbázis műveleteket megvalósító logika, az üzleti logika és a felhasználók elé tárt felületek, eredményhalmaz megjelenítési logikája között.
Tehát három rétegről beszélünk, melyek közül 1-1 módosítása nem okozza a többi réteg változtatási szükségességét.
Model
Ez az az objektum, ami vándorol az adatbázis, az üzleti logika és a megjelenítési réteg között. A legalsó szinten áll össze a tartalma, amikor az adatbázisból megtörténik az adatlekérdezés, vagy valamilyen adatmanipulációs művelet. Mondhatjuk úgy is nagyon sarkítva, hogy egy adatbázis tábla maga a model osztály, az adatbázis tábla mezői pedig a model osztály adattagjai (property). Ez az adatmodell, vagy más néven model, megint más néven Entity átkerül a vezérlő rétegbe, azaz a controllerbe.
Controller
A kontroller, vagy más néven vezérő, pontosan tudja, hogy mit igényelt a kliens (request), azaz a felhasználó. Ez alapján „szól” a model, vagy más néven repository rétegnek, hogy éppen most milyen adatra van szüksége. Amikor a model réteg átadja a szükséges adatot (modellt, modellkollekciót) a vezérlőnek, az még „elvégzi az utolsó simításokat”, amivel olyan alakra transzformálja az adatokat, hogy az megfeleljen a felhasználó kívánalmainak. Amint összeállt ez a transzformált adat, tovább adja a megjelenítési rétegnek (response).
View
A view, vagy más néven a megjelenítési réteg az az absztrakciós szint, ahol a felhasználó valamilyen interakciós művelet alapján (scroll, kattintás, enter, input kitöltés) utasítást ad a program vezérlőjének, hogy „ezt meg azt” csinálja meg. Illetve ez az a réteg, ahol a felhasználó számára igényelt adat humánus, design-os, letisztult felületen, pl. egy táblázatban megjelenik (nem pedig egy json dump).
A fentiekből is látszik, hogy az MVC működése egy olyan körforgás az adattárolás és megjelenítés között, ami külön szinteken jelenik meg úgy, hogy egyik szint módosítása sem befolyásolja a másik szint működését.
Ez azt jelenti, hogy pl. a megjelenítési rétegben, ha bootstrap 3-mat használunk, de át szeretnénk térni bootstrap 4 – re, ahhoz nincs szükség a vezérlő és adatmodellező rétegek fejlesztőire. De ugyanez elmondható a többi szintre is. Ha esetleg MySQL adatbázisról áttérnénk PostgreSQL adatbázisra nincs szükség a megjelenítés módosítására, elég csupán a model rétegben az új adatbázis csatlakozási beállításait és az adatbázis típusát megadni (feltételezzük, hogy valamilyen ORM rendszert használ a szoftverünk).
Van egy nagyon jó hírem. Akár java nyelvű keretrendszert, akár PHP nyelven írt keretrendszert használunk az MVC szinte kivétel nélkül biztosított bennük. Ezért könnyebb nagyságrendekkel egy olyan szoftveren dolgozni, ami megfelel az MVC tervezési minta szabályainak, alkalmazza a S.O.L.I.D elveket és a szükséges tervezési mintákat (design patterns).
Az örök dilemma, érdemes-e saját keretrendszert fejleszteni?
Erre lehet adni egy elég egzakt választ: Abban az esetben éri meg egyedi keretrendszert fejleszteni, ha valós megoldást kínál a jelenleg piacon lévő keretrendszerek problémáira.
Lehet az a probléma biztonság, vagy betöltési sebesség, alkalmazott szoftverarchitektúra, de az is lehet, hogy a csapatunkkal megfogalmazódott bennünk egy olyan tény, hogy bizony a készülő szoftver igényeit csak egyedi keretrendszer fejlesztésével kielégíteni.
Egy nagy hátránya van ennek, mégpedig az, hogy egy új ember, aki esetleg elkezd a projekten dolgozni, sokkal több idő lesz átlátnia a teljes alkalmazást, még akkor is, ha programozás technikailag az kifogástalan.
Ugyanakkor nagyban elősegítheti egy új kolléga munkáját az, ha az egyedi keretrendszer kellően dokumentált, betartja a szakmai standard-eket (Design Pattern-ek, S.O.L.I.D elvek alkalmazása, megfelelő adatbázis absztrakció.
Egy dologra viszont óva intelek kezdő fejlesztőként. Ne kezdj bele egy keretrendszerbe a nulláról. Nagyon komoly architektúrális tervezést, felhasználói felület tervezést és sok éves gyakorlatot igénylő feladatról beszélünk, ami könnyen végződhet kudarccal tanulmányaink elején.
Viszont ha már szereztél néhány év tapasztalatot, akkor pedig mindenképp ajánlom, akár egy egyszerűbb keretrendszer fejlesztését, hiszen azzal olyan haladó technikákat fogsz érinteni, ami idővel a senior, architekt tudásszintnek nélkülözhetetlen alapja lesz.