n gif bytes odateam d o o mala nedelja gosposvetska si mala nedelja maribor e mail info odateam com url http www odateam com povzetek v podjetju odateam se ze celo desetletje uspesno ukvarjamo s projekti ki temeljijo na objektni tehnologiji okljub temu objektna ts pricujocim prispevekom nimamo namena nacenjati nove zgodbe o internetu omrezju vseh omrezjih hiperomrezju ali kakor je dandanes mnogokrat povelican njegov pomen avtorji bomo le skusali predstaviti kako je mogoce na sorazmerno lahek in poceni nacin izkoristiti standarde in orodja ki jih prinasa njegova vse vecja razsirjenost v podporo procesom razvoja programske opreme osredotocili se bomo na t i objektne tehnologije in metode ki jih uporabljamo v podjetju odateam govora bo o zasnovi izdelavi in upravljanju intraneta kot povezovalnega orodja pri uporabi drugih razvojnih orodij kot orodja za izdelavo programskih specifikacij razvojne dokumentacije itd ehnologija sama se ne zagotavlja uspeha zelo pomembni so odnosi ki vladajo v razvojni skupini ideja ekstremnega programiranja temelji na udarni skupini ki goji skupinsko zavest in razmisljanje ter si sama postavvljai pravila za delo v skupini je pomembna dobra komunikacija tako med stranko in razvijalci kot med razvijalci samimi prav tako pomembno je tudi testiranje ki nam omogoca da preverimo ali je skupina uspesna ce zelimo delati udarno je kljucnega pomena tudi enostavnost razvijamo natancno to kar stranke potrebujejo in ne funkcionalnosti ki bo morda potrebona v prihodnosti zgoraj nastete cilje dosezemo s t i lahkim procesom razvoja ki se izogiba nepotrebni dokumentaciji in drugim balastom ter uvaja metode dela kot so skupinsko lastnistvo izvorne kode programiranje v parih in uporaba vzorcev nase izkusnje v zadnjem letu so zelo pozitivne zvisala se je kakovosti produktov in zadovoljstvo razvojne skupine uvod v nasem podjetju uporabljamo objektno tehnologijo ze od samega zacetka in prav ta odlocitev je bila kljuc do uspeha v zadnjih letih smo naleteli na nekatere pojave ki so nam dali vedeti da je veliko odvisno od razvojnega procesa in odnosov v skupini zato smo se natancneje lotili analize razvojnega procesa v nadaljevanju zelimo predstaviti nekatere simptome ki so se pojavljali v razvojnem procesu in na kaksen nacin smo se jih lotili ugotovili smo da obstaja skupina strokovnjakov ki se prav tako ukvarja z razvojnim procesom imenmovanim ekstremno programiranje extreme programming ki je zelo skupinsko naravnan individualni nacin razvoja v preteklosti smo izdajali nove verzije nasih produktov pribljizno enkrat letno v letnem intervalu smo razvili novo funkcionalnost ali dopolnili obstojeco pred izdajo smo produkt testirali in ga nato strankam dali v uporabo odziv strank je bil v zacetku slab ker so stevilne spremembe ki so nastale v letu dni bile prezahtevne da bi jih obvladali v nekaj dneh izkazalo se je tudi da kakovost produkta kljub natancnemu testu ni bila zadovoljiva v prvem mesecu po izdaji je zmeraj sledilo veliko popravkov tako tehnicne kot strokovne narave stanje se je po zacetni slabosti izboljsalo in kakovost produkta je dosegla zeleno raven drugi problem se je pojavljal pri razdelitvi dela razvoj je bil usmerjen izrazito komponentno komponente so bile tudi baza za lastnistvo izvorne kode ena oseba je torej imela lastnistvo nad eno programsko komponento v dokaj nerednih intervalih smo programske komponente zdruzevali v celoto v vmesnem casu razvijalci niso imeli dostopa do dela ostalih razvijalcev resnicna integracija s testom pa je potekala le pred izdajo produkta ko so razvijalci ki so nujno potrebovali spremembe v tuji kodi in lastnik kode ni imel casa za spremembe se je vecinoma zgodilo da so razvijalci kodo kljub temu spremenili in nato spremembo poslali po elektronski posti lastniku lastnik je kodo dodal in ob naslednji integraciji je bila sprememba vidna vsem razvijalcem v redkih primerih ko je slo za kompleksne algoritme je bil ta nacin dober ker je bilo nujno da oseba ki se na podrocje spozna pregleda spremembo vecina sprememb pa je bila enostavne narave in zapleten postopek je bil cisto nepotreben dogajalo se je tudi da se je programska koda enostavno izgubila nekje na poti do lastnika komponente ko smo sistem integrirali je to bil dolgotrajen proces ker so bile posamezne komponente in deli sistema neprilagojeni psiholosko je bil taksen nacin dela slab ker ni vzpodbujal skupinskega dela in je temeljil samo na individualnih zmogljivostih programerja redka integracija produkta je vlivala strah ker nihce ni natancno vedel kaksna bo posledica zamenjave starega produkta z novim zamenjava kadrov je lahko vplivala na delo celotne skupine ker v danem trenutku ni bilo vec odgovornega za dolocene komponente ekstremno programiranje ekstremno programiranje je proces razvoja objektnih aplikacij katerega cilj je s cim bolj enostavnimi sredstvi in cim hitreje implementirati kvalitetno programsko opremo izogiba se pretirani formalnosti in dokumentaciji posveca se komunikaciji med osebami sodelujocimi v projektu tri glavne ideje so enostavnost komunikacija in testiranje ideja oblikovanja intranetaenostavnost prvo osnovno nacelo ekstremenega programiranja je da vsako funkcijo implementiramo na najbolj enostavnosten simplicity nacin ne gradimo sistema za funkcije ki jih morda predvidevamo za prihodnost ko sistem sirimo in kodo dodajamo ga tudi predelamo refactoring tako da se izognemo redundanci in sistem obdrzimo pregleden naceli enostavnosti in predelave nam omogocita da je sistem dobro razdeljen in primeren za siritev to nacelo je v nasprotju s starim racunalniskim pravilom da je potrebno funkcije implementirati na cim bolj splosen nacin pri objektnih sistemih to pravilo ne velja vec izkaze se da je najbolj fleksibilen sistem ki je sestavljen iz enostavnih in dobro porazdelelejenih objektov oz komponent prednost enostavnega razvoja je tudi v tem da prej dobimo rezultate ki jih lahko preizkusimo v realnosti in lahko na napacno obnasanje veliko lazje reagiramo kot pa ce zelimo ze v prvi iteraciji zajeti vse tudi potencialne zelje uporabnikov in sele ob koncu ugotovimo da uporabnik potrebuje nekaj drugega kent beck do the simplest thing that could possibly work komunikacija osredotocili se bomo na komunikacijo med clani razvojne skupine zavedamo se velikega pomena komunikacije med strankami in razvijalci v fazi definiranja zahtev a bi zzaradi kompleksnosti bi o tej temi lahko napisali svoj clanek vsekakor pa je poglavitno da so stranke prisotne tudi pri nacrtovanju sistema in so del razvojne skupine tudi komunikacija med razvojno skupino in upravo je pomembna tudi to podrocje presega meje tega prispevka predpostavimo torej da ze vemo kaj stranka zeli in smo upravo prepricali da bomo projekt speljali zahteve opisemo zs primeri uporabe use case crc kartice sistem razdelimo v podsisteme in dolocimo prioritete razvoja podsisteme razvijamo v iteracijah ki trajajo nekaj tednov do maksimalno eden mesec da lahko sistem razdelimo moramo narediti nacrt sistema zberemo skupino razvijalcev in strokovnjakov podrocja in naredimo t i sesejo sz crc kartami crc card session namen taksne seje je identificirati objekte in sodelovanje med njimi vsak udelezenec dobi doloceno stevilo kartic ki identificirajo dolocen objekt oz razred na levi del kartice napisemo odgovornosti objektov tega razreda odgovornosti so lahko podatkovne narave ali pa funkcionalne narave na desni del kartice napisemo objekte s katerimi objekt sodeluje najprej izberemo kandidate za objekte sistema nato poizkusamo igrati scenarij nekega primera uporabe tako da se oseba ki ima v roki kartico poistoveti z objektom na kartici vse skupaj poteka kot simulacija sistema taksne seje so zelo interaktivne in zahtevajo veliko soedelovanja med samo sejo lahko ugotovimo da potrebujemo nove objekte ali pa lahko tudi stare zavrzemo rezultat seje je dokaj natancen nacrt sistema ker pri seji sodeluje vec ljudi tudi taksnih ki sistema ne bodo programirali obstaja skupina ki problem in resitev pozna sistem poizkusamo implementirati na taksen nacin da bo vsak sodelujoci pri nacrtu takoj spoznal resitve za katere smo se odlocili pri nacrtu primer class responsibility collaborator kartice programiranje v parih sistem implementirajo programerji v parih to pomeni da sedita dva programerja pred enim racunalnikom na prvi pogled pomeni to da razvijamo dvakrat pocasneje v praksi pa se izkaze da dva programerja skupaj programirata hitreje in da so rezultati veliko bolj kakovostni prvi programer ima vlogi pisca in ima pri sebi tipkovnico ima lokalni pogled in ve tocno kaj dela v dolocenem trenutku drugi programer ki samo gleda ima zato ker ni obremenjen s pisanjem kode globalni pregled nad kodo ki jo piseta novinec se lahko veliko nauciijo ce je v paru s strokovnjakom na drugi strani pa nlovincec lahko pa zaradi neobremenjenosti najde resitve ki jih strokovnjak ne vidi ce razvoj zaradi problemov zastane se vrnemo v fazo nacrtovanja in spet naredimo sejo s crc karticami skupinsko nacrtovanje z crc kartami in programiranje v parih skupinsko lastnistvo izvorne kode programerji imajo pravico spremeniti karkoli v s sistemu karce je sprememba seveda smiselnoa za resitev problema spremembe moramo dovoliti ker pogosto resitev problema zahteva predelavo refactoring obstojecih razredov zelimo namrec da je nas sistem cim bolj enostaven in samo dograjevanje brez predelave ni mogoce upraviceno se lahko vprasamo kaj se zgodi ce sprememba v razredu ki ga je napisal nekdo drugi povzroci da razred ne deluje vec zato je potrebnomoramo zelo natancno definiratie testne primere za vse razrede in programske komponente sprememboe toreaj lahko takoj preverimo s testom pogosta integracija programerski pari svoje rezultate dnevno izdajo nato se vse spremembe integrirajo tako da imajo vsi najnovejse verzije programske kode potrebno je izvesti tudi vse teste ker ne zelimo integrirati nedelujocega sistema izvorna koda komunicira nacrt sistema ko sistem implementiramo crc kartice zavrzemo in s tem izgubimo edini dokument ki opisuje nacrt sistema to lahko naredimo zato ker izvorno kodo pisemo tako da nam direktno pove kaj sistem dela izvorna koda je pisana na tako visokem nivoju da je ne sluzi samo zato da pove racunalniku kako naj izvaja program ampak nam sluzi tudi za komunikacijo resitve ce zelimo to doseci moramo v skupini imeti natancno dolocena pravila za pisanje programske kode tako da vsi clani razumejo vsak delcek izvorne kode najlazje pravila opisemo v obliki vzorcev programska jezika kot sta java in smalltalk nam celo omogocata da vecino metod sploh ne komentiramo komentarje napisemo le za razrede oz programske komponente kjer opisemo kaj komponenta dela prednost je v tem da ni potrebno vzdrzevati paralelne dokumentacije nacrta sistema ki vecinoma ni usklajena z implementacijo primer nepotrebnega komentarja v javi public void run tell my station to process me this station process this stavek tell my station to process me ima natanko enak pomen kot programska koda sama primer v smalltalku kjer lahko programsko kodo preoblikujem tako da komentar ni potreben self flags bitand r iftrue am i visible napisemo novo metodo isvisible self flags bitand r in programsko kodo preoblikujemo v self isvisible iftrue programska koda dobi torej nov smisel ker postane medij za komunikacijo programske resitve v primerih ko gre za zapletene algoritme in delovanje razredov in komponent ni ocitno je seveda potrebno napisati natancne opise o delovanju le teh ti opisi naj bodo integrirani v razvojnem okolju in naj ne bodo loceno shranjeni pogosta integracija programerski pari izdajo svoje rezultate dnevno izdajo nato vse spremembe integriramo tako da imajo vsi clani skupine najnovejse verzije programske kode izvedemo tudi vse teste ker ne zelimo integrirati nedelujocega sistema dnevna integracija je izredno koristna ker je sistem vedno v konzsistentnem stanju in se lahko napake lahko zelo hitro odkrijejo testiranje razvojnega procesa ki tako mocno temelji na sodelovanju si brez natancnega testiranja ni mogoce predstavljati tudi neprestano integriranje nas sili v avtomatsko testiranje ker si skupina ne more privosciti integracije nedelujocega sistema zato je ob integraciji sistema potreben zagon vseh testov na drugi strani pa neprestana integracija omogoci da bodo programsko kodo zelo hitro zacelia uporabljati drugi uporabniki kar dodatno vpliva na kakovost teste locimo na teste enot unit test in teste funkcionalnosti functional test testi enot testirajo posamezne razrede oz komponente za vsako komponento mora obstajati testna komponenta pogosto tudi napisemo teste preden implementiramo samo komponento druge vrste testi so testi funkcionalnosti ki testirajo primere uporabe use case testi funkcionalnosti nam povejo ali sistem dela tako kot je stranka narocila testi enot pa nam povejo ali nasi razredi in komponente delujejo tako kot smo jih nacrtovali komponente ki ne prestane testa enote ni mogoce integrirati v sistem pomembno je da odstotek uspelih testov funkcionalnosti pocasi konvergira proti sto odstotkov v nasprotnem primeru je to pokazatelj da je sz projektom nekaj narobe zakljucek v nasem podjetju smo se ekstremnega programiranja lotili na vseh podrocjih menimo namrec da uvajanje samo nekaterih od zgoraj navedenih nacinov dela ne prinese zelenih rezultatov zelo pomembno je tudi da je proces odprt za spremembe razvojnao skupina se mora drzati dogovorjenihpostavljenih pravil to so pravila ki ne peljejo v enoumje saj ji jih je skupina sama postavila da bi uspesno delala optimalni nobeden razvojnii proces ne obstajas ni idealen in razmere se lahko spreminjajo zato mora skupina ce obstaja razlog nacin dela spremeniti v zadnjem letu smo opazili da se je kvaliteta izdanih produktov povecala clani skupine so bolj zadovoljni in zlasti mlajsi programerji se veliko hitreje vvklaplajo v skupino samozavest pri resitvah je pri programiranju v parih veliko vecja preglednost in porazdelitev programske kode je veliko vecja in programi so veliko bolj citljivi stranke dobijo gotove produkte in izboljsave v krajsih intervalih v manjsem obsegu in brez dolgotrajnega izdajanja novih verzij reference beck kent guide to better smalltalk cambridge university press beck kent smalltalk best practice patterns prentice hall jan steinman and barbara yates managing project documents the smalltalk report letnik stevilka junij gabriel richard p patterns of software oxford university press wilkinson nancy m using crc cards sigs books wirfs brock rebecca et al designing object oriented software prentice hall brown william j et al anti patterns john wiley sons roberts don et al why every smalltalker should use the refactoring browser the smalltalk report letnik stevilka september c team chrysler corp case study chrysler goes to extremes distributed computing oktober http www armaties com extreme htm extreme programming roadmap http www c com cgi wiki extremeprogramming extreme programming discussion vase mnenje o prispevku splosno odlicen vreden branja ni vreden branja dolzina predolg ravno prav prekratek strokovnost prevec strokoven ravno prav prevec splosen opombe vase ime priimek e posta podjetje