Kódaudit és kódjavítási szempontok Magento projekteknél

Első lépés a Magento kódaudit során

Érdemes megnézni, történt-e valamilyen hard-kódolás a projektben, találunk-e benne olyan módosításokat, amelyek a core fájlokban lettek kivitelezve, nem pedig config-ban újraírva, vagy community/local codepool-ba áthelyezve, majd ott módosítva. Ehhez arra van szükségünk, hogy legyen egy ugyanolyan típusú (community/enterprise) Magento projektünk (a verziószám is egyezzen), amivel össze tudjuk hasonlítani.

 

Ehhez PHPStorm-ot fogunk használni, de egyéb programokkal is nagyon szépen kivitelezhető az összehasonlítás. Kattintsunk az app/code/core könyvtárra, majd jobb klikk rajta, „Compare With…” (Ctrl + D), majd válasszuk ki a „társ-környezet”-ben ugyanezt a mappát.

 

Miután elfogadtuk (OK), felugrik egy ablak a változásokkal, itt nyugodtan kapcsoljuk ki a „Show new files on left side”, illetve a „Show new files on right side” opciókat, csak összezavarna bennünket. Ezek után, ha minden igaz, csak a „Show difference” lehetőség marad aktív, ami kifejezetten a különbségek listázására való.

Sajnos olyan opciót nem találtam, ami a kommenteket nem veszi figyelembe, így bár a kódrészek megegyeznek, a kommentek miatt több fájlt is feldob, mint különbséget. Ettől eltekintve esetemben nincs különbség a 2 projekt között. Ha ez a te esetedben nem így van, tehát különbségek vannak a rendszerben, azokat a fájlokat, amelyek eltérnek az eredetitől, vissza kell állítani, és a módosításokat át kell helyezni.

tips Ezt többféleképpen is megtehetjük :

 

  1. Core fájl átmásolása az app/code/core/…/File.php elérésről, az app/code/local/…/File.php helyre, majd az eredeti fájl revertálása annak alaphelyzetébe

 

  1. A fájl config-ból való felülírása egy a saját modulunk fájljával, az eredeti fájlt ebben az esetben is alaphelyzetbe kell állítanunk, és azt mint ős-osztályt kiterjeszteni belőle

 

  1. Harmadik lehetőségként Observer-rel megvalósítani a működésbeli különbségeket

 

A fenti listából az első megoldást tartom a leggyorsabbnak, míg az utolsót a legszebbnek.

 

Amennyiben ezek megtörténtek ‒ tehát a capp/code/core fájlok az eredeti állapotukba, az új működések pedig valamilyen módon kiszervezésre kerültek ‒, a következő lépés az app/design/[frontend/adminhtml] mappa(k) tartalmának összehasonlítása. Sajnos gyakran előfordul, hogy a fejlesztő nem hoz létre saját template vagy layout fájlt, hanem a base/default/[template/layout] mappá(k)ban szereplő eredeti fájlokat módosítja.

 

Ennek javítása is hasonlóképpen történik, mint a kód esetében. A módosított fájlokat átmásoljuk a saját témánk alatt ugyanabban a struktúrában, az eredeti fájlokat pedig eredeti állapotukra revertáljuk. pl. az app/design/frontend/base/default/template/catalog/product/list.phtml-t másoljuk az app/design/frontend/rwd/theme/template/catalog/product/list.phtml elérésre, az eredetit pedig visszaállítjuk.

Layout fájlok esetében elég csak a változó részt átmásolni, nem szükséges az egész layout fájlt egy-egy rész miatt mozgatni, illetve még szebb megoldás, ha reference-szel hivatkozunk egy definiált Block-ra.

 

Template-ek esetében is érdemes felmérni annak lehetőségét, hogy tudjuk-e layout-ból számunkra megfelelő módon változtatni, módosítani. Ha layoutból módosítva azonban nem a megfelelő helyen jelennek meg a kérdéses új elemek/blokkok/template-k, a fent említett módszer (template mozgatása, változtatása) biztos megoldást jelent.

 

Tegyük fel, hogy ezeken a helyeken is minden rendben volt, a template és layout fájlok is ott kerültek módosításra, ahol ennek történnie kell (akkor ez egy nagyon szép projekt, valószínűleg a továbbiakban sem lesz vele gond). A meglévő modulok illetve template fájlok minőségét kell ellenőrizni, ezeket az alábbi szempontok alapján tudjuk megtenni, melyekre egyesével kitérünk:

 

  • Kódredundancia – kódismétlés
  • Kódrelevancia – bizonyos kódok megfelelő helyen történő tárolása
  • Installer Scriptek – minőség és megbízhatóság
  • Template fájlok – objektumhívások minimalizálása
  • Block / Controller ellenőrzés – terhelés, megvalósítás

 

 

Kódredundancia – kódismétlés

 

A kódredundancia: alatt az értendő, mikor egy adott modulon ‒ vagy akár több összefüggő modulon keresztül ‒ ugyanazt a működést valósítjuk meg, akár ugyan azzal a módszerrel, de több különböző helyen. Ha a kódban ilyet találunk, biztosan rossz helyen szerepelnek ezek a kódrészek, hiszen ezeknek optimális esetben egy helyen kell lennie, és onnan kerülnek meghívásra.

Sajnos ezt nem olyan könnyű kiszúrni, hiszen a kód nem egzakt, többféleképpen is nekifuthatunk valaminek az ellenőrzésének, így ennek a felmérése, megtalálása több időt vehet el, mint a végén az az idő, amelyet a javítására kell fordítani. Az alapvető szempont, hogy legjobb már az elején, a fejlesztés indításánál, felkészíteni az egységes működésre ezeket a folyamatokat, és ennek szellemében létrehozni a különböző megoldásokat.

 

Kódrelevancia – bizonyos kódok megfelelő helyen történő tárolása

 

Vannak kódok, melyeknek egyértelmű helyeik vannak, ilyen pl. egy új modul aloldala, action-je, aminek egyértelműen controller-be kell kerülnie, hiszen egyéb esetben nem működik. Vannak kódok azonban, amelyek funkciótól függően lehetnek Block-ban, vagy Helper-ben is, sőt, akár még Model-be is kerülhetne, de  ezeknek is megvan a pontos helye. Az általános működéshez kapcsolódó kódok azonban nagy valószínűséggel Helper-be kell, hogy kerüljenek, a keresztfunkcionalitás segítése érdekében. Jellemzően ilyenek az egy-egy modul állapotát ellenőrző kisebb metódusok, és/vagy amelyek közvetve vagy közvetlenül, de a config értékekkel dolgoznak.

 

Ezen felül kerülhetnek ide még az aktuális end user-hez kapcsolódó, de alaphelyzetben még le nem fejlesztett ellenőrzések, mint pl. egy adott típus ellenőrzése egy kiterjesztettebb regisztráció után, stb. $helper->isStudent(); $helper->isTeacher() stb. (Bár ezeket szintén akár observer-rel is meg lehet oldani.)

 

Ide lehet sorolni még bizonyos a Model-ekhez kapcsolódó „működéseket”, melyek néha eltévednek a megvalósítás közben. Jó példának tartom ide a Model exportálandó mezőit, illetve annak CSV header-eit, aminek nem helper-ben vagy block-ban a helye, hiszen bárhol ahol a Model meghívásra kerül, szükség lehet erre, aminek egyszerűbb és logikusabb módja az adott Model-ben tárolni.

Ide raknám még a Model-hez az esetleges parent-child elemek lekérését, tehát ha az egyik adott Model-nek van egy 1-* kapcsolata egy másik Model-el, azt esetleg egy $model->getChildSomethings(); metódussal a „fő” Model-ben elhelyezhető.

cikkgrafika-koderelevancia

Installer Scriptek – minőség és megbízhatóság

 

Az installer script-ek írása közben gyakran megfeledkezünk még mi magunk is arról, hogy valamilyen varázslatos és megmagyarázhatatlan módon (valaki töröl egy jellemzőt, mezőt, értéket, majd újra futtatja a script-et), időnként duplán futnak le, és így nem várt hibába ütközünk.

 

Ennek kiküszöbölése nem annyira időbeli, mint hozzáállásbeli erőfeszítést igényel. Bár valószínűleg saját script-ünk futtatásakor a saját környezetünk adataira támaszkodva készítjük el azt, érdemes ezeket mindenre felkészítve, már eleve egy ellenőrzéssel indítani.

Ha jellemzőt adunk hozzá, akkor a jellemzőt keressük először, és a hozzáadását kössük feltételhez. Tábla mezőinek manipulálásakor is érdemes ellenőrizni annak aktuális állapotát. A $installer->endSetup(); kódot, csak a 100%-ig biztos lefutáshoz illesztjük be, ha try-catch-be rakjuk az installer működését, az endSetup() ne ezen kívül, hanem a try végében helyezkedjen el, így biztosítva, hogy csak a helyes működéssel lép verziószámot modulunk.

 

Template fájlok – objektumhívások minimalizálása

 

A template fájlok (.phtml) írása során is igyekeznünk kell annak azonnali áttekinthetőségére, illetve a kód újrahasznosíthatóságára. Mit jelent ez?

 

  • Nem égetünk bele értékeket
  • Nem valósítunk meg benne működést
  • Nem hívunk a szükségesnél több metódust benne

 

Helyette:

 

  • Az értékeket/beállításokat lehetőleg már (a frontend-es kolléga támogatását elősegítve) layout szinten megadhatónak fejleszteni.
  • Mindennemű működést, ami a lekéréseken felül kerül hívásra, a Block-okban megvalósítani
  • A template-ek bizonyos szintű összetettségétől függően (pl. 2 különböző típus elágazásánál) külön template-ekbe szervezni.

 

Idetartozónak tartom még, bár valójában ez minden részében igaz a fejlesztéseknek, hogy egy-egy értéket (0, 1, 2) soha nem értékével azonosítunk, ezeket érdemes, sőt kötelező valamilyen konstansba helyezni, és így beszédes változónévvel azonnal áttekinthetővé tenni annak értékét. Erre is nagyon jó példák találhatóak a Core Magento-ban, termék Status értékek, xml config path-ek, valamilyen minimum/maximum értékek meghatározása.

cikkgrafika-templates

Azonfelül, hogy ezek sokkal áttekinthetőbbek, beszédesebbek is így, ha mindenhol ezt az értéket használjuk, arra keresni is sokkal egyszerűbb (kevesebb találat), illetve egy helyen tudjuk módosítani adott esetben.

 

Block / Controller ellenőrzés – terhelés, megvalósítás

 

A block-ok és controller-ek ellenőrzésénél két dolgot kell figyelembe venni, és ez a két dolog elég szorosan összefügg. A megvalósítás mikéntje, és a terhelés, amit ki kell állnia. Minél jobb a megvalósítás, annál kisebb a terhelés.

Amennyiben egy template fájlból a block getCollection() metódusa több alkalommal is hívásra kerül, azt jó megoldás cache-elni a block-ban, így valódi adatbázis művelet csak elsőre lesz, minden további csak a cache-elt objektumlistáig jut. Erre találunk egyébként core példákat is, amelyeket minden további nélkül lehet útmutatásként használni.

 

A controllerek esetében érdemes az egyes action-ök méretére egy pillantást vetni. Nem kívánok itt sem fontméretet sem pedig a sorok számát megadni, hogy mekkora terjedelemig megfelelő egy action, de abban azt hiszem, megegyezhetünk, hogy a szemnek kényelmesen áttekinthetőnek kell azt találnia, mind formai mind mennyiségi szempontból.

Amit még a controllerek-hez hozzátennék, hogy véleményem szerint az ezekben elhelyezett block példányosítások sem szükségszerűek, szintén meg lehet oldani a block-on belül. Ezzel máris csökkentjük annak méretét.

 

Összegzés

Ez mennyiségileg nem olyan sok dolog, hiszen mindössze 5 részletesebb és 2(1) ezektől különálló lehetséges problémafaktort tekintettünk át, de ha azt vesszük figyelembe, hogy egy-egy projekten akár nagyobb számú (értsd x > 4) fejlesztő is dolgozhat egymás mellett, modulonként akár egyszerre tízes nagyságrendű fájlokat hoznak létre/módosítanak, már nem is olyan kevés.

Ha minden ilyen fájlban csak egy ilyen apró hiba van, már az is indokolhat egy kisebb refaktorálást a projekt élesítése előtt/után. Illetve a témánkat tekintve, ezeken a pontokon végighaladva, egy részletesebb képet kapunk arról, hogy az új projektünk mennyi, és milyen problémákkal rendelkezik, melyeket meg kell oldanunk.

 

Szükséged van további segítségre? Keress minket azonnal, vagy olvass többet kódaudit szolgáltatásunkról.

 

61 válaszok
  1. Drug And Alcohol Treatment Near Me says:

    Alcohol Rehab Near Me Free http://aaa-rehab.com Alcohol Rehab Near Me http://aaa-rehab.com Alcohol Programs Near Me
    http://aaa-rehab.com

Trackbacks & Pingbacks

  1. cialis 20 mg price

    Kódaudit és kódjavítási szempontok Magento projekteknél – aionhills.com

  2. tylenol walmart szerint:

    tylenol walmart

    Kódaudit és kódjavítási szempontok Magento projekteknél – aionhills.com

  3. naltrexone canadian pharmacy

    Kódaudit és kódjavítási szempontok Magento projekteknél – aionhills.com

  4. cipro sale szerint:

    cipro sale

    Kódaudit és kódjavítási szempontok Magento projekteknél – aionhills.com

  5. viagra szerint:

    viagra

    Kódaudit és kódjavítási szempontok Magento projekteknél – aionhills.com

Hagyjon egy választ

Want to join the discussion?
Feel free to contribute!

Vélemény, hozzászólás?

Az email címet nem tesszük közzé.