2016. június 12., vasárnap

Erre ügyelj, ha egyedi fejlesztésű weboldalt akarsz

Samael, az ördög, sátán, Lucifer, Beliál, Belzebub és még ki tudja hány neve van a gonosznak, ami alatt a megtestesült rosszat értjük. Sokan ezzel hozzák összefüggésbe a saját fejlesztésű weboldalakat is. Pedig rosszul teszik, és a hiba nem az egyedi fejlesztésű weboldalakban van, hanem vagy a fejlesztőben - aki azt rosszul csinálta meg-vagy az ügyfélben, aki ebben a kategóriában a legolcsóbb és legtöbb esetben a tapasztalatlan megoldást választotta.
Félreértés ne essék, én sosem erőszakoskodom ha az ügyfél egy CMS-re építkezik, de érdemes elgondolkodni az alábbi dolgokon.

 

Mekkora a költségvetés ?

Általában egy 2000 EUR - 3000 EUR fölött már saját fejlesztést szoktam javasolni. Ha egy minimális havidíjat is szánnak a dologra, akkor pedig szinte kötelező belevágni. Az ár egy fontos szempont, de nem az egyetlen.

Mi van a háttérben ?

Teljesen normális dolog, hogy egy ember tanácsot kér egy adótanácsadótól, egy ügyvédtől, vagy akár egy könyvelőtől, na de egy informatikustól sosem. Miért ne? Hát könyörgöm kérdezz! Mennyibe kerül egy egyedi rendszert átírni, és mennyibe kerül megkérdezni egy harmadik felet, hogy ami eddig elkészült, az jó irányba halad-e? Jómagam is keveslem azt, hogy senki nem kér tanácsot tőlem, de a tapasztalatok is azt mutatják hogy teljesen berögzült mindenkinél, hogy az egyedi fejlesztés rossz. Pedig nem így van, csak a pénzt rossz helyre, rossz időben és rossz személyhez kerül. Bérelj fel egy kívülállót, aki akár az egész projektet levezényli, egy igazi IT Projekt Managert. Nem projekt managert írtam, hanem IT projekt managert. Van különbség, nem is kevés. Tehát nem arra van szükséged, aki tartja a kapcsolatot közted meg a fejlesztő/fejlesztőcsapat között, hanem arra, aki tudja is mit csinál a fejlesztő. Egy olyan tapasztaltabb fejlesztőre lehet szükséged, aki a minőségre is ügyel és a motorháztető alá is van belátása. Nem kell jelen lennie az egész projekt alatt, elég ha például az elején, a közepén vagy a végén ott van. Persze ez sem teljesen igaz, mert az a jó, ha végig jelen van.

Működik ez ?

Sok fajta tesztelés létezik, de az utolsó tesztelésnek mindig az ügyfélnél kell történnie. Ezt hívják kiadástesztelésnek. Az esetek nagyon nagy részében mindig akad olyan kisebb bug, amit a fejlesztő nem lát, de még a PM sem, csak az ügyfélnek tűnik fel. Tehát egyedi fejlesztésnél számolj arra, hogy a végső produktumot neked is végig kell kattintgatni.

Lehet egyedi, de csak részben

Nagyon fontos, hogy egy egyedi fejlesztés dokumentált legyen. A jövőben nagyon sok fejfájástól megkímélheti az ember magát, ha dokumentál. Ha nincs dokumentáció, de egy már jól dokumentált keretrendszert használunk, az már elég. A keretrendszer dokumentációjából és egy jó adatbázistervből már jól kivehető, hogy mi van a háttérben. Én nagyon erősen javaslom, hogy aki ilyesmibe fog, az csakis egy MVC keretrendszerrel tegye (Laravel,CakePHP,Yii, stb.). Nem elég azonban csak MVC keretrendszert használni, annak konvencióit is követni kell! Az, hogy a fejlesztők körmére nézzen, egy projekt manager feladata. Sajnos előfordul (tisztelet a kivételnek) hogy valaki elvállalja a projektet, majd az egészet tapasztalatlanul, a "csak működjön" elven viszi végig.

Mit kapsz ?

Egy egyedi fejlesztésű weboldal legfőbb előnye a szabadság. Azt csinálsz, amit akarsz, úgy, ahogy akarod. Ez nagy előny, de ugyanakkor (ha rossz kezekbe kerül) nagy hátrány is lehet. A másik fontos tényező a sebesség. Legutóbbi projektünkben bármely CMS betöltési sebességét szó szerint lealáztuk. Nem csoda, egy CMS-nél (főleg Wordpress) a rengeteg rosszul tervezett bővítmény csak a sebesség rovására megy. Ha valamiért egy bővítményt átírtál, retteghetsz a frissítésektől. Ha frissítessz, már nem olyan mint szeretnéd, de egy biztonsági frissítésnél a frissítés elkerülhetetlen. Itt nincs ilyen. A legvégső és egyik legfontosabb szempont a zártság. A saját fejlesztés zárt, a CMS nyílt. A crackereknek ez egy nyitott könyv, míg egy saját fejlesztéssel meggyűlhet a bajuk. Wordpress esetén még nem is annyira az open source jelleg a problémás, hanem a sok rosszul tervezett (ha egyáltalán lehet így mondani) bővítmény.

Konklúzió

Ha pl. egy webshopot akarsz és még nagyon az elején jársz a dolognak, akkor használj nyugodtan valami egyszerű megoldást. Ha egy kicsit jobban megindult az üzlet, akkor válts, de figyelj: legyen egy jól dokumentált mvc keretrendszer és ügyelj arra, hogy a konvenciók követve legyenek: legyen egy adatbázisterv (ezt el lehet kérni), ne félj segítséget/tanácsot kérni egy harmadik féltől, végezetül pedig tesztelj!






© Smart Web Services
Maira Gall