Weblabor

Aki kicsit is foglalkozott weboldalak használhatóságával, egész biztosan találkozott Steve Krug Don’t make me think című könyvével. A használhatóság (usability) egyetlen feladata, hogy a látogató vagy vevő számára a lehető legegyszerűbbé tegye a meghatározott cél elérését. Felmerül a kérdés, hogy vajon hasonló elveket, gondolatokat alkalmazva hatékonyabbá tehető-e a webfejlesztési munka, egész konkrétan a PHP-s fejlesztés.

Rengeteg féle-fajta rendszeren dolgozom, és igen gyakran nagy mélységben bele is kell nyúlnom a kódba. Akik személyesen ismernek, tudják, hogy átmegyek házisárkányba, ha az általam használni kívánt kód nem egyértelmű vagy bonyolult használni. Eljön az a pont, amikor a legzseniálisabb programozó sem tudja az összes függvény paramétereit megjegyezni. Jellemzően a legjobbaknál is vége van, ha félmillió kódsor fölötti projektet kell fejbe tartani. Plána, ha nem is egy projekten kell dolgozni.

Egy másik szempont a gondolatmenet megtartása. Ha picit figyeljük magunkat kódolás közben, általában egy adott cél lebeg a szemünk előtt, méghozzá egy adott funkcionalitás megvalósítása. Ehhez használjuk a már korábban megírt függvényeket. Ha viszont ezen függvények használata nem triviális, nem egyértelmű, akkor neki kell állnunk elolvasni a dokumentációt, vagy rosszabb esetben a függvény kódját. Ez megakasztja a gondolatmenetünket, ami semmiképpen nem hat jól a produktivitásunkra. Magamat figyelve azt vettem észre, hogy ha elég ilyen zavaró tényező lép fel, egy ponton túl egyszerűen képtelen vagyok a feladatra koncentrálni, hiszen a teljes időmet azon függvények bogarászása tölti ki, amiknek az én munkámat kellene segítenie.

Függvények írása

Éppen ezért az első és szerintem legfontosabb a függvény öndokumentáló jellege. Nézzük az alábbi példát:

/**
 * @param iPlugin $plugin
 * @param string  $eventName
 * @param int     $priority
 */
public function register(iPlugin $plugin, $eventName, $priority = 10) {}

Mint látható, a függvénynek nem adtam szöveges dokumentációt. Noha lehetne magyarázni a függvény működését, ennyiből már ki kell derülnie, hogy nagyságrendileg mire szolgál. Ha ez nem adott, akkor már csökkent a kódolás sebességén, hiszen a triviális feladatok elvégzésére is bele kell túrnunk a doksiba vagy rosszabb esetben a függvény kódjába ahhoz, hogy használni tudjuk.

Itt kitérnék a magas szintű angoltudás fontosságára. Sajnos rengetegszer látok magyarból, németből, kínaiból tükörfordítással előállított függvényneveket. Amennyiben úgy döntünk, hogy a céges nyelvünk az angol, akkor fordítsunk időt az önképzésre, hiszen senkinek nem jutna eszébe a fenti függvényt mondjuk insert() néven keresni. Ez megint egy olyan pont, ami lassíthatja a függvényeinkre épülő kódok írását. Amennyiben nem vállalható az angol nyelvű függvényelnevezés, még mindig jobban járunk a magyar nyelvű nevekkel a tükörfordított függvénynevek helyett.

A példára visszakanyarodva, érdemes megnézni a függvény paramétereit is. Mint látható, egyértelműen dokumentálva van, hogy mit vár a függvény. Ahol szöveget vár, ott string van írva, ahol számot, ott int. A kiszámíthatóság szempontjából a lehető legrosszabb, ha ilyeneket írunk: int|bool. Ez esetben ugyanis nem triviális, hogy miért és milyen esetekben kell int-et, milyen esetekben bool-t átadnunk.

Ugyanilyen főbenjáró bűn szerintem a szöveggel indexelt tömbök átadása. Ha tehát a $plugin változó egy tömb lenne, amely bizonyos jól meghatározott elemein vár különböző adatokat, akkor a függvényt használni kívánó fejlesztőnek vagy el kell olvasnia a függvény dokumentációját, vagy még rosszabb esetben át kell túrnia a függvény kódját.

Adatkonténerek

Ezekre az esetekre szervezhetünk adatkonténer osztályokat avagy data objecteket. Ezek semmi mást nem tesznek, mint bizonyos adatokat eltárolnak szabványos formában. A fenti projektből véve egy példa erre:

abstract class Event implements iEvent {
    /**
     * @var string
     */
    protected $name;
    
    /**
     * @param string $name
    */
    public function setName($name) {
        $this->name = $name;
    }
    
    /**
     * @return string
     */
    public function getName() {
        return $this->name;
    }
}

Mint látható, az Event osztály egyetlen egy paramétert tartalmaz, méghozzá az esemény nevét. Az objektum tetszés szerint bővíthető további attribútumokkal, és ha korszerű fejlesztőkörnyezetet használunk, az ún. getter és setter függvényeket automatikusan legenerálja az osztályba.

Ha igazán ki akarunk tenni magunkért, akkor definiálhatunk egy interfészt is. Az interfész ugyanis lehetővé teszi azt, hogy bárki írjon olyan osztályt, ami megvalósít bizonyos szabványos metódusokat, azonban azt ne kelljen egy közös őstől (pl. az Event-től) származtatni. Ennek akkor van értelme, ha a különböző implementációk radikálisan különböznek vagy különbözhetnek egymástól. Az Event osztályunkra írt iEvent interfész így néz ki:

interface iEvent {
    /**
     * @param string $name
     */
    public function setName($name);
    
    /**
     * @return string
     */
    public function getName();
}

Nem egy bonyolult művelet megírni, azonban a későbbiekben sokat segíthet a felület szabványosítása. Mivel interface-t használunk, nem kötjük a függvényünket egyetlen implementációhoz sem, bárki írhat bármilyen eseményt megvalósító osztályt, amit átadhat a függvényünknek.

Felmerül a kérdés, hogy mi a teendő akkor, ha több elemet akarunk átadni? Természetesen építhetünk egy csomagoló osztályt az ArrayObject nyomán, azonban ez talán egy picit sok. Viszont a korszerű IDE-k itt is kínálnak egy egyszerűen használható megoldást, méghozzá az objektumtömb dokumentációt, itt egy változóra alkalmazva:

/**
 * @var iPlugin[]
 */
protected $plugins = array();

Mint látható, itt egyértelműen egy tömbről van szó, azonban szabványosítottuk azt, hogy milyen elemek lehetnek a tömbben. Innentől kezdve egy okos IDE például egy foreach ciklusban fel fogja nekünk kínálni az adott objektumhoz tartozó függvényeket kódkiegészítésben. Noha az egyértelmű függvény specifikáció rendkívüli módon segíti az implementáló dolgát, érdemes lehet azért egy típus ellenőrzést végrehajtani az elemeken, ha félő, hogy más is kerülhet az adott tömbbe. (Én személy szerint az itt leírt elvek betartása mellett elenyészően kevés ilyen hibával találkoztam éles kódban.)

Visszatérési értékek

Ha visszatérési értékekkel dolgozunk, akkor is érdemes a korábban leírtakat fontolóra venni. Véleményem szerint a lehető legrosszabb dolog, amit tehetünk a következő:

/**
 * @return bool|SomeObject
 */

Mint látható, a függvény visszatérési értéke vagy SomeObject lehet vagy pedig egy boolean érték, legtöbbször false. Ezzel több súlyos probléma is van. Egyrészt a programozó lusta, és akármennyire is verjük nádpálcával, akkor sem fog minden egyes függvény visszatérést ellenőrizni. Ebből következően, ha objektumként próbálja használni a visszatérési értéket, a program azonnal elhasal. Másrészt megint csak gondolkozni kell azon, hogy milyen esetekben lehet false a visszatérési érték, lassítjuk a programozási folyamatot, megtörjük a gondolatmenetet.

A konfliktus feloldására két megoldásunk van. Az első, hogy a hibaesetet egy kivétel (exception) dobásával jelezzük. Ez aztán szépen felfele kipörög a függvényből, amíg el nem kapja valaki. Az előnye az, hogy nem kell feltétlenül minden hívó félnek visszatérési értéket ellenőriznie és adott esetben tovább adnia, hanem mondjuk 3-4 szinttel feljebb is elkapható a hiba:

/**
 * @return SomeObject
 * @throws ConnectionException ha csatlakozasi hiba tortent.
 */

Ez egy elég egyértelmű dokumentáció, ha csatlakozási hiba történt, ez az exception fog jönni. Kérdés nincs, egy pillantás elég ahhoz, hogy megállapítsuk, kell-e foglalkoznunk az üggyel.

A másik megoldás, ha rá akarjuk kényszeríteni a hívó függvényt az eredmény kezelésére, hogy a visszaadott objektumba implementálunk egy sikerességet jelző mezőt, például így:

class SomeObject {
    /**
     * @var bool
     */
    protected $success;
    
    /**
     * Megmondja, hogy a muvelet sikeres volt-e.
     *
     * @return bool
     */
    public function getSuccess() {
        return $this->success;
    }
    
    /**
     * @param bool $success
     */
    public function setSuccess($success) {
        $this->success = $success;
    }
}

Ezzel egyértelműen jeleztük a hívó félnek, hogy az eredményben van egy mező, amivel foglalkozni kell, tehát sokkal kisebb az esélye, hogy elsiklik a kezelése felett.

DI Container/Helper

Ha ezen mind túl estünk, már csak egy részlet maradt hátra, a DI Container pattern. Nagyon leegyszerűsítve a DI Container működését, van egy osztályunk, amely különböző egyéb osztályokat tárol kulcs szerint. Ha tehát példának okáért egy helpereket (segítő osztályokat) biztosító DIC-ről van szó, a HTML helpert így érhetnénk el:

$this->getHelper('html')->doSomething();

Namost, ez a kódrészlet szerintem ezer sebből vérzik. Honnan tudjuk, hogy a 'html' sztringet kell oda beírni? Honnan tudjuk, hogy milyen objektumot kapunk vissza? Ki garantálja, hogy annak az objektumnak lesz doSomething() metódusa?

Az első és legfontosabb dolog, amit tehetünk (illetve amire rávehetjük az általunk használt framework gyártóit), hogy készítsenek interfészeket a leggyakrabban használt helperekhez, szolgáltatásokhoz, DIC elemekhez stb. Ha lehet, ez az interfész tartalmazza konstansként a kulcsot, amivel meg lehet hívni, például így:

interface iHTMLHelper {
    const HELPER_NAME = 'html';
    
    public function doSomething();
}

A második lépés pedig az, hogy az általunk használt helperekre, szolgáltatásokra stb. gyártsunk kódkiegészítést lehetővé tevő függvényeket, például kiterjeszthetjük a DIC osztályt, és adhatunk hozzá egyéni függvényeket:

class MyProjectDIC extends FrameworkDIC {
    /**
     * @return iHTMLHelper
     */
    public function getHTMLHelper() {
        return $this->getHelper(iHTMLHelper::HELPER_NAME);
    }
}

Amennyiben esetleg PHP 5.4-et használunk, az egyes helperek ezeket a függvényeket akár traitek formájában rendelkezésre is bocsájthatják, hogy a saját DIC / helper osztályunkba csak be kelljen húzni.

Mindez minimális befektetés egy projekt elején, viszont napi szintű szívásokat és megakadásokat előz meg.

Alkalmazás meglevő projektekre

Ez mind szép és jó, de valószínűleg kevés ember dolgozik zöldmezős projekten, így az itteni elvek alkalmazása igen nehézkes. Éppen ezért érdemes egy szabályt bevezetni a csapatban: aki egy kódrészlethez hozzányúl, rendbe rakja. Ez sokszor nem triviális, és sok esetben nem is fog 100%-osan megtörténni, azonban már egész kis erőfeszítéssel nagyon komoly előrelépést lehet elérni a mindennapi munkák tempójában.

Ezen a ponton külön kiemelném a PHPStorm fejlesztőkörnyezetet, amely ugyan fizetős, de igen komoly eszközkészletet ad a PHP fejlesztő kezébe, például egy valóban működő refaktor (függvény- és osztályátnevező) eszközt, felhívja a figyelmet a hibás, illetve adott esetben problémát jelentő kódokra, és még sok minden mást is.

Végszó

Rossz kódot bármilyen programnyelven lehet írni, talán nem szégyen egy picit tanulni a szigorú(bb)an típusos nyelvektől vagy a usability szakeremberektől.

Támogatod? Ellenzed? Kérdésed van? Mondd meg a véleményed a kommentekben!