Lexandro weblogja

… avagy a collective code ownership tapasztalatok agile projekteken.

Bevezetés

A collective code ownership (továbbiakban CCO, mert nincs kedvem mindig beírni) az agile metodológiák egyikének az extreme programmingnek (XP) részét képező alapelv vagy szabály, ami szerint a kód egészéért maga a csapat felelős nem pedig az egyes fejlesztők, akik írják az adott kódrészletet. Azaz aki belenyúl valahol a kódba felelős azért, hogy a meglévő unit teszteket ne rontsa el, az új funkcionalitás coverage-e is az elvárt szinten mozogjon és a termék integritását se sértse meg. Általam hallott vagy olvasott szinonímák: code stewardship, shared responsibility, team responsibility.

Én bugom, te bugod, ő bugja = mi bugunk!

Képzeljük el azt a helyzetet, amikor valaki besubmittál egy olyan kódot, amitől elszáll a build vagy valamelyik unit teszt és borul a CI szerver (már ha van) vagy csak egyszerűen többek munkáját akadályozza a beküldött bug. Mi történik hagyományos esetben? Elkezdjük keresni a logokban, hogy ki küldte be, megkeressük az illetőt és szólunk, hogy javítsa ki, majd várunk, amíg megcsinálja. Lehet most idézni az okos módszertani könyvekből, de én a hétköznapi életről beszélek, ahogy a dolgok valójában történnek.

Elképzelhetjük azt az esetet is, amikor t. kollégánk unit teszt nélkül rak be új funkciót, amit akkor veszünk észre, amikor már 2 napja szabin van és még 5 napig nem fog előkerülni, de a coverage ott árulkodik róla, hogy valaki bizony slendrián volt.

Hogyan értessük meg a csapattal a CCO-t?

Eljutottunk oda, hogy a csapat felismerte a kód minőségével kapcsolatos problémákat és megoldásra van szükségük. Itt jön a képbe a CCO-t ismerő és alkalmaző szakember, hogy megtanítsa nekik azt a pár apró, de hasznos fogást, ami ehhez kell. Nem egy ördöngősség a CCO. Tényleg nem. A CCO lényege két dolgon nyugszik: 1. ha hibát találsz bárki kódjában, akkor javítsd meg, 2. könyörtelen refaktorálás (merciless refactoring)

Fix-it, improve it

Az írás elején említett példák közül az első és második esetben mit tesz egy CCO-t alkalmazó csapattag ha hibát talál? Anélkül, hogy más munkáját félbeszakítaná ő maga nekiáll és megfixálja a kódot. Miért? Mert nem csak az felelős érte aki írta, hanem ő is, aki épp a hibát találta. Valószínűleg úgyis az ő munkájával kapcsolatos, különben nem ő nézegetné (kevés kivétel azért akad) így simán belefér a feladatába, hogy azt a hibát is kijavítsa, amit eredetileg nem is várt, hogy felbukkan. Ugyanez igaz akkor is ha új funkciót kell hozzáírni egy olyan osztályhoz, amit nem ő fejlesztett. A régi megoldás az, hogy szólsz a fejlesztőnek és megkéred, hogy írja meg te pedig vársz rá és telik az értékes idő, de CCO-t alkalmazva nyugodtan nekiállhatsz átírni más kódját, mert az a ti kódotok, így mindenki nyer vele ha te is hozzáteszed a saját képességeidet. Ez a CCO első pillére.

Merciless refactoring

Idézzük fel a harmadik példát a gyengélkedő kóddal. A kolléga műve tűrhetően működik, de nem hozza az elvárt minőséget és teljesítményt. A CCO szerint nem mehetünk el szó nélkül egy ilyen probléma mellett, de nem az a megoldás ha készítőt zaklatjuk a javításért, hanem feltűrjük az ingujjunkat és mi magunk refaktoráljuk a kódot, amíg nem lesz olyan, amilyennek lennie kell. Bármikor ha találunk a kódban refaktorálható részt, bátran tegyük meg, mert ezzel javul a kód minősége és hosszú távon sok fejlesztési időt tudunk megspórolni, ami a határidők közeledtével igen értékessé válik a csapat számára.

Mi szükséges a CCO bevezetéséhez és alkalmazásához?

A legfontosabb, hogy a csapat magáénak érezze a célt a munka minőségének javítására és belássák, hogy a “jól bevált” – azaz legacy – módszerek nem elégségesek ehhez és változtatni kell. Ellenséges környezetben nem lehet ilyen változásokat erőszakkal bevezetni, meg kell győzni a csapatot a CCO szükségességéről. Ha már megvan az elhatározás, akkor aránylag fájdalommentesen alkalmazhatóvá válik az alapelv. A legfontosabb, hogy bevezessünk – ha eddig nem tettük – egy olyan coding standardet, amit a csapat összes tagjának kötelezően alkalmaznia kell a munkája során. Ez egyrészt megkönnyíti a tagok közti kommunikációt, másrészt kódot magát is olvashatóbbá teszi az összes csapattag számára.

A következő fontos lépés, hogy amit automatizálhatunk azt ne bízzuk az emberre, mert abban ott a hibázás lehetősége. Alkalmazzunk verziókezelőt a kódbázis karbantartásához (bár ezt szerintem már mondanom sem kell, mert mindenütt van egy cvs, svn, git, mercurial vagy más scm tool). Ezen felül írjunk unit teszteket a kódhoz, hogy a már elkészült munkánk folyamatos ellenőrzés alatt álljon és ne tudjanak mások akaratlanul is valami rejtett bugot hozzáírni a kódhoz.

A megírt teszteket érdemes minden kódváltozáskor újra és újra lefuttatni, de ez kézzel sok időt vinne el, ezért mindig írjunk olyan build scriptet, ami az IDE nélkül is képes a kódot lefordítani és a unit teszteket a kódon lefuttatni. Ezt automatizálhatjuk egy continuous integration szerverrel, hogy elvégezze helyettünk a piszkos munkát és visszajelzést adjon a munkánk minőségéről.

Fontos a kód elemző toolok (PMD, Checkstyle, FindBugz) használata is, hogy amit emberi közreműködés nélkül meg tudnak találni, arra ne kelljen dev munkaidőt pazarolni, elvégre a mi szakmánkban az idő kőkemény pénz nekünk és az ügyfélnek is. Ne pazaroljuk! Megkönnyíti az alkalmazásukat az az örvendetes tény, hogy a főbb build rendszerekhez (ant, maven) mindegyiknek van olyan kiegészítése, ami könnyen beilleszthetővé teszi őket a meglévő build folyamatba.

A automatizált tesztek újabb időnyerők számunkra. A tesztek lehetnek a már megírt unit tesztek vagy integration tesztek, end-to-end tesztek vagy a ui-t végigkattintgató scriptek is. Fontos, hogy a lehető legtöbb dolgot teszteljük le automatikusan, mert onnantól kezdve, hogy az adott teszt elkészül már nem kerül semmibe újra és újra futtatni.

Utoljára hagytam a pairinget, mert nem mindenhol alkalmazzák. Ha ismeretlen kóddal találkozunk, amin még nem dolgoztunk és nem vagyunk teljesen tisztában a funkciójával, akkor mindig kérjük meg az ügyfél valamelyik devjét, hogy pairingeljen velünk, mert az ő helyismerete a kódban kulcsfontosságú ahhoz, hogy ne törjünk el valami meglévő funkcionalitást és javíthassuk a kód minőségét. Elvégre nem érthetünk mindenhez és nem ismerhetjük az ügyfél rendszerének minden szegletét.

Tags: agile opinion ownership

Hogyan vedd rá deploykor a JPA-t, hogy észrevegye a JAR fájlokban lévő annotált entity-jeidet!

Van egy szép nagy lista a fejemben azokról a dolgokról, amiket nem értek. Ezek közül az egyik, hogy az itteni British Telecomos router hogyajófenyőbe tud 119kb/sec-es wireless copy sebességet nyújtani a hálózaton belül WEP128-al (Direkt vettem le a WPA2-PSK-t, nem kicsit bexarva, mert ha megtörik és torrenteznek rajta keresztül, akkor az én ánuszomba tol be egy méretest a helyi hatóság, de a MAC address szűrés valami picit azért segít… Nem sokat…) és megáll az egész netezés is mindenkinél, mert elfoglalom a sávszélt. 119kb/sec. Belső kopi az IOmega iConnectről a laposra tehát nyista internet forgalom.

Ezek a BT-nél valami nagyon gyanús dologra használhatjáka routereket, amikről mi nem tudunk és csak az ilyen jelekből következtet az ember, hogy esetleg fennforgás van.

Már nézegetem az ebayen a wifi adsl routereket, mert sosem árt ha van, mert ez nekem így nagyon nem tetszik virág elvtárs.

Arról nem is beszélek, hogy úgy általában a szolgáltatás minősége/sebessége/dns szerverek stabilitása egy f*s. BT netet ne kössön aki Angliában van, mert öntökönlövés. Lehet, hogy a többi rosszabb, de azt még nem próbáltam.

Esszel valaszd ki hajnalban hazafele imbolyogva azt a helyet, ahol husos melegszendvicset eszel a froccsok hatasat enyhitendo, kulonben ugy megpurgal a nem tul friss aru, hogy a vasarnapod egy reszet a fajanszon toltod…

Mexivtam na

Na megjövés olaszisztánból, ahol azt a mély következtetést sikerült levonni, hogy csúcsidőszakban a mediterráneumba menni bármi más céllal mint a tengerparton döglés baromság. Az ember 18.00 előtt konkrétan megrohad a melegben, de hát akkor zár minden, ezért erőt kell venni a nyamvadt testin és betántorogni aztán 30 percenként leugrik egy fél literes frizzante San Benedetto a gugádon vagy valami fagyi csak, hogy életben maradj. Az izzadtság csípi a szemed, mintát fest a hátadra, a hónaljadra és mindenhova, kiütéses leszel a sótól és fehér foltok jelennek meg a pólódon ha épp felszárad és egy halom japán túristát kell kerülgetned mindenhol és izgulni, hogy ne baxák ki a szemed a félméteres teleobjektívjeikkel, amit szerintem még a mobiltelefonjukra is rácsatolnak ha kell. Ha mindez még nem veszi el a kedved a kultúrált szórakozástól, akkor még ott vannak az árusok, akik vad lelkesedéssel üvöltik a füledbe, hogy csak ma, csak itt, csak most árengedmény van csak neked és okvetlenül vegyél órát, napszemüveget, bőrkabátot, papucsot, akármit. Nem értek én az árakhoz, de az egyetlen dolog, ami megtetszett egy szép bőröv volt, de a 32 eurós ár az én érzékszerveimnek sok volt, így maradt ott. Spatulával kellett szegény árust lefeszegetni rólam, amikor a távozás hímes mezejére léptem.

Összességében ettől még marhajó volt és a Lericiben üzemelő I Pescatori éttermet nagyon meleg szívvel tudom mindenki figyelmébe ajánlani ha nem túl árérzékeny az ember (37.5 euró a menüjük, de egy álom. Éhesen érkezzen oda mindenki ha jót akar magának), de ami engem dühít az a TomTom cég üzleti modellje. Nem elég, hogy a GPS-em europa térképéről valahogy lemaradt Olaszország, de konkrétan a teljes térképfrissítés után kell rájöjjek, mert voltam olyan naív barom, hogy azt hittem, hogy ha a németek, franciák, szlovének elférnek rajta, akkor esetleg a taljánoknak is jut valami. A fő bajom pedig az, hogy a rohadtéletért kerül ugyanannyiba egy szimpla olasz térkép, mint a teljes európai update-em. Azt hiszem, most löktek egy erőset rajtam abba az irányba, hogy feltört cuccokat kezdjek keresni, mert annak a fényében, hogy a Nokia pl. MINDEN okostelefonjához INGYENES navigációt ad (térképpel mindennel az Ovistore-ból) azért elég méretes pofátlanség engem egy csóró ország térképére így lehúzni.

Még fogalmam sincs mi lesz a jövő évi célpont, de a spanyol és olasz tapasztalatokon okulva a következő nyaralás is iroda nélkül lesz összerakva szállással, repjeggyel, autóbérléssel, mindennel együtt, mert nagyon flottul ment a dolog.

Ui.: egy csodás Golf TDI-t adott az ótóbérlő cég. Remélem nem fogok túl sok gyorshajtás cetlit kapni, mert mi tagadás meg sem kottyant a 180 annak gépnek

Ui2.: az elmúlt 2 évben meggyőződésem volt, hogy a spanyolok vezetnek a legszarabbul a világon, de az olaszok feljöttek az első helyre

Komolyan mondom olyan az idő itt Londonban, mint gyerekkorom nyarai. Pont jó strandolni, de nem ég szét az ember a parton és nem kell azon aggódnia, hogy mikor kap bőrrákot vagy valami egyéb nyanyaját az intenzív napfénytől Otthon meg a hírek szerint ha épp süt a nap, akkor ropogósra sül a jónép gyász. Igazándiból sok mesélnivaló nincs, mert az élet szépen megyeget, az asszony lenyomta a negyedévet mi pedig a kollégával intenzív lelkesedéssel míveljük a munkánkat a projon, amin egyre inkább körvonalazódik, hogy az eredetileg nekünk szánt feladatkörnél jóval nagyobb terület jut kettőnkre és ezzel együtt a felelősség is nagyobb, de én csak vigyorgok, mert ínyemre van, hogy a tervezésbe is aktívan bevonnak és sok dologban a mi elképzeléseink érvényesülnek.

És itt kell felismernem avagy meggyónnom azt, hogy amit az előző projekten csináltunk Yeovilban, abból egy csomó dolgot átvettünk, mert mégis jó dolog, csak ott és akkor valahogy nem láttuk a big picturet illetve ott mintha tudták volna, hogy ez jó dolog csak valahogy nem volt teljesen összecsiszolva a processz. Arra gondolni sem merek, hogy esetleg azért nem éreztük hasznosnak, mert abban az idegállapotban dolgoztunk sokáig, hogy gyakorlatilag még a kockára is rámondjuk, hogy gömb, hogy ne legyen annyira igazuk. A fene tudja. A lényeg, hogy az ott tanultakat elkezdtük alkalmazni és el kell ismerjem, hogy jól működnek, bár az is igaz, hogy most nem egyszer kódipari segédmunkásként verjük vakon a cuccot a gépbe, hanem aktívan résztveszünk a tervezésben, látjuk a teljes rendszert és processzt.

A londoni élet pedig kezd abba a kerékvágásba kerülni, amikor az ember nem azért járkál, hogy valami látnivalót lásson hanem mert éli az életét. Vásárlás, kis pub látogatás, mászkálgatás néha valami programra és ilyesmik. Nagyon bejövős. Még mindig nem bírom elhinni, hogy simán eltölthetek egy nyarat Londonban Aki esetleg mégis kijön az nagyon nem fogja megbánni. Pezseg itt az élet minden nap és a tegnap sétakor fedeztük fel, hogy az Old Spitalfield Market éjjel is erősen éli az életét a rengeteg bulihely, bár és kocsma jóvoltából. 150m gyalog

Vagy nem is tudom, hogy hívjam a lényeg, hogy elvonultunk a kollégákkal Barbican közelében egy The Shakespeare nevű kricsmibe, hogy mindenki fizethessen nekem egy sört, ha már máshogy nem bírtak kinyírni 35 év alatt. Természetesen alapos voltam, így olyan helyre mentünk ahol van televízió, mert a team  nem normálisabb része VB lázban ég és ezt illik tiszteletben tartani. Én az elején próbáltam udvarjas érdeklődéssel szemlélni a tévében azokat a fura szerkós csávókat, de hamar odakinn találtam magamat a VB mentes résszel és ott osztottuk az eszet, a sör meg gyűlt bennem előttem és éreztem, hogy egyre okosabb leszek, de végül az egész team ott kuksolt kinn, mert borzasztó szar meccs volt mi meg csendesen iddogáltunk én sikeresen el is törtem egy poharat. Ez nálam lassan sport, hogy ha nem is török el valamit egy ilyen alkalommal, azért egy felborítás mindig benne van a pakliban. Hátezva’… Mindenesetre jót tett a fejemnek a hazagyaloglás Barbicanről, legalább tisztultam.

Egyébként nyár, uborkaszezon, szívás mindenféle kódokkal meg titkosításokkal, de az nem olyan érdekes és sokkal kevesebben értik, mint a sört Megjegyzem jelenleg Londonban olyan az idő, mint régen otthon azaz marhameleg van, de nem gutaütögető hőség. Azért erősen tanulmányozni fogom holnap az ángélusokat a melóban és ha látuk rajtuk valami rövidebb szárú gatyát, akkor én is bejövök péntekenként olyanban ha ilyen lesz az idő, mert totál beleolvad az ember a gatyájába. Pföhh.

Nem szeretem a DTO(Data Transfer Object) patternt, mert sok zavart okoz a devek közötti kommunikációban és igen szépen keverik is a szerepkörök definiálásakor, ezért már jóideje nem használom (nem kis részben Váradi úr nyomására ). DTO-val két helyen szoktam találkozni általában. Egyrészt a perzisztencia layerből érkezik a DAO-ból, másrészt a service/manager layeren keletkezhet adatot tárolni/cipelni. A dev társadalom ezek okán igen szépen össze tudja keverni ennek a patternek a használati helyét, de egy patternnek megvan a használati módja és az, hogy mikor kell használni, de a DTO leírása túl generikus, ezért én kettő másikkal helyettesítem.

Pattern: Entity

Az Entity szerepű DTO-k a DAO layerben keletkeznek és manapság már jól meg is annotálja az ember és a fő szerepe , hogy a DB-ben lévő fizikai adatokat reprezentálja azaz a DAO objektek Entity-ket adnak vissza/mentenek el.

Pattern: Domain object

A DAO-ból a Service/Manager osztályokba érkező objektumot mi általában konvertálni szoktuk*, hogy ne legyen kapcsolata a perzisztencia layerrel még ha ez igényel is némi extra ramot/cpu-t. Ők a domain objectek, akik lemodellezik a memóriában a teljes adatszerkezetet és kapcsolatokat és ezek már tényleg színtiszta POJO-k. A konverzio mindkét irányba működik, tehát a DAO-ba már Entity érkezik és az kerül letárolásra.

Szóval ha lehet kerüljétek a DTO elnevezést ezekben a szerepkörökben és inkább Entity/Domain object néven emlegessétek szerepkörtől függően.

*Mostanában játszadozok a gondolattal, hogy esetleg az Entity-t detacholjam a service layerbe küldés előtt és aztán azzal dolgozzak tovább, majd visszaérkezéskor merge, de még nem próbáltam ki komolyabb környezetben.

Nem igazan konnyiti meg az ember munkajat a felgyulemlo tapasztalat es tudas, mert amig kevesbe edukalt allapotban az a kerdes, hogy “na ezt most, hogyan kellene megoldani” addig elorebb jutva szaktudasilag erre modosul: “Oke van 2-3 mod is megoldani, de melyik a legjobb?”.  Es ez esetben az ember tiprodik mint a szarogalamb, mert nem akar ganyt kiadni a kezei kozul (es a tavoli jovore, a karbantarthatosagra es a kollegak vadlo tekintetere is gondolnia kell) es pont ugyanakkora stressz mint a “nem tudom, hogy kell megoldani” problema.

Konkretan most pont ezen tiprodtunk Varadi kollegaval, hogy mi lenne a legjobb megoldas es ezen heheresztem egy sort, hogy mekkora mar, hogy a megoldasok sokasaga es sokszinusege kot minket guzsba. Egyebkent az alkalmazas tesztelhetosegevel kapcsolatos problema volt.

Ilyenkor a kovetkezo szempontokat vesszuk figyelembe:

• az alkalmazas kodja ne tartalmazzon olyan reszeket, amiket csak a teszteles miatt raktunk bele, mert eles szerverre rakva ezek kiskapuk lehetnek vagy a performanciaban okoznak zavart
• a konnyen ki es bekapcsolhato legyen a tesztuzemmod
• a build kepes legyen teljesen teszt mentes kodot eloallitani az eles uzemhez
• ne kelljen kezzel hekkelni a feluleten csak a teszt kedveert

Kicsit altalanosabb szempontok

• konnyen karbantarthato legyen
• mas is konnyen megertse*
• minel egyszerubb legyen, nincs szukseged nagy flikkflakkokra
• akkor van kesz, ha mar nem tudsz elvenni belole es nem akkor, ha mar nem tudsz hozzatenni

Megnyugtatasul kozlom, hogy sikerult talalni olyan megoldast, ami talan meg a Nagyember rosszallo tekintetet sem valtja ki Nagyember Driven Development hehehe.

* jomagam nagyon hiszek abban, hogy ahhoz, hogy egy cegnel az ember hasznossa valjon pont nem arra van szukseg, hogy nelkulozhetetlenne tegye magat hanem arra, hogy barmikor lecserelhessek es mashol bevethessek. Azaz olyan kodot ir, ami mindenki szamara konnyen olvashato, egyszeru, atlathato, konnyu megerteni es folytatni. Ha a fonokod tudja rolad, hogy barmikor atrakhat egy masik projra, ahol tobbet kerhet erted es a helyedre rakhat egy kevesbe tapasztalt/kepzett embert (vagy csak projt akar valtani a ficko), akkor nagyon fogja szeretni, hogy ilyen jolly-joker vagy nem pedig egy titkaidat kemenyen orzo, onzo valaki.

Na megint betoltam egy évet az életkor dossziéba, nem sikerült kicsinálnia senkinek hehe. Ezért ez a 35 elég ütős szám nem? Legoptimistább becsléseket, statisztikákat nézve ez erősen félút a bölcső és a koporsó között (persze kerekítési hibákkal), persze ha mondjuk azt nézem, hogy igazándiból olyan 20 évesen vágtam a lecsóba, addig lájtosan éldegéltem és akkor csak 15 év telt el az effektív (önálló, íverérett, maga ura) életemből, de a hátralévő évek darabszáma ettől még nem változik. Sajna

Asszem kicsit érdemes lenne visszatekinteni az eddig eltelt életemre, amit magamban meg is tettem, de engedelmetekkel nem fogom most felsorolni mindama hibákat, amiket elkövettem, mert nem akarok megsérteni senkit. Nem mindenki hiszi, hibának azt amit én, nem kell a feszkó hehehe.

Nincs okom panaszra, mert azok az emberek, akiket a barátaimnak tartok igen-igen sok éve megvannak (van aki már 20 éve, igaz Pepe?) tehát van akikre bizton számíthatok jóideje. A munkámmal kapcsolatban azt látom, hogy megtaláltam lassan a helyem és egész pontos elképzelésem van 1-5-20 évre vonatkozólag, hogy hol szeretnék tartani és haladok is arra. Ez nem volt mindig így, de szerencsére kiszakadtam abból a milliőből, ahol nem igazán voltak vevők az ötleteimre és most egy egészen más atmoszféra vesz körül és ez jó. Egzisztenciailag ismét csak azt mondhatom, hogy biztonságban érzem magam annyire, amennyire a helyzetemben ez lehetséges és számomra ez a legfontosabb, nem pedig a menő cuccok, májer verdák, arcoskodás mások előtt üres zsebbel. Az igazat megvallva ez az életkor pont egy remek időpont a komolyabb nyugdíjtervezés megkezdéséhez, amit meg is fogok tenni sok-sok exceltábla és fejvakarás közepette. A magánéletemről nem beszélek, mert nem kötöm az orrotokra kis kíváncsiak, elmondom annak, akit illet ugye. Az élettől megkaptam a kötelező pofonokat, kijózanodtam, leszálltam a felhők széléről, ami egy kicsit fáj is az embernek, hogy fel kell adnia a képtelen álmait, de ez az ára a tapasztalatnak. Cserébe nyugodtabb lettem, türelmesebb, elviselhetőbb és egyesek szerint megint sokat komolyodtam. Lassan felnőtt emberré érek nem?

Sajnos a Húsvét szigetekhez nem sikerült még eljutnom megnézni a kőfejeket, de rajta van a listán és úgyis elevickélek oda baszki ha törik, ha szakad. A jófenébe bírt az a halom benszülött az óceán közepére mászni és ott építkezni azt fel nem foghatom, de pont emiatt a felfoghatatlanság miatt akarok odamenni

Na jóccak. Most csak ennyire futotta, az igazi ünneplés hétvégére marad