Kokous 2002-06-14

Kokous B436 klo 13-16 Paikalla Antti Merja Petri Tuomo Vilho Raatikka

• Iteraation palaute

Tavoitteiden saavuttaminen

Käyttöliittymäsuunnitelmaa ei ole, goaleja ei ole tehty. Käyttöliittymästä esitettiin ajatus continous filter tai autofill -design patternien käytöstä. Mielenkiintoinen kysymys oli mikä oikeastaan on RDF:stä suoritettava hakusana; subjekti, predikaatti vai kenties objekti (vai kaikki) ?

Oracleen saatiin laitettua Jenan tietokantataulut. Jena saatiin asennettua ja kokeiltua, että se toimii. Tomcat on myös asennettu ja todettu toimivaksi. Kuitenkaan minkään työkalun välille ei saatu yhteyttä.

Ontologiaa on mietitty. Esimerkkiontologiaa ei kuitenkaan saatu vielä RDF:ksi, sillä Protege kaatui kun sillä koetti tallentaa RDF:ää.

Lisäksi testattiin ja asennettiin jUnit ja Cactus-testausympäristöjä, sekä rakennettiin Ant-buildympäristöä.

Kaikenkaikkiaan vaikuttaisi, että edelleen iteraation aikana oli liikaa tekemistä. Työmäärän arvioimista varten täytyy ottaa käyttöön työkaluja, jotta jatkossa voidaan tehdä paremmin todellisuutta vastaavia arvioita.

• Kehityskeskustelu

Pariohjelmointi on ollut aluksi vaikeaa, kun asiat ovat uusia. Tiedonsiirto on ollut yksipuolista Antilta muille. Mutta parityöskentelystä on ollut selvästi etua uusien asioiden opettelussa. Vilho ehdotti, että ensi viikon tiistaina klo 14-16 pidettäisiin molempien ryhmien yhteinen esitys ontologiasta.

Todettiin, että jatkossa voisi tuoda CRC-kortit mukaan ainakin iteraation tehtävien suunnitteluun. CRC-korteille (A5-koko) pilkotaan iteraation asiakastarina yksittäisiksi tehtäviksi, joiden kestoa ryhmä arvioi ideaalisina parityöskentelytunteina. Tämän jälkeen arvioidaan myös kuinka hyvä arvio on riskiasteikolla 1..3 (tiedän tarkkaan.. ei mitään hajua).

Lisätään projektisuunnitelmaan uusi toteutunut riski: Linux ympäristö saattaa koska vain lakata toimimasta kesken työskentelyn. Kuinka varautua tähän riskiin? Tänään menetettiin 1,5h työaikaa (no 1h pidettiin enemmän kokousta tosin).

Linux on myös riski, sillä se hidastaa työntekoa. Linux on uusi asia, ja monessa kohtaa myös kovin kömpelö verrattuna Windowsiin (esim leikepöytä, joka ei välttämättä toimi sovelluksesta A sovellukseen B), mikä hidastaa työskentelyä kun joudutaan näpertämään merkityksettömien asioiden kanssa.

Työskentely TKT laitoksella on riski, sillä ATK-ylläpito saattaa koska tahansa poistaa työskentelyjärjestelmän toiminnasta vedoten tietoturva-aukkoihin. Tämä riski täytyy vain hyväksyä (kenties varata pelivaraa?).

Dokumennoinnin kehittäminen

Javadoc ja koodin kommentointi
Mihin koodin kommentointia tarvitaan? Eräs tarve on, että muutkin pystyvät ymmärtämään koodin toiminnan kuin koodin kirjoittaja. XP:ssä tähän tavoitteeseen pääsemiseen käytetään kahta muuta menetelmää kuin koodin kommentointi; collective code ownership ja yksikkötestit. Ongelmana kommentoinnissa on, että se aiheuttaa ylimääräistä työtä muutenkin kuormitettuun päivärutiiniin. Pelkästään suunnittelu, yksikkötestien tekeminen ja integrointi koodauksen lisäksi ovat hyvin aikaavieviä askeleita. Mikäli tähän joudutaan lisäämään runsaasti ylimääräistä dokumentaatiota, projektin nopeus tulee hidastumaan merkittävästi. Tarkoitus kuitenkin olisi saada jotain aikaiseksikin. Yksi XP:n periaate on Travel Light, jossa viitataan paimentolaisiin, joilla on mukanaan vain teltta ja yksinkertaisia ruuanvalmistusvälineitä. Paimentolaiset liikkuvat kameleiden perässä ja vaihtavat paikkaa usein, he eivät pysty käyttämään vähäisiä resursseja toimintansa ylös kirjoittamiseen, vaan kansantarinat välittyvät suullisena. Vastaavasti XP-projekti kulkee jatkuvasti paikkaansa muuttavien asiakasvaatimusten ja tekniikan perässä, jolloin raskaalla kuormalla ei pysytä muutosten perässä.

Collective Code Ownership tarkoittaa, että kaikki ryhmän jäsenet saavat tehdä muutoksia mihinkä tahansa CVS puun osaan. Vastaavasti vesiputousmallissa työ ositetaan yksittäisille henkilöille, jolloin toiset eivät saa mennä sorkkimaan muiden tekemiä ohjelmanpätkiä ja kaikki muutokset tulee mennä yhden henkilön kautta. Vesiputosmallin perinteisessä tavassa ongelmana on, ettei ole mitään takuuta siitä että muun henkilön tekemän muutoksen jälkeen ohjelma toimisi enää samalla lailla kuin se toimi ennen muutosta. XP:ssä ohjelman toiminnallisuus kuitenkin varmistetaan automaattisilla testeillä, jolloin refaktoroinnin jälkeen voidaan aina tietää toimiiko koodi samalla tavalla kuin se toimi ennen muutosta siitä menevätkö testit läpi vai ei.

Koodin yhteisomistus asettaa kuitenkin tiettyjä vaatimuksia sille minkälaista koodia kirjoitetaan. Jos Maijan mielestä {:tä edeltää välilyönti ja Matin mielestä ei, ongelmaksi syntyy minkälaista koodaustyyliä käytetään. Pahimmassa tapauksessa Matti käy illalla poistamassa välilyönnit illalla, ja Maija lisää ne takaisin aamulla. Koodin kirjoittamista varten täytyy siis sopia yhteinen Coding Standard, joka voi olla mikä tahansa mistä päästään yhteisymmärrykseen. Se on hyvä dokumentoida ja yhteneväinen tyyli ja nimeämiskäytännöt auttavat myös koodin luettavuudessa suuresti. Meidän tyylistandardiksi on ehdotettu Sun:n Java Coding Standard:ia ilman Javadoc:ia, mistä joku voisi pitää esitelmänkin.

Välttämättä kaikkea kommentointia ei tarvitse jättää tekemättä. Kuitenkin on täysin turhaa käyttää aikaa kommentoinnin käyttämiseen ryhmän sisäisenä kommunikointikeinona, kun työskentelemme yhteisessä tilassa ja voimme vaihtaa tietoa helpommin suullisesti kuin kirjoitetussa muodossa.

Mitä tulee ryhmän ulkoiseen kommunikointiin, niin automaattiset testit näyttelevät myös tärkeää osaa siinä mitä koodi oikeastaan on. Ne periaatteessa määrittelevät koodin ulkoisen käyttäytymisen. Tällöin koodin sisäistä rakennetta voidaan muuttaa tarvittaessa (liikkua kamelien perässä) refaktoroimalla sitä. Testien ansiosta voidaan edelleen olla varmoja sen ulkoisen toiminnan muuttumattomuudesta. Koska muutos ja refaktorointi on jatkuvaa, on äärimmäisen tärkeää XP-menetelmässä että muutoksen tekeminen on halpaa. Tällöin ylimääräinen kommentointi puukottaa menetelmää vakavasti. Lisäksi koodin rakenteen kuvaaminen on lähes mieletöntä, sillä se periaatteessa muuttuu viikoittain. Ja sen on tarkoituskin muuttua. Yksikkötestien avulla voidaan kuitenkin määritellä koodinpalasen skooppi, jonka jälkeen etsitään yksinkertaisin mahdollinen toteutus. Useimmissa tapauksissa ratkaisu ei toivonmukaan ole monimutkainen (muuten epäonnistutaan yksinkertaisuus-periaatteessa).

Jos kooditason kommentointi jätetään pois, sen sijaan edelleen kannatan systeemitason arkkitehtuurikuvausten tekemistä design patternien avulla. Pienten koodikikkareiden kuvaamisen sijasta myös myöhemmille koodin käyttäjille (ja meille itsellemme) on hyödyllisempää piirtää yleiskuva järjestelmästä ja sen suunnitteluperiaatteista. Systeemiarkkitehtuurin kuvaustavaksi ehdotettiin neljää työkalua; Poseidon+ArgoUML, xfig, dia ja pelkkä paperi/fläppitaulu. Työkalua ei kuitenkaan päätetty vieläkään.

Kaikki ylläolevat perustelut puoltavat sitä, että koodin tarpeettomasta kommentoinnista ja javadocista pidättäydytään.

Vilhon mielestä kommentteja ja javadoc:ia tarvitaan.

Projektisuunnitelma on nykyään ainoastaan WikiWikiWebissä?.

• Päätettiin jatkaa nykyistä iteraatiota seuraavalle viikolle, vaikka se on hyvin XP-menetelmän vastaista toimintaa. Seuraava viikko on kuitenkin Juhannuksen takia vajaa (2 työpäivää) ja työkalujen kokeilu, kälisuunnittelu ja ontologian tekeminen on edelleen pahasti kesken. Jatkossa toivonmukaan pystytään arvioimaan työmäärää tarkemmin.

• muuta

Päivemmällä päätettiin että keskiviikkoisin voitaisiin 10 sijasta tulla 9:ltä paikalle, jolloin kaikkina päivinä tullaan 9:ksi.