A budapest.rb (Budapest Ruby Meetup) szeptemberi újjáéledésén felbuzdulva vittünk egy előadást a múlt heti alkalomra.
Az előadás anyaga innen is elérhető: “Agilis és extrém ruby”, valamint ebben a bejegyzésben megpróbálom a meetup-on kialakult beszélgetés / interaktív előadás lényegét összefoglalni. (A videó felvétel nem tudom hogy sikerült, talán később az is elérhető lesz.)
- platform független
- objektum orientált
- egyszerű szintaxis, olvasatos kód
- flexibilis - teljes szabadságot ad a programozónak
- produktív, élvezetes programozás
- principle of least surprise
A ruby-ra épülő népszerű Ruby on Rails keretrendszer pedig ezt még kiegészíti a következőkkel:
- Modell-View-Controller architektúra - az üzleti logika elválasztása a felhasználói felülettől
- Don’t Repeat Yourself - ne írd le többször ugyanazt a kódsort, csökkentsd a redundanciát!
- Convention over Configuration - a konfigurációs állományok minimalizálása
Mindezt azért fontos felsorolni, mert legfőképp ezekből következik az, hogy hogyan lehet hatékonyan alkalmazást fejleszteni:
- minél kevesebb kód - ezáltal kevesebb hiba lehetőség és könnyebb karbantarthatóság
- olvasatos kód - kevesebb magyarázatot és dokumentációt igényel
- teszt vezérelt programozás - jobb minőségű kódot és szintén kevesebb hibát eredményez
A ruby és a rails azért segíti az agilis fejlesztést, mert "ebben a korszakban nőtt föl" és alapvetően erre lett kitalálva, e mentén fejlődik tovább, napjainkban is. Továbbá rengeteg - a fejlesztést vagy módszertant támogató - eszköz készül ruby-ban, ami még könnyebbé teszi a programozók életét.
Tapasztalatok
Az elmúlt években nagyon megszerettük a ruby-t, amikor csak tehetjük - pl. termékfejlesztésben - ruby-ban fejlesztünk. Nehéz olyan feladatot kapni, aminek megoldására ne lenne alkalmas, ráadásul nagy mértékben újrafelhasználható.
Készült sok saját fejlesztésű csomagunk. A saját csomagok kapcsán rájöttünk, hogy minél alacsonyabb szintű komponenseket kell írni, amik önálló, független funkcionalitással bírnak. Fontos, hogy már a tervezéstől kezdve ruby szintű GEM-ekben gondolkozzunk és ne Rails - vagy más keretrendszer szintű - plugin-ban, ezáltal még hordozhatóbb és könnyebben karbantartható kódot kapunk. A GEM-ek verziókövetése, függőségeik kezelése is jobban megoldott, legfőképp az új Bundler nevű csomaggal, amit akár Rails 2.3-tól használhatunk.
A fejlesztői környezet karbantartása, a technológiai újítások megismerése az igen intenzív fejlesztési Sprint-ek alatt nehéz feladat. Éppen ezért mi azt találtuk ki, hogy a Scrum csapat(ok) mellett párhuzamosan dolgozik egy Maintenance csapat. Ezáltal megoldódik az a probléma is, hogy az egyik rendszerben adott nap kiderül egy kritikus hiba és sürgősen ki kell javítani - amivel alapesetben egy Sprint-ben dolgozó kollegát kellene megzavarni.
A Scrum és XP-vel kapcsolatos további tapasztalatainkat a letölthető előadásban lehet részletesen megtalálni.
