Täna ma kirjutan wikist

Uue meedia võimalustega seoses tuleb mainida, et ma suhtun kõikvõimalikesse vaba sisu esinemisvormidesse väga hästi, aga ise ei ole viitsinud väga ajaga kaasas käia. Kui välja arvata tööalased vajadused. Seepärast räägiks wikist seoses tööga ja võrdleks wikit traditsioonilisemate suhtlus- ja dokumenteerimisvahenditega, mida tarkvaraarenduses on kasutatud.








(allikas: 3nexus.com)



Tarkvaraarenduses käib töö lihtsustatult nii :

• Kliendil (välisel või firma mingil üksusel) on mingi soov. Ta oskab seda kuidagi kirjeldada, aga suht lünklikult ja muidugi üldse mitte tehniliselt.
• Firmas on analüütik või siis keegi projektijuhi-analüütiku sulam, kes kliendi ära kuulab ja kirja paneb, mida uuelt tarkvaralt või mingitelt täiendustelt-muudatustelt oodatakse.
• Tarkvaral, olgu ta juba olemas või mitte, on üldiselt nõuded, arhitektuur, komponentide disain ja kood. Ja ilmselt ka testid, kui tegu on hea firmaga. Mingi osa loetletust on kuskil kirjas. Kas kood on ühtlasi ka dokumentatsioon, selle üle vaieldakse. Aga kindlasti ei ole kood ainus kirjasolev asi ja seega lähevad ootused ja tegelikkus kindlasti kuskil sünkroonist välja.
• Tarkvara on vigane (olevikus või tulevikus) ja vead on kuskil kirjas. Paremates firmades on selleks veahoidlad, viletsamates firmades on vead kuskil e-mailides vms. Hea on, kui vead, veaparandused, dokumentatsioon ja tegelikkus kõik kooskõlas on. Kood on elab igas enesest lugupidavas projektis muidugi versioonikontrolli all, aga see ei taga kuskilt otsast koodi ja kõige muu kooskõlasolemist.
• Arendaja on tihti olukorra ees, kus ta hakkab millegi põhjal koodi kirjutama, aga nõuded muutuvad koguaeg ja tulemus peab muidugi olema kooskõlas viimaste nõuetega. Või siis läheb nii, et implementatsioonis on veel kuidagi kolmandatmoodi, sest nõuetele vastavalt ei olnud probleemi võimalik tehniliselt lahendada.
  

Mõelge, kui palju kommunikatsiooni tarkvaraarendus endas hõlmab ja kui palju on sünkroonist väljaminemise võimalusi. Võib isegi öelda, et tarkvara saab loodud muutuvate sisendandmete kiuste.

Wiki kujutab endast igavesti mõnusat vahendit tarkvaraarenduses liikuva info hoidmiseks, muutmiseks ja haldamiseks, kusjuures ärksamaid wikisid annab siduda veahoidlate, versioonikontrolli, RSSi ja muu sarnasega, tänu millele tekib wiki ümber elav protsess.
Jama on ainult siis, kui kasutatakse formaate, mis ei allu teksti diffimisele (kes ei tea, siis diffimine on kahe tekstifaili võrdlemine ja võrdlustulemuse väljastamine tekstikujul, kokkulepitud tähistustega). Näiteks ei allu diffimisele .doc-formaadis nõuded jne.
Kirjeldan nüüd eeltoodud tarkvaraarenduse protsessi osi ja osalejaid wikipõhise lähenemise kontekstis ja mainin iga punkti juures, kuidas varem tehti ja mis on piirangud.

• Head wikid oskavad majandada kasutajaõigustega. Kui meil on toimiv wiki, siis saab klient õiguse teatud wiki lehti külastada ja ka kommenteerida, mida vaja. Lisaks saab wiki kaudu ligi tarkvara väljalasetele (pakkidele, binaaridele vms). Ilma wikita oleks klient arendusfirmast või -osakonnast isoleeritud ja tarkvara versioonid jõuaks temani plaadil, mälupulgal või näiteks mingi FTP saidi kaudu, kus ei oleks jällegi võimalik näiteks viidata uues versioonis parandatud vigadele. Selle punktiga seoses mingeid väga suuri probleeme tekkida ei tohiks.
  
• Analüütik paneb muidugi kõik vajaliku wikisse kirja. Dokumente genereerib vajadusel ka wiki põhjal. Ilma wikita oleks kuskil kataloogid nõuete failidega, ilmselt eri versioonid lihtsalt eri failides, või siis kasutaks firma mõnd dokumendihaldussüsteemi. Siin on muidugi wiki sobiv ainult teatud firmadesse, teatud olukordadesse, sest wiki võib väga lihtsalt käest ära minna. Selleks, et wiki oleks hea analüüsidokude asukoht, peab keegi isiklikult selle eest hea seisma ja firmas peaks valitsema ka õhkkond, mis soosib tekstiformaati ja sellest vajadusel eri väljundite genereerimist.
• Tarkvara dokumentatsiooni hoidmine wikis on umbes samalaadi ülesanne nagu analüüsipoole hoidmine. Vaja on süsteemi, huvilisi ja arusaamist, et wiki on allikas ja kõik muu genereeritakse. Probleeme tekitavad kindlasti väliste vahenditega tekitatud joonised, see probleem on tegelikult ka analüüsidokude juures. Ja vanamoodne lähenemine oleks jällegi sama: failid kuskil kettal, näiteks .doc formaadis, samuti erinevate CASE-vahendite väljundvormaatides failid.
  
• Tark wiki viitab koodi- ja veahoidlale. Vanamoodsate vahenditega võib olla päris raske järge pidada, kus mingi nõue implemenditud või viga parandatud on. Eriti ilus on, kui wiki oskab kuvada mingit alamhulka veahoidlas püstiolevatest probleemidest ning väljavõtet versioonihalduse viimastest commit-idest. Raskused võivad ilmselt tekkida vigade-versioonide ja wikivaheliste ristviitamistega, e. kuidas ma viitan koodist mingile wikis kirjasolevale nõudele jms. Jällegi: vaja on huvilisi, süsteemi ja õiget wikit.
• Muutuvatest nõuetest võiks arendaja saada infot RSSi abil. Eriti on see hea, kui töötajad ei asu füüsiliselt samas hoones. Kui nõuet wikis muudetakse, võiks arendaja saada teada, millega seoses muudatus tehti ja lingi, kus see kirjeldatud. Vanamoodsam alternatiiv oleks, et projektijuht tuleb tuppa ja teatab, et tegelikult tahetakse hoopis naa, mitte nii. Kuna nõuete muutumine on tüütu nii või teisiti, siis wiki peale ülesehitatud protsessis ei satu projektijuht tuppa vähemalt kõige viletsamal hetkel - näiteks kui arendaja on just suutnud keskenduda koodile.