RSS Feed LinkedIn Google Plus

Címke: Coderetreat

  1. Kell-e a seed a randomhoz?

    2013. április 20. szombat

    Olvastam egy jó cikket a JavaScript-beli Math.random()-ról. Ha csupán (pszeudo)véletlen számokat szeretnénk, akkor tökéletes, számomra nagyon szimpatikus volt, hogy nem kell más nyelvekhez hasonlóan inicializálni. Ez teljesen feleslegesnek tűnt egészen a legutóbbi és egyben első magyarországi Leacy Coderetreat-ig, amikoris megörökölt, véletlenszerű működésre alapuló programot kellett helyrepofoznunk, karbantartanunk. Az első lépés természetesen a tesztek írása – no, de hogyan? Más programnyelvben dolgozó kollégáim könnyen megoldották a kérdést, hiszen beégetett seed-et használtak a teszt adatok generálásához (itt akadtak gondok, amikor különböző platformon más sorozatot adott ugyanaz a seed), nekünk, script nyelveseknek más utat kellett járnunk: legeneráltuk előre a random számokat, és mindig ebből dolgoztunk.

    A fent említett cikkben több megoldás is található, ha nem elsődleges szempont a sebesség, de szükségünk van előre tervezhető véletlenszerű értékekre, David Bau megoldása tökéletes választás lehet JavaScripthez. Hátránya, hogy a natív Math objektumot módosítja, előnye viszont hogy transzparens – teszthez bekapcsolhatjuk, éles környezetben pedig továbbra is az eredeti Math.random() állhat rendelkezésünkre.

    Remélem, sikerült felkeltenem az érdeklődésedet, s bár a következő (egyben Legacy) CodeRetreat-re nincs már több hely, ha feliratkozol a Meetup.com-on, értesülhetsz a további lehetőségekről.


  2. A kódunk legyen öndokumentált!

    2012. december 15. szombat

    Kérlek, mondd el röviden, mit csinál az alábbi CoffeeScript kód!

    uglyStep = (arr) ->
        res = []
        arr.forEach (a) ->
            count = 0
            arr.forEach (b) ->
                count += 1 if \
                    Math.abs(a.x - b.x) <= 1 and \
                    Math.abs(a.y - b.y) <= 1 and \
                    (a.x != b.x or a.y != b.y)
            res.push(a) if 2 <= count <= 3
        arr.forEach (a) ->
            for i in [-1..1]
                for j in [-1..1]
                    live1 = arr.some (cell) ->
                        (cell.x == a.x + i and cell.y == a.y + j)
                    live2 = res.some (cell) ->
                        (cell.x == a.x + i and cell.y == a.y + j)
                    unless live1 or live2
                        current = {x: a.x + i, y: a.y + j}
                        count = 0
                        arr.forEach (b) ->
                            count += 1 if \
                                Math.abs(current.x - b.x) <= 1 and \
                                Math.abs(current.y - b.y) <= 1
                        res.push(current) if count == 3
        res

    Ha a válaszban olyan szavak szerepelnek, hogy „végimenve”, „megnézzük”, „hogyha egyenlő”, az mutatja a problémát. A kódnak önmagában érthetőnek és világosnak, vagyis öndokumentált jellegűnek kell lennie. Viszont dokumentációban és a tesztekben azt írjuk le, hogy mit csinálunk, nem azt, hogy hogyan. (more…)


  3. Second Global Day of Coderetreat

    2012. december 8. szombat

    Hű, nagyon jó volt! A teszt vezérelt fejlesztés már rutinosan ment, így tudtunk a feladatra koncentrálni, és nagyon élveztem a páros programozást. :) Kódoltam C++-ban is (eleinte csak néztem, ahogy a társam kódol, de aztán fokozatosan felelevenedtek az emlékek). Jó partnereim voltak, és mivel minden egyes sessionban elölről kellet kezdeni a kód írást, nem mentem bele hitvitákba: ha a társam kötötte az ebet a karóhoz, ám legyen, egy sessiont kibírunk, és levonjuk belőle a tanulságot. (Igaz, az első sessionban én is egy rossz statégia mellett kardoskodtam.) (more…)


  4. Legacy Code Retreat Day

    2012. november 17. szombat

    Legacy kód az, amihez nincsenek tesztek.

    Ma volt a magyarországi első Legacy Code Retreat Day, melynek során a megörökölt – specifikáció és leírás nélküli, kissé hibásan működő, a spagetti elvet szem előtt tartva készült – kódot kellett először is megértenünk, majd javítanunk és újabb funkcionalitással ellátnunk. Az elmélet nagyon egyszerű:

    • a kód átláthatatlan és érthetetlen, nem is tudjuk mit csinál
    • először is megértjük – szükség esetén eközben készítünk megértési refaktorálásokat, amiket később visszavonunk (!)
    • generálunk egy end-to-end tesztet, hogy a jelenlegi funkcionalitást semmiképpen se rontsuk el
    • a kódot elkezdjük kijavítani, hogy karbantartható legyen, eközben a funkcionalitást egyre jobban unit tesztekkel fedjük le, mindezt megtámogatva a generált e2e teszttel
    • ahogy halad az idő, az open closed szemléletet igyekszünk érvényesíteni: a kódunk legyen nyitott a bővítésre, de zárt a módosításra, vagyis az új funkcionalitás megvalósítása esetén új dolgokat kelljen hozzáadni, ne a régit módosítani
    • és így tovább…

    Sajnálatosan azonban a jelenlevőknél legtöbb esetben működtek a régi reflexek: itt a kód, itt az elvárt módosítás, no gyorsan javítsuk ki, és kész. Ja, hogy nem biztos, hogy jó lett? Hogy a javítás esetleg egy másik részt elronthat… És mégis sok esetben inkább nekiálltunk hack-elni…

    Többünk tapasztalata szerint az elkészült tesztekkel exponenciálisan nőtt a fejlesztői magabiztosság, hiszen már tudtam mit csinál, és azt is tudtam, hogy ha változtatok és a tesztek jók, akkor rendben van.

    Számomra a nagy ötlet az volt, hogy az elején (rögzítve a random számokat) generáltunk egy elvárt input-output, ami az esetek túlnyomó részét lefedte, így ezt ellenőrző pontként felhasználva el tudtuk kezdeni egyáltalán fejleszthetővé és karbantarthatóvá tenni a kódot.

    Hallottam kollegákat áradozni a páros programozásról, nekem eddig egyáltalán nem voltak jó tapasztalataim e téren, és sajnos ez a nap sem hozott radikális fordulatot. Nem volt rossz, de ott volt az érzés, hogy egyedül lehet, hogy jobban haladtam volna.

    A helyszínt és az ételt-italt (beleértve az ebédet) az emarsys biztosította, az elején tartottak egy rövid bemutatkozást, és az iroda is nagyon szép volt. A web konferencián beszéltem még Merklik Lászlóval, náluk a TDD mindennapos gyakorlat, ezért is támogatták a rendezvényt, és örülnek, hogy vannak lelkes, szombatjukat is rászánó fejlesztők Magyarországon. Köszönet a szervezőknek (Devill és Athos)!