Egyedi fejlesztés, vagy gyorsan összedobjuk Wordpress-ben?
Címkék
Megosztás

Egyedi fejlesztés, vagy gyorsan összedobjuk Wordpress-ben?

Kocsis József

Igazából kicsit igazságtalan vagyok a Wordpress-szel szemben, nem kimondottan eme népszerű tartalomkezelő rendszert akarom bírálni. Úgy is feltehetnénk a kérdést, hogy "előre megírt tartalomkezelő rendszer, vagy egyedi fejlesztés?". Ám tapasztalatom szerint - már csak népszerűsége okán is - a Wordpress-szel fordul elő a legtöbbször, hogy az alaprendszer, illetve a telepített plugin-ek mellé rettenetes egyedi fejlesztéseket kell beerőltetni és a végén az egyedileg fejlesztett függvénytár (a Wordpress esetében a functions.php) terjedelme vetekszik egy kisebb önálló natív alkalmazáséval.

Nézzünk egy viszonylag tipikus példát, amivel már a legtöbb web-es fejlesztő találkozhatott.

Az ügyfél megrendel egy webshop-ot. A fejlesztő létrehoz egy barátságos környezetet a Wordpress-nek, majd egy friss példányba feltelepíti az egyik népszerű e-commerce plugint, mondjuk a WooCommerce-t. Aztán az ügyfél szeretne mondjuk videókat a termékek képei közé, a fejlesztő felrak egy plugint, amit erre a feladatra terveztek. Az ügyfél szeretne hírlevelet kiküldeni, erre a fejlesztő feltesz egy plugint, ehhez azonban már haladó levelezési beállításokra lesz szükség, amit persze egy újabb plugin-nal orvosol a fejlesztő. Ezt a módszert elég sokáig lehet vinni, tudok olyan projektről, ahol a Wordpress kapott egy haladó fejleszetőknek szánt témát, amelybe PHP és JavaScript csomagkezelőkkel lehetett újabb csomagokat behúzni, az amúgy telepített plugin-ek mellé.

Ilyenkor annyiféle technika és technológia találkozik, ami már nagyon nehézkessé teszi az alkalmazás karbantartását. Az alap Wordpress alkalmazást, az esetleges témákat, plugin-eket, csomagokat mind-mind külön kell frissíteni, és ha az egyikkel gond van, megbéníthatja az egész alkalmazást.

Az alkalmazás sebessége is drasztikusan romolhat minden plugin telepítésével, hiszen minden plugin egymástól függetlenül kérdezi le az adatbázisból a számára szükséges adatokat, tekintet nélkül arra, hogy mellettük még hány másik csomag használja szintén az adatbázist. Ez az optimalizálatlan, stratégia nélküli adatbázis lekérdezgetés több másodperces oldalbetöltéseket is eredményezhet nagyobb adatmennyiség esetén.

Továbbra sem a Wordpress-t akarom bántani a fenti példával, azonban a leírtak jól mutatják, hogy az alkalmazás tervezése során valószínűleg sok praktikus szempontot figyelmen kívül hagytak a fejlesztők, akár véletlenül, akár esetleg szándékosan (utóbbi esetre még visszatérünk).

Nagy volumenű projekteknél (pl. webshopok, crm-ek) az ügyfél természetes késztetése, hogy pénzt akar spórolni, a fejlesztő természetes késztetése, hogy munkát akar spórolni. Természetesen lehet létjogosultsága a kész tartalomkezelők használatának, de túl sok egyedi kéréssel mind anyagilag, mind a befektetett munka szempontjából könnyen gazdaságtalanná válhatnak a fejlesztési, illetve fenntartási feladatok. (Sok időt igényelhet például az adatbázis-lekérdezések gyorsítása, vagy az alaprendszer és a plugin-ek frissítése).

Íme néhány szempont, illetve gondolat, amit a fejlesztés megkezdése előtt megszívlelendőnek gondolunk:

  • Az ügyfél gyakran nem tudja, hogy pontosan mit akar látni a kész termékben, ezért az alkalmazás első kipróbálható változata fogja ihletni igényeinek egy jelentős részét. Nagyon hasznos lehet működő termékeket példaként mutatni a tárgyalások során, hogy az ügyfélnek a lehető legkevesebbet kelljen a képzelőerejére hagyatkoznia.

  • Érdemes elolvasni valamennyi használni tervezett plugin vagy csomag dokumentációját. Ha az ügyfél csak egyetlen egy dolgot szeretne másképp, mint ahogy a választott keretrendszer vagy tartalomkezelő és bővítményeinek alapműködése ki lett találva, már az is okozhat több nap plusz munkát, hogy az alkalmazáshoz érkező frissítések ne írják felül a saját fejlesztéseket.

  • Ha az ügyféllel való megbeszélések során sokszor hangzik el ehhez hasonló mondat: “...olyat szeretnék mint ez a webshop, csak máshogy nézzen ki”, vagy “... így működjön, mint ez a példa, csak ne ebben a sorrendben jöjjenek az oldalak”, stb., akkor elég valószínű, hogy az ügyfélnek egyedi fejlesztésre van szüksége, csak még ő maga sem tudja, és ilyenformán kezdi kommunikálni az alkalmazása specifikációit. Ezt időben felismerve sok bosszúságot és áttervezést lehet megspórolni.

  • Ha az ügyfél a megbeszélések során tökéletes leírja egy már létező tartalomkezelő és / vagy webshop működését, akkor viszont semmiképp sem szabad nekifutni egyedi fejlesztésnek, érdemes viszont kétszer átgondolni a karbantartással járó feladatokat. (A Wordpresshez vagy Wordpress pluginekhez például havonta több frissítés is érkezhet.)

  • Előfordulhat olyan eset, amikor az ügyfél, a projektmenedzser vagy a fejlesztő cég tulajdonosa valami oknál fogva elkötelezett híve egy adott tartalomkezelő rendszernek. Ebben az esetben tudomásul kell venni, hogy bármi legyen is az ügyfél igénye, a fejlesztés mindenképpen az adott tartalomkezelőben fog elkészülni, függetlenül attól, hogy mennyi szakmai érv szólna az egyedi fejlesztés mellett.

  • És végül ha a fentiek közül bármilyen oknál fogva kész tartalomkezelő mellett döntünk, mindenképpen fontos, hogy tájékozódjunk az adott tartalomkezelő rendszerben használható szakszerű fejlesztési gyakorlatról, hogy pl. egy frissítés nehogy felülírja az esetleges módosításainkat. Informálódjunk a tartalomkezelő már megírt függvényeiről is: nagy rá az esély, hogy a függvényt, amire szükségünk van, a tartalomkezelő rendszer alkotói már megírták nekünk.

Amennyiben kész tartalomkezelő rendszereinek karbantartásáról illetve megújításáról szeretne beszélni velünk egy kávé mellett, keressen minket és biztosan találunk megoldást!