Szél Péter

Nem vagyok nagy rajongója a hagyományos humán-reál felosztásnak – egyszerűen nem így működik a világ. Amikor programkódot írsz, azt nem csak egy gép számára írod, hanem embereknek is, több szempontból is. Egyrészt a programot végül jó eséllyel emberek fogják használni, másrészt emberek fogják karbantartani.

Kinek íród a programot? Számítógépnek vagy embernek?

Emberek fogják használni az alkalmazásodat

Az egyik legerősebb érvem a címben megfogalmazott állítás mellett, hogy az általunk készített programokat embereknek írjuk. Persze, vannak kivételek, elvont célú programok, többségében mégis elmondható, hogy mindig a felhasználót kell szem előtt tartanunk, ha sikeres alkalmazást szeretnénk kiadni a kezeink közül.

UI First

Ki ne tapasztalat volna már olyat, hogy a szoftver megrendelőjétől azt az utasítást kapjuk, hogy csak kezdjünk el programozni, haladjunk, majd később kitalálják, hogy hogyan is fogják használni az új funkciót.

Ez a megközelítés soha nem lesz sikeres. Mindig a felhasználó szempontjából kell megközelíteni a kérdést, hogyan fogja használni, hogyan lesz a kényelmes számára. Innen kiindulva kell megtervezni a program alsó rétegeit is, a UI-tól kiindulva, a backenden át az adatbázisig.

Webfejlesztés esetén például, az a szerencsés, ha rendelkezésre áll az adott funkcióhoz tartozó UI mockup és annak részletes leírása a fejlesztés megkezdésekor.

User Story

A Scrum metodológiában a User Storyt használjuk erre a célra, amely kifejezetten arra kényszerít minket, hogy a felhasználó szemszögéből közelítsük mega a feladatot. Elvárás, hogy minden User Story tartalmazza, hogy az adott funkció pontosan mely felhasználók igényeit elégíti ki, mire lesz jó, valamit miért lesz a felhasználónak teljesebb az élete az adott funkciónak köszönhetően.

Felsorolt három pont szigorúan kötelező, egyik eleme sem hagyható el. Sajnos a "miért" kérdésre adott válasz igen gyakran elmarad, holott ebben az esetben a fejlesztők téves következtetéseket vonhatnak le, erre alapozva teljesen használhatatlan program születhet.

Két befogadó számára írod a kódot

Az egyik legfontosabb, amit észben kell tartani, miközben kódot írunk, hogy az alkotásunknak két befogadója lesz: a számítógép, amely végrehajtja utasításainkat és egy programozó aki hibajavításokat és módosításokat végez rajta.

Nagyon érdekes a helyzet, hiszen a két-két befogadó egészen más elvárásokat támaszt. A számítógép szempontjából lényeges, hogy hatékony programot készítsünk, jól megválasztott adatszerkezetet használjunk és elég gyors algoritmust írjunk. Ezzel szemben a programozó, aki olvasni fogja a kódunkat, annak örülne, ha könnyen meg lehetne érteni, valamint szükség esetén könnyedén lehetne módosítani rajta.

Mitől lesz olvasható a kód?

Számos könyv foglalkozik ezzel a kérdéssel, számomra 3 alappillére van az olvasható kódnak:

1. Értelmes elnevezések.

A változóinkat, metódus neveinket értelmesen megválasztva sokat javul a kód olvashatósága. Ha pl. az m nevű változó helyett kiírjuk, hogy message, akkor az utánunk következő programozó is érteni fogja, hogy mit reprezentál a változó. Szakítsunk időt az elnevezések végiggondolására!

2.Rövid metódusok, osztályok.

Ha egyetlen metódusban szeretnénk megvalósítani teljes funkciókat, hamar több száz soros metódusokhoz jutunk, melyeket nagyon sok ideig tart értelmezni. Sokkal szerencsésebb, ha a metódusaink csak egy-egy feladatot látnak el, hiszen több, kisebb metódust gyorsabban tudunk értelmezni.

3. Értelmesen kell használni az adott programozási nyelv/keretrendszer eszközeit.

Jó példa erre a legtöbb nyelvben elérhető ?: operátor. Attól még, hogy a nyelv biztosítja a funkciót, nem biztos, hogy ez lesz a legjobb választás az adott probléma megoldására, sőt. Sajnos találkoztam az alábbihoz hasonló programkóddal:

    isEnabled ?
    <20 sor kód>
    :
    <20 sor kód>;

Remélem, mindenki látja, hogy ez rossz ötlet. :) Az olvashatóságot nehezítendő, néha egymásba ágyazva is megtalálható a fenti szerkezet.

A másik jó példa a jQuery könyvtár által biztosított láncolhatóság. Minden függvény visszatérési értéke az adott példány, így azon újabb metódusokat hívhatunk:

$('#id').css('height', '100px').show();

Egyszerű esetekben, mint az előbbi példában, ez nem okoz nagy problémát. Viszont hosszú, bonyolultabb láncolatot írni, esetleg láncokat egymásba ágyazva megvalósítani a kívánt funkciót, garantáltan olvashatatlan kódhoz vezet.

Ehelyett tehát szerencsésebb, ha külön változóba tároljuk a jQuery objektumot, és soronként hívjuk meg az egyes függvényeket.

Ha tetszett a bejegyzés, mások számára is hasznos lehet, akkor oszd meg az alábbi gombok segítségével!