Agilni projekti - osmotska komunikacija

Razporeditev prostorov in delovnih mest lahko pomembno vpliva na potek projektov, ki se izvajajo v hiši. V večji meri zaposleni nimajo vpliva na razporeditev po svoji izbiri, zato je toliko bolj pomembno koliko se komunikacije med programerji, o tej "podvrsti" govorimo tu, zavedajo odgovorni. Neprimerni prostori že sami po sebi slabo vplivajo na storilnost, nedostopnost informacij pa zadevo še poslabša.

Izraz osmotska komunikacija izhaja iz biologije, a ga lahko prenesemo v bolj abstraktne koncepte. Pomeni tok informacij v ozadju, ki ga nezavedno filtrirajo člani skupine na ožjem delovnem območju. To običajno pomeni skupino ljudi v istem prostoru. Ob zastavljenem vprašanju se lahko posamezniki vključijo v diskusijo ali pa tudi ne, po lastni presoji. Največkrat osmotska komunikacija niti ne pomeni diskusije, ampak samo kratek stavek, ki bodisi odgovori na vprašanje ali pa popravi kaj že izrečenega, morda izrazi pomislek ali nestrinjanje. Z zdravo mero pameti tako dosežemo hitre in spontane odgovore na vprašanja, ki ne motijo delovnega procesa posameznika. Za posamezne faze projekta je lahko take vrste komunikacija povsem dovolj in lahko celo prepreči kakšen dolgočasen sestanek. Za majhne projekte je tovrstno komuniciranje lahko celo večinsko, običajni sestanki pa bolj redki. Že sama fizična oddaljenost običajno preprečuje zastavljanje vprašanj izkušenejšim na določenem področju. Sam zelo pogosto uporabljam poštne liste za razvojnike odprtokodnih projektov za iskanje odgovorov ali tehnik, to pa zahteva čas, predvsem takrat, če odgovora še ni na voljo na listi. V takem primeru moramo računati na dobro voljo nekoga z ustreznim znanjem, da nam odgovori na običajno zelo specifično vprašanje. Veliko pogostih vprašanj je na takih listah že odgovorjenih ali zbranih v FAQ datotekah za lažji dostop. Če sedimo v manjši skupini, po možnosti še z možnostjo hitrega pogleda na sosednji monitor z ustrezno informacijo, dobimo odgovore v rangu sekund, mogoče minut, kar je bistveno pri hitrem razvoju.

Najverjetneje se bo uveljavila tudi video konferenčna zveza med udeleženci, a bo to zahtevalo prilagajanje mediju in bo težko nademestilo osebni kontakt, papir in svinčnik. Obstajajo urejevalniki programske kode (in seveda besedil), ki dopuščajo hkratno urejanje istega modula, če na primer potrebujemo nasvet kako sprogramirati določen odsek kode. Tako ni potrebno združevanje prek sistemov za upravljanje z izvorno kodo (CVS, Subversion, SorceSafe, ...), če nam to ustreza. Vse je seveda odvisno od urejenosti delovnih procesov in nenazadnje tudi od navdušenosti posameznikov za napredne in ne vedno tudi koristne pripomočke.

Razporeditev pisarniškega pohištva v prvi meri vpliva na osebni prostor posameznika, neposredno s tem pa na odnose med sodelavci. V odvisnosti od narave dela so se izoblikovale tipične konfiguracije miz, predelnih sten in samih pisarniških sob. Vsakemu posamezniku seveda ustreza nekaj česar drugemu ne. Nekoga moti, da mu drugi lahko gledajo v monitor vsak trenutek, drugega (beri mene) moti, če nekdo konstantno trese mizo, spet tretjega ne moti, da mora vsakič vstati, če hoče pogledati sogovorca in tako naprej. Fino je, da obstaja prostor kamor lahko na trenutke "zaidemo", da prekinemo rutino ali da se umaknemo iz skupine. Najbolje je, da obstaja na firmi neformalna soba za sestanke. To je nekakšna večnamenska soba kjer poleg običajnih sestankov lahko naključno s kakšnim kolegom (ki ne kadi :-)) mimogrede izmenjamo kakšno idejo. Kajenje sem omenil z razlogom. Kot bivši kadilec lahko z gotovostjo rečem, da se je v vseh čik pavzah povedalo poleg nujnih govoric tudi precej, če ne večino, s službo povezanih zadev. Ne gre pa pretiravati s temi pavzami - slej ko prej postaneš aktualna tema udeležencev ne-čik pavz.

Slaba lastnost osmotske komunikacije je ta, da generira veliko šuma in da običajno predstavlja breme za vodilnega razvojnika, ki največkrat odgovarja na vprašanja. Veliko komunikacije pomeni za nekoga motenje svojega dela in tako postane manj storilen ali pa sploh ne dosega svojega potenciala. Vodilni razvojnik(i) običajno najdejo svojo rezino miru po običajnih delovnih urah ali čez vikend. Boljše, čeprav nenaravno, je doseči dogovor o tihi uri ali dveh. Nazadnje se vse konča pri posamezniku in njegovem značaju, o čemer pa bom pisal v nadaljevanju člankov o agilnih projektih.

Cayenne

Vsi vemo, da je zadan problem rešljiv na veliko načinov. Ena izmed možnih poti pri izdelavi dinamične spletne aplikacije je tudi uporaba ORM (Object Relational Mapping) ogrodij. To je programska tehnika, ki podatkovno bazo predstavi kot objektno strukturo.

Zakaj bi si sploh želeli imeti podateke zapisane v bazi v aplikaciji predstavljene kot graf objektov? Odgovor je zelo podoben tistemu, zaradi katerega je veliko programerjev opustilo proceduralne programerske tehnike in jezike ter osvojilo koncepte objektnega programiranja. Ljudje lažje razmišljamo o objektih, njihovih lastnostih in povezavami med njimi, kot pa o tabelah in vrsticah podatkovne baze (po lastnih izkušnjah velikokrat nenormaliziranih).

Uporaba relacijske baze za shranjevanje objektno orientiranih podatkov vodi v semantični prepad - programerji moramo(jo) programsko rešitev snovati tako, da mešajo dva pristopa. S podatki operiramo na objekten način, shranjujemo pa jih relacijsko. Združevanje tehnik na tak način pomeni zadajanje omejitev enega na drugega in obratno. Prihaja do tako imenovane impedančne nezdružljivosti. SQL podatkovne baze so sestavljene iz niza tabel, ki vsebujejo elementarne podatke. Posamezen zapis v taki bazi se običajno razteza čez več tabel, ki jih moramo za aplikativne potrebe pred tem združiti. S tem hočem povedati, da moramo pri pisanju poizvedbe navesti tudi relacije med njimi.

Uporaba SQL stavkov bo vedno hitrejša rešitev, ob predpostavki da je to v celotnem kontekstu problema najbolj kritičen člen. ORM rešitve podatke na veliko shranjujejo v medpomnilniku, kar je resnično velikega pomena za visoko zmogljiv sistem.

To je bilo nekaj malega v splošnem, zdaj pa še o Cayenne. Ogrodje se zgleduje po EOF (Enterprise Objects Framework), ki velja za enega izmed najboljših. Tabele in vrstice so v pomnilniku predstavljeni kot graf objektov. Nad tem grafom objektov izvajamo čisto običajne operacije kot bi delali z javanskimi zrni. Cayenne spremlja kaj počnemo s posameznimi objekti in relacijami med njimi in ko je čas za zapis v bazo, ogrodje samo izgradi optimizirane SQL stavke. Podatkovne baze različnih proizvajalcev lahko združimo v enoten podatkovni vir do katerega dostopamo prek enega vmesnika. To pomeni, da imamo lahko več dislociranih podatkovnih baz, ki v navezavi z naprednim (Cross-VM Cache Sharing) mehanizmom omogoča skalabilne aplikacije.

Običajno najprej popišemo problem, ki ga želimo aplikativno rešiti. V tem procesu spoznamo naravo podatkov in relacije med njimi. Entitetni model lahko prenesemo v Cayenne Modeler, ki je vizualno modelirno orodje. Z njim lahko tudi preberemo že obstoječo podatkovno shemo in iz nje tvorimo javanske razrede, lahko pa iz modela naredimo shemo - imamo skratka dvosmerno povezano operacijo. S tem orodjem se posredno izdelajo vse konfiguracijske datoteke, ki jih potrebuje naša (spletna) aplikacija. Cayenne je agnostičen na prezentacijski nivo. Java razredi se avtomatsko zgenerirajo "v paru", vedno se naredi še podrazred, v katerega mi dodajamo poslovno logiko. Na ta način lahko Cayenne Modeler ob spremembi (npr. dodan ali spremenjen atribut tabele) prepiše "očeta", ne pa tudi naše dodatne logike. Ne potrebujemo razmišljati, če tega eksplicitno ne želimo, o primarnih ključih, ker to ni v OO (Object Oriented) semantiki. Ker so vsi podatki o preslikavah v posebnih konfiguracijskih datotekah, ki jih izdela prej omenjeni Modeler, je v samih razredih lahko samo čista poslovna logika, kar je lep način ločitve odgovornosti.

Iz svojih izkušenj lahko povem, da je arhitektura aplikacije in koda veliko lepša, če si lahko privoščimo toliko svobode pri načrtovanju.

Eclipse

Eclipse kot razvojno okolje sem začel uporabljati pred slabimi dvemi leti. V tem času sem spoznal, da za tem imenom stoji več kot samo okolje za razvoj aplikacij.

Eclipse je skupnost - odprtokodna skupnost, v kateri se "kuhajo" raznolika orodja za izdelavo aplikacij. Deluje kot povezovalno ogrodje. Deluje na Windows, Linux, Mac OS X, Solaris, AIX, HP-UX in QNX sistemih.

Nastajati je začel novembra 2001 s povezovanjem velikih podjetij kot so Borland, IBM, Red Hat, SuSE, Rational Software. Trenutno je v konzorciju že več kot 100 podjetij, ki razvija v Eclipse skupnosti devet večjih in preko petdeset manjših odprtokodnih projektov. Če naštejem omenjenih devet:

The Eclipse Top-Level Project
razvojno okolje za orodja in aplikacije

The Eclipse Tools Project
skrbi za medsebojno povezovanje in združljivost orodij

The Eclipse Web Tools Platform Project
platforma za razvoj spletnih aplikacij

Test & Performace Tools Platform
platforma na kateri razvijalci razvijajo testna in performančna orodja

The Business Inteligence and Reporting Tools Project
orodja za poročanja iz aplikacij

The Eclipse Data Tools Platform Project
orodja za podatkovno orientirane tehnologije

Device Software Development Platform
orodja za razvoj aplikacij namenjenih za različne naprave

The Eclipse SOA Tools Platform Project
okolje in orodja za SOA (Service Oriented Architecture) aplikacije

The Eclipse Technology Project
inkubator za nove tehnologije

V bližnji prihodnosti (junij 2006) se nam obeta izid kar desetih Eclipse projektov pod skupnim imenom Callisto.

Pri delu uporabljam intenzivno samo prvega, to je Eclipse IDE z raznimi dodatki (plug-ins). Za razvoj Java frontend aplikacij uporabljam MyEclipse in Spindle, za backend in samostojne aplikacije v Java jeziku pa so nepogrešljivi XMLSpy, RMI compiler, Subversion, UML, Log4E, LogWatcher in pa zadnje čase tudi JProfiler in Maven. Urejevalnik izvorne kode za Java jezik ima odlično podporo za refaktoring, ki prihrani čas in živce pri razvoju programske opreme.

Dodatki za Eclipse se najdejo na Eclipse plugins in na Eclipse plugin central.