programozók, kések és keretrendszerek

Előszöris remélem senki nem veszi tolakodásnak, ha egy kicsit kisajátítok egy fórum témát. Mentségemre szóljon, hogy a többség valahol az én hozzászólásomhoz reagált. Sokat fogok most ollózni, de igyekszem minél szabatosabban fogalmazni és pontosan kifejteni a véleményemet. A téma alapjául egy blogmark szolgált, de a bejegyzéssel olyan szinten nem értek egyet, hogy linket sem adok neki. A Weblaboros beszélgetés viszont itt elolvasható: http://weblabor.hu/blogmarkok/103683.

programozók és kések

Kezdeném ott, hogy legfőbb vitapartnerem szerint két féle programozó van: a favágó, aki konvenciókat keres és keretrendszert használ, és a művész, aki kihívásokat keres és megoldásokat alkot. Tiszteletben tartva a véleményét és ígérve, hogy nem citálom őt többet itt elő, én mégis máshogy csoportosítanék.

  • Én azt gondolom, hogy először is vannak a kezdők és spagettihuszárok. A kezdőkből természetesen bármi lehet később, a spagettihuszár, aki hosszú évek óta képtelen az érdemi fejlődésre. Ők azok, akik sosem szánják rá az időt, hogy megismerjenek új eszközöket. Jellemzően azt hiszik, PHP-ban programozni az tud jobban, aki több függvényt ismer a doksiból, vagy előbb meg tud írni egy 100 soros programot úgy, hogy nem dob hibaüzenetet. Őket valószínűleg el kell fogadni olyannnak amilyenek és menekülni tőlük ahogy lehet. Idegennek a munkájukba belejavítani tilos és életveszélyes...
  • Aztán vannak a haladók, akik olvasgatnak mindenféle okos dolgot, tanulnak a jobbaktól, összerakják a kis elemeket és és fejlesztgetik a saját toldozott-foltozott rendszerüket. Sokszor abba az álomba ringatják magukat, hogy a több megabájtos keretrendszerek használatának elkerülésével, sokkal gyorsabb programot kap a felhasználó, kevesebb áramot fogyaszt a vas és mivel ők már olvastak ilyen-olyan biztonsági résekről is, ezért "tudják", hogy ők már védve vannak. Gyakran említik azt is, hogy a nyílt forráskódú cuccokban bárki könnyen talál hibát, ráadásul még publikálhatják is a réseket, így egy potenciális támadónak csak meg kell keresnie egy foltozatlan hibát. Bezzeg a jó kis sufnituning admin oldal mindig működni fog. Ebben ugyan elvileg lehet is igazság, de szerintem 99%-uk sosem futtatott egy tesztet sem, sem Unit, sem biztonsági tesztet. Illetve hasonló százalékban lehetnek ők magányos farkasok is, már a munkát illetően. Ha már elvégeztek egy munkát, akkor az valószínűleg azért többé-kevésbé rendben van, de ha egy kicsit is fontos a projekt, akkor érdemes portolni a régi tartalmat, különben az ember csak a haját tépi az egyedi megoldások "szépségén".
  • Aztán vannak a rajongók. Mint az élet minden területén, itt is vannak, akik egy keretrendszer elkötelezett hívei és isten se tudná meggyőzni őket, hogy nem biztos, hogy ugyanaz a rendszer a legjobb választás mindenre. Jobb esetben ez azért egy elismert és komoly rendszer, ez esetben valószínűleg megéri megtartani és használni, amit átveszünk tőlük, feltéve, hogy az nagyjából legalább működik. Ők általában szívesen segítenek azoknak, akik most találták meg rajongásuk tárgyát és igyekeznek a haladókat is annak használatára buzdítani. Publikálni ritkán szokták, de kisebb-nagyobb módosításokat végeznek a keretrendszerükön.
  • Vannak az igazi használók, akik kipróbálgatnak mindent, ami felkelti az érdeklődésüket és azt használják, amelyiket az adott szituációban a legjobbnak találnak. Közölük sokan hozzá is tesznek egy-egy rendszerhez, esetleg publikálják is a tapasztalataikat, arra viszont kevésnek van ideje, hogy kezdőknek segítsen. Csapatban szívesen dolgoznak, de még nem feltétlenül ők a vezetők.
  • Végül pedig vannak a guruk, akik nem csak kenik-vágják a legjobb praktikákat, de össze is tudják szedni a gondolataikat, projektmenedzsmentben is otthon vannak. Képesek precízen kitalálni a céljaikat, megvitatni a tapasztalatokat és végigvinni egy komoly fejlesztést.

Na most, ha az a kérdés, hogy ezek közül melyik a favágó és melyik a művész, én nem tudnám megmondani. Érzem, hogy nem tökéletes az asszociációm, de nekem kicsit olyan ez, mintha azt kéne eldöntenem, hogy kést készíteni vagy a késsel fát faragni nagyobb művészet-e. Vagy épp aligha jutna valakinek eszébe, hogy egy faragott fa értékét a kés művészi értéke befolyásolja. Na de mindegy is. A lényeg, hogy kést a guruk és a haladók készítenek, a kezdők és spagettihuszárok fel se fogják, hogy mi az, a többiek pedig választanak egy szép kést és farigcsálnak. Ráadásul nem biztos, hogy csak a költséghatékonység miatt, lehet, hogy nem jó késkészítők vagy épp pont ez untatja őket...

keretrendszerek

És akkor most szépen, szájbarágósan összeollózom, hogy miért kell nekünk keretrendszer.

mit tudnak?

  1. Kialakítanak egy jó struktúrát a létrehozandó programnak. (Tipikusan MVC valamilyen továbbfejlesztéssel)
  2. Meghatároznak egy egységes kódolási stílust.
  3. Adnak egy sor hasznos modult, osztályt, függvényt.
  4. Jól dokumentáltak. (Legalábbis remélhetőleg)
  5. Automatizálnak sok biztonsági megoldást és könnyen elérhetővé tesznek továbbiakat.

kellenek ezek?

  1. Az átgondolt struktúra nekem megúszhatatlannak tűnik, mert fontos, hogy a fejlesztő mindig tudja, hogy mit hol talál, akkor is ha nem ő írta az adott részt. Persze tömegével látni még mindig olyan szoftvereket, hogy minden funkció be van vágva egy külön php fájlba, a közös részek meg copy-paste alapon ott figyelnek az összesben, kezdve az adatbázis-kapcsolattól az analytics javascript kódjáig minden, de ezek az uramisten kategórába tartoznak. (Hemzsegnek a biztonsági hibáktól, átláthatatlanok és karbantarthatatlanok.) Tehát miért is lenne jobb, ha én hoznám létre a struktúrát egyesével egy sima másolás vagy parancssori parancs kiadása helyett?
  2. A kódolási stílus egységesítése majdnem ugyanaz, mint a struktúráltság, csak egy másik vetülete ugyanannak a problémának. Ahol 1-nél több programozó van, ott már érdemes konveciókat alkalmazni. Érdemes kiindulni abból, hogy előbb-utóbb, minden szoftverhez több, mint 1 programozó fog tartozni és nagy valószínűséggel nem kerül egy projektbe két programozó, aki azonos stílust használ. A konvenciók használata biztosítja, hogy a teljes mű mindenkor jól olvasható maradjon, függetlenül attól, hogy ki végezte el a változtatásokat. Érdekesség, hogy míg a legtöbb rendszer a PEAR standardra hivatkozik, mégis szinte mindenki változtat rajta.
  3. A modulokat, függvényeket ha akarom, használom, ha nem akarom, akkor meg nem. Ráadásul ha nem akarunk nagyon egyedi külső modulokat beilleszteni - amit amúgy általában semmi nem tilt -, akkor egy olyan kódot kapunk, amit az azonos kódolási stílus miatt sokkal kellemesebb és gyorsabb olvasni, elemezni. Pláne ha az ember szeme már "ráállt" a kódolási stílusra. A rendszerek többsége automatikussá teszi ugyan a betöltést, de az utolsó pillanatig nincs semmi betöltve (csak a betöltő modul), így hiába több megabájt egy rendszer, a jellemző futása nem lesz lényegesen hosszabb egy bármilyen lecsupaszított programnál. Persze a késes példához visszatérve, nem mindegy, hogy valamilyen feladathoz a bozótvágóval látunk neki vagy bicskával...
  4. Az egyszemélyes rendszerek dokumentáltsága szinte sosem veszi fel a versenyt egy komoly nyílt keretrendszerrel. Az ugyan tény, hogy ez még nem veszi le a programozó válláról a dokumentálás felelősségét, de mégis nagy segítség lehet. Ráadásként sok esetben még ehhez a feladathoz is kész eszközöket kapunk a keretrendszerrel, amik egységessé és gyorsá teszik ezt az amúgy unalmas munkát.
  5. Ha valamiben igazán pocsék a programozók nagy része, az a biztonsági kérdések vizsgálata. (Engem is beleértve.) Egyszerűen mire kiizzadunk magunkból egy funkciót, ami működik, és főleg működik a megbízó gépén(!), plusz még többé-kevésbé hülyebiztos is, addigra már rég a következő, vagy következő utáni funkció megvalósításán jár az agyunk. Természetesen itt óriási előny, ha az embert órabérre fizetik, de legyünk őszinték, a főnökök se biztos, hogy örülnek, ha a drága programozók már "kész" funkciókkal molyolnak. Egy jó keretrendszer ilyenkor a legjobb barát a Földön. Az XSS, CSRF és SQL befecskendezés és egyéb védelmek ha nem is teszik egy csapásra tökéletessé a szoftvert, de mindenképp sokkal magasabb szintre emelik biztonságot. És, hogy tgr-t idézzem: "Saját keretrendszer használatának lehet értelme (bár ez nem ugyanaz, mint az eredeti cikkben szereplő no-framework, aminek szvsz nincsen), saját XSS szűrőének legfeljebb akkor, ha XSS-re specializálódó biztonsági szakértő vagy."

ennyi?

Távolról sem. A teljes eszköztár keretrendszerenként más és más még volumenében is, de olyan eszközök, mint a gyorsítótár kezelés, adatbázis és futási mutatók vagy a unit testing támogatása ma már mindegyik komoly rendszerben elérhető.

jó, de nem túl lassúak ezek?

Erről azt gondolom, hogy ez ennél összetettebb kérdés.

Először is ahogy nem ér összevetni egy html oldal beolvasási idejét egy adatbázisból dolgozó php oldal feldolgozási idejével, ugyanúgy nem ér egy átlagos php oldalt összevetni egy objektumorientált, biztonságos működést garantáló keretrendszer futási sebességével. Ha tényleg annyira fontos nekünk hogy hány századmásodpercig izzasztjuk a szervert egy oldal összerakásával, akkor rengeteg olyan eszközt kapunk, amivel ez a kép akár meg is fordítható. Ehhez nem kell más csak egy kis bonyolultság a feladatba és egy jó gyorstárazás a keretrendszerbe. Ugyanakkor még a legegyszerűbb oldalnál is hasznos egy gyors framework, mert ilyen esetekben az alapértelmezett konfiguráció sem lesz észlelhető időígényű, ráadásul a többi kedvező szolgáltatást és a gyors bonyolítás lehetőségét is megtarthatjuk.

Ugyanakkor az eddig leírtaknál fontosabb, hogy a renderelési idő normális esetben csak minket, fejlesztőket érdekel. Ha időről van szó, akkor sokkal fontosabb a fejlesztés és a betöltés ideje. Előbbit a keretrendszer óriási mértékben csökkenti, utóbbit pedig szinte nem befolyásolja. A betöltési hossza ugyanis sokkal inkább függ a megjelenítendő képek, szkriptek és stíluslapok számától és méretétől, mint a php futási idejétől, legalábbis amíg azt 1-2 tizedmásodpercen belül tudjuk tartani, addig biztosan.

megéri a sok tanulást?

Hosszú távon mindenképp. Aki még nem ismer egy keretrendszert se, annak bármelyik elismert szoftver sok újdonságot fog hozni, a többieknek pedig ezt már úgysem kell mondani.

Általánosságban azt hiszem elmondható, hogy kisebb feladatok megoldására minden framework alkalmas, ha pedig olyan komolyságú projektünk van, amelyik megvalósításához egy általunk ismert rendszer sem elég rugalmas, akkor is óriási segítség az ismeretük. Ha ilyen feladatba ütköznék, akkor én biztosan először körülnéznék, hogy melyik rendszer áll a legközelebb az elképzeléseimhez, akár az addig ismeretlenek közül is. Ha arra jutnék, hogy egyik sem jó, akkor a legvalószínűbb az, hogy a PHP sem a megfelelő nyelv a feladat megoldására. Illetve amennyiben mégis PHP-ban kellene dolgoznom, akkor is egy már létező rendszert alakítanék át az igényeim szerint, ebben egészen biztos vagyok.

Címkék: php keretrendszerek

A bejegyzés trackback címe:

https://szajtbilder.blog.hu/api/trackback/id/tr881656868

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

deejayy · http://deejayy.hu/ 2010.01.11. 09:11:38

Kérdés az utószóhoz, hogy melyik gyorsabb, megírni a saját projektet szinte nulláról, vagy belenyúlni a keretrendszerbe?

Hiszen utóbbiakhoz gyakran adnak ki frissítéseket, újabb release-eket, amikben esetleg kritikus hibákat javítanak, de már átírtad a kódot a saját szájízed szerint, ezért nehéz belepatchelni, stb.

Vagy megvalósítanak benne egy csomó olyan dolgot, amit annak idején saját magad írtál bele, de ők mára jobban megcsinálták?

Dilemma van bőven :)

Thoer 2010.01.11. 09:33:36

@deejayy: Azt hiszem az a legnagyobb baj, hogy nem igazán tudok elképzelni olyan szerver oldali feladatot, amit egy jó keretrendszer nem tud lekezelni, így nehéz korrekt választ adni.

Az utóbbi 2 évben szerintem egyszer sem nyúltam bele keretrendszer magjába, korábban is maximum néhány bugfix erejéig. Azokat a bugokat mindig le is jelentettem a fejlesztőknek, persze a javítással együtt, így egyfelől mindig láttam, hogy a javítás bekerült-e már az alapba, másfelől volt egy pontos leírásom a javításról, így ez nem okozott túl nagy gondot.

Ha tényleg arról lenne szó, hogy valamiért egészen át kell buherálni a rendszert, akkor azt mondom, hogy a dokumentáció korrekt vezetésével ez a dilemma kiküszöbölhető. Mondjuk kiveszem a kedvenc játékszeremből a legfontosabb részeket, például az űrlap kezelést, biztonságot garantáló cuccokat, illetve bármit ami kellhet még és ha kell akkor készítek hozzájuk egy egyedi illesztőfelületet, ezután az eredeti modulokat már frissíthetem az újabb verziókhoz.

Persze ez a részemről csak elmélet, de konkrétumok híján így gondolom.

Kormoran 2010.10.01. 08:34:22

A C és ASM felől jőve nekem is a sebesség-kompaktság volt a fixa ideám sokáig, de a tapasztalatom az, hogy a PHP projektek túlnyomó többségében a stabilitás és a fejlesztési idő az, amit megfizetnek, már ami a logikai kódolást illeti.

Thoer 2010.10.01. 09:00:12

@Kormoran: Egyet kell értenem, én is egyre inkább a lassabb de stabilabb rendszereket preferálom. Igaz, hogy a Kohana/CI törtrész alatt képes megoldani valamit, mint egy ZF + Doctrine kombó, de a tesztelhetősége, modularitása és eszközkészlete mérföldekre van. Éles környezetben pedig a gyorstárazás úgy is nagyságrendileg többet nyom a latba, mint a keretrendszer felépítési ideje 1-1 kérésnél.