Weblabor

... vesztemet. A kommentemben nem írtam le mindent egyértelműen.


Mint írtam, nem olvastam végig, csak átfutottam, valamint amit összegzésként írtam, azt a conclusion részben olvastam.

Éppen a kódszervezés volt az egyik dolog, ami miatt kialakult a saját megoldás. Természetesen folyamatosan csiszolva van, ha jön egy újabb dolog, amit úgy gondolok, hogy érdemes bevezetni az eddigi módszerek mellé.

Egy CakePHP vagy Symfony megismerése nem kis feladat (idő, energia, szemlélet átformálás), valamint vannak kialakult programozástechnikai dolgok, saját módszerek, hogy mit hogyan oldok meg. Hosszú évek alatt csiszolódik és mint írtam, vagy feladom ezeket a framework filiózófiájáért, vagy szépen lassan beleviszem az én dolgaimat, ami egy komplex framework esetén sok idő, energia, ami nem biztos, hogy megtérül.

Másrészt, esetemben a fő szempont az volt, hogy egy általános platformot hozzak létre, ami minden project esetén azonos lesz. Ez kiegészül azzal, hogy egyszemélyben valósítom meg egy honlap vagy internetes rendszer teljes programozását, kezdve a HTML+CSS-sel, JS-en át a PHP-ig. Így a framework-öt úgy alakítottam ki, hogy a többi területet könnyen tudjam kezelni, szóval itt jön főként az egyedi szemléletmód, követelményrendszer.


Ez írtam fentebb, vagy átveszem a fw filozófiáját, vagy beleviszem a sajátomat, ergo testreszabon a fw-öt, ami hosszú távon egyenlő a saját fw fejlesztésével.


Nem is volt cél a legtökéletesebb framework létrehozása. A saját kialakult munkamódszerekhez illő rendszerre van szükségem, kell egy szabványos platform, ez a saját framework. De nem minden igényt kielégítő, minden problémát lefedő rendszerre van szükségem, hanem egy vázra, amire azt és úgy építek fel, ahogy akarok.

Alapvetően szeretem tudni, hogy mi hogyan működik. Egy framework egy magasabb absztrakciós réteget képvisel, sok dolgot eltakar, ami engem sok esetben zavar. Ált. meg akarom érteni, hogy mi hogyan működik és a saját megoldásomat létrehozom. Ez persze nem igaz olyan dolgokra, mint e-mail küldés, mert arra ott a PHPmailer.

Tehát ahány programozó, annyiféle szemléletmód. A végeredmény ugyanaz lesz, a rendszer működik. Hogy a dobozban mi hogyan megy, az pedig a programozón múlik.


Anno néztem egy diplomamunkát, amiben CakePHP-vel hozott létre a srác egy rendszert (már nem emléxem mit). Itt pl. nem tetszett, hogy a M-V-C hogyan kommunikál egymással, nem állt kézre a logika. Ezért a logikát nagyjából adaptáltam (MVC), viszont a tényleges működést máshogyan oldottam meg.


Itt a kulcs, hogy az egységes struktúrát én akarom meghatározni, a saját logikám, munkamódszereim alapján. Ez lehet, hogy nem eredményezi a legjobb megoldást, nem kapok érte szakmai díjat, de hatékonyan tudok általa dolgozni.


Ebben igazad van, viszont mint írtam, nem volt célom, hogy tökéletesítsem a mások által kitalált rendszert, hanem saját használatra dolgozzak ki egy módszert, amivel kényelmesen tudok dolgozni. Másrészt messze nem rendelkezem olyan ismeretanyaggal, hogy tökéletesíteni tudjam a meglévő framework-öket.

Ez kb. olyan, mint hogy van az optika egér, de létezik trackball is. Az emberek 99%-a nem tudna mit kezdeni egy trackball-lal én meg imádom és ezzel tudok kényelmesen dolgozni. A végeredmény ugyanaz (mozog a kurzor), de nekem mégis egy alternatív megoldás fekszik. (Tudom hülye hasonlat és sántít rendesen, de remélem érthető, hogy mit akarok mondani.)


Persze, hogy más kategórai a CMS. Itt az elvet akartam szemléltetni, hogy én pl. nem akarok Drupált használni egy kisebb honlaphoz, mert a saját framework-ömmel is össze tudom állítani az oldalt. Az eredmény ugyanaz lesz, csak jóval egyszerűbb lesz a kód, a saját logikámat követi, nem kell megtanulnom a Drupal filozófiáját; ami lehet, hogy teljesen ellentétes az enyémmel.


A framework lényegében egy általánosított platform, egy magasabb absztrakciós réteg, ami növeli a produktivitást. Abban az esetben van értelme ismert, sokak által használt rendszer alkalmazni (szerintem), ha nagy eséllyel mások fogják majd módosítani a kódot, így van egy közös nevező (persze ez csak egy érv a sok közül).

Esetemben mivel egyszemélyes megoldásban dolgozom, számomra kényelmesebb, ha a saját logikám, munkamódszereim alapján létrehozott rendszerrel dolgozom. Amennyiben esetleg más kezébe kerülne a rendszer, jó lenne az egységes platform, amit biztosít pl. a Symfony. De mi van, akkor ha az emberke CakePHP-t használ? Meg kell tanulni a Symfony-t, hogy tudja módosítani a rendszert.

Másrészről pedig, ha minőségi kódot ír az ember, jól kommentezve és van fejlesztői doksi is, akkor szerintem minimális az az idő, ami alatt bele tud nyúlni más ember a rendszerbe. A GDF Abakusz nevű programozói versenyén évről évre szembesültek a verseny szervezői azzal, hogy nem tudak a programozók fejlesztői doksit írni ...

Nem utolsó sorban pedig a programozók nincsenenk egy szinten. Én például látom, hogy mennyi mindent nem ismerek még, merre lehetne fejlődni. Viszont mivel nem életcélom, hogy nagynevű programozó legyek (régen ez volt, de azóta sok minden változott, másfelé orientálodom, egyre távolabb a programozástól), viszont minőségi munkát akarok kiadni a kezemből kell egy köztes állapot. Többet tudok mint a kezdők, kevesebbet, mint a profik, viszont próbálok hasonló megoldásokat alkalmazni, mint a nagyok. Nem lesz így tökéletes a rendszer programozói szempontból, de mint azt tapasztalom a megrendelőt ez cseppet sem érdekli. Én törekszem az aktuálisan adható legjobb kivitelezésre, de ebbe nem fér bele, hogy a legprofibb programozói megoldásokat alkalmazzam (kevés idő, energia, kapacitás), mert ahhoz évek kellenek, hogy elsajátítsam.

Lehet, hogy jól megél a CMS-t fejlesztő, majd értékesítő cég, de a nyakam rá, hogy van jó néhány olyan ember, akinek sokkal jobb lenne egy teljesen saját, a cégre szabott megoldás, aminek a kódja lehet, hogy 10x egyszerűbb lenne. Az áltánosság üzleti szempontból nagyon jó, de az ügyfélnek nem biztos (lásd lentebb).


Itt egyedi alatt a Drupal vs. célorientált fejlesztést értem. Nem dolgoztam eddig sok helyen, viszont egyre inkább azt látom, hogy az egyedi, egyénre szabott megoldásokra van sok esetben szükség (ez nem jelenti azt, hogy ne lenne piaca az általánosítot megoldásoknak). Anno megvette a volt munkahelyem az SBO-t, majd ráköltöttek még 4x annyit az egyedi fejlesztésekre. Ebben az esetben jobb lett volna egy teljesen egyedi, testreszabott vállalatirányítási rendszert iratni (hogy miért nem ez történt az nem ide tartozik).


Ez igaz, de itt jön az, hogy ha nekem van saját metódusom, hogy hogyan kezelem a form-okat, akkor miért használjam a meglévő megoldást, ami nekem lehet, hogy 10x kényelmetlenebb?

Ez kb. ugyanaz, hogy miért van kismillió autó? Az egyik a családosoknak készült, a másik az üzletembereknek, a harmadik a kispénzüeknek, stb. Hiába tud 300-al menni egy Ferrari, ha nem fér bele a család motyója. Így talán érthetőbb, hogy mit értek saját igények alatt.


Ezért használok pl. PHPmailer-ert és nem írok saját mailer class-t. Viszont más esetben, lehet, hogy a saját megoldás sokkal jobban kézreáll.

Ez is kb. egy framework lenne, amit idővel szépen bővítgetni kell, és végül eljutsz simán egy lightweight frameworkhöz, csak egy szép kis kerülőúton.

Illetve mit vársz attól, hogy procedurális megközelítést használsz? Én összedobtam most egy frameworköt ami OOP, kb. tudja amire alapban szükség lehet, és egy kis trükkel APC mellett kiszolgált kb. 3000 hello world oldalt másodpercenként az egyik amúgy élesben lévő szerverünkön. Eleve kérdéses, hogy olyan-e a projekt, amit fejlesztesz, hogy érdekesek az ilyen mikro optimalizálások, általában nincs erre szükség, és az a fontos, hogy minél rövidebb legyen a fejlesztési idő.


Üdv,
Felhő