Weblabor

Szia!

Nem árt ha az ember ismer "keretrendszereket". De. Nekem ezek a keretrendszeres dolgok a PHP-hoz mostanában már picit a könyökömön jönnek ki, egy újabb divathullám ami elérte a PHP-t. A keretrendszerek háborúja! Nem hiszem, hogy valaki jobb vagy rosszabb fejlesztő lenne A Keretrendszerek ismerete nélkül, ugyanakkor az sem igaz, hogy ezek a rendszerek rosszak lennének és ártana a használatuk a kreativitásnak, egyetértek a cikk írójával abban, hogy növelhetik a kreativitást és alakíthatják a szemléletet, de nem lehet ebből egy általános törvényt gyártani sem végső Nagy Konklúziókat levonni... Én a Symfonyt ismerem legjobban ezek aközül a "keretek" közül, készítettem benne "igazán nagy" rendszert, de előtte keretrendszerek nélkül - több céges (belső) és saját kódgyűjteménnyel is készítettem, illetve vettem részt "nagy" rendszerek fejlesztésében. Soha nem a keretrendszereken múlik ha rossz a végeredmény... :)

Nekem az a kérdésem, hogy mit NEM lehet ezekkel megcsinálni? Brutális SEO praktikák, sebességoptimalizálás, <és még amik most nem jutnak eszembe>, stb?

/me = mindent-nulláról php kiddie

Ez a téma részemről már nem a fórum keretei közé való, mert erről érdemben egy hosszú délután alatt, több sör társaságában lehetne beszélgetni.

Nos, akkor "röviden" megfogalmaznám, hogy mit is akartam kihozni abból, hogy saját keretrendszert használok, nem egy népszerűt. Én alapvetően olyan ember vagyok, hogy meg akarom érteni, hogy mi hogyan és miért úgy működik ahogy (ergo azt, amit a keretrendszer elfed előlem). Ez egyrészt jó hozzáállás, másrészt így el lehet veszni a részletekben, adott esetben kevésbé produktívnak lenni. Viszont hosszabb távon megtérül a miértek megismerése.

Főként azért használok saját megoldásokat, mert az idők során kialakultak bizonyos rutinok. Namost ezek a folyamatok nem úgy vannak jelen az egyes nagyobb keretrendszerekben, mint ahogy én használom őket. Amikor egy project-en dolgozik az ember, akkor nincsen ideje megtanulni pl. a Symfony-t, hogy őt használja, mint keretrendszer. Persze, amennyiben a megrendelő olyan, hogy távlatokban tud gondolkodni, hallgat a fejlesztőre, hogy érdemes erre vagy arra a keretrendszerre alapozni egy project-et, akkor bele lehet kalkulálni azt az időt, amíg a fejlesztő legalább az alpokat megismeri és elkezdi a project-et. Így meg lehet tanulni éles környezetben egy keretrendszert. Viszont eddigi munkáim olyanok voltak, hogy mindent tegnapra akarnak, ezért munkaidőben nem volt energiám megtanulni egy keretrendszert sem.

Viszont amikor már eljutottam egy olyan fejlettségi szintre, hogy komolyabb alapokra szeretném helyezni a saját kódomat, akkor belelestem pl. a CakePHP-be, Smarty-ba, hogy mit hogyan oldottak meg (anno a saját template engine fejlesztésekor).

És itt jön a lényeg. Ahogy egyre összetettebb feladatokat kell megoldanom időről-időre előjönnek azok az igények, amiket az egyes keretrendszerek megvalósítanak. Ekkor utánaolvasok, keresgélek neten, hogy adott problémát hogyan lehet megoldani. Próbálom adaptálni a rendszerembe. Biztos, hogy nem lesz olyan jó a megoldás (bár ezt nem jelenthetjük ki egyértelműen), mint a nagyobb keretrendszerekben lévő profi kivitelezés, de meg fogom érteni, hogy a keretrendszer fejlesztői, adott dolgot miért is úgy csináltak ahogy. Példával élve: jó dolog az ABS az autóban, csak mondjuk érteni kell, hogy az miért van, hogyan működik, meg hogyan kell vele fékezni.

Ahogy haladok előre az időben, egyre bonyolúltabb feladatokkkal találkozom és egyre letisztultabb alaprendszert akarok építeni a saját megoldásaimból, folyamatosan találkozom a keretrendszerekben megvalósított problémákkal. A napokban például rájöttem, hogy miért is jó mondjuk az ADOdb, vagy miért vannak bizonyos funkciók úgy megvalósítva Smarty-ban ahogy. Ez olyan dolog, hogy aki PHP-vel ismerkedik és találkozik a változó nevű változókkal, látja, érti, hogy mi az, de fingja nem lesz róla, hogy a gyakorlatban ezt mire tudja majd használni. Én is csak bő fél éve jöttem rá, hogy miért is jó ez nekem. Volt egy gyakorlati probléma, ahol dinamikusan kellett létrehozni objektumokat és ekkor jött jól a dolog. De előtte fogalmam sem volt róla, hogy ezt a lehetőségét a PHP-nek mire lehetne felhasználni. Jó dolog a Smarty, de ha kismillió dolgot tud, én viszont nem használom ki, akkor majdnem felesleges a használata. Most találkoztam egy gyakorlati problémával, utána néztem Smarty doksiban, hogy ezt hogyan oldják meg és így megértettem, hogy miért is ilyen funkciógazdag a Smarty. Így már tudtam adaptálni a dolgot a saját rendszerebe, a logikát át tudtam ültetni.

Ez az egyész egy tanulási folyamat. A keretrendszer ad egy olyan környezetet ahol produktívan lehet dolgozni, mert elfedi az ember elől azokat a dolgokat, amivel sz*pás lehet. Én olyan ember vagyok, hogy meg akarom tudni, hogy mit fednek el előlem, mert ezzel úgy gondolom, hogy jobban fogom majd használni / kihasználni a keretrendszer lehetőségeit, valamint ha speciális igény jelentkezik, akkor hamarabb tudok lépni.

Azt is említettem, hogy a keretrendszer használata lényegében (megítélésem szerint) egy elég profi hozzáállás. Annak nem érdemes ajánlani egy keretrendszert, aki még nem ismeri eléggé PHP-t, az OOP-t, a WEB-es világ működését, mert bár használni fogja a keretrendszer közel sem biztos, hogy jó minőségű kódot ír.

Én sz*pok a saját rendszeremmel, folyamatosan fejlesztem és időről-időre rájövök, hogy miért is vannak bizonyos dolgok úgy a nagyok rendszereiben, ahogy. És amikor megvan már az alapvető elméleti és gyakorlati tudás, akkor fogok áttérni egy komplex keretrendszerre, mert akkor már ki tudom használni és nem csak használni fogom.

Ami a Symfony tanulását illeti, minden nagyképűség nélkül mondhatom, hogy nem jelentene problémát megtanulni Symfony-val fejleszteni, csak éppen jelenleg nem akarok. Egyrészt, mert rájöttem, hogy a programozás nekem örök szerelem, de nem ez a hivatalásom – bő 10 évvel ezelőtt még úgy gondoltam, most már más dolgokban látom a hivatásomat, de ez magán jellegű dolog; egy-két sör mellett erről is lehetne beszélgetni –, másrészt meg sok elméletet kellene olvasnom hozzá (pl. OOP tervezési minták), amire most nincsen időm (hogy miért, ez megint magán jellegű dolog).

Remélem így már érthető a hozzáállásom a dologhoz.