ST-WORLD liitenumero
                     
Program development s. 18
                     
                     
                     
                     
                     
            Ohjelmointi ja ohjelmankehittely
                     
             Phil Trory - suom. J. Laurila
                     
                     
                     
                     
                     
                     
                     
Muutamia vinkkejä miten ohjelmointi sujuu paremmin:
                     
Heräät jonakin aamuna päässäsi uusi idea, jonka haluaisit ohjelmoida
                     
koska se mullistaisi koko ST-maailman. 
                     
Tällä ohjelmalla nouset kuuluisuuteen ja rahahuolesi vihdoinkin poistuvat,
                     
saat mainetta, onnea ja avio-ongelmat ratkeavat (jos se on ollut tästä
                     
kiinni).
                     
                     
                     
Ryntäät  panemaan keittimeen vettä, unohdat purut, sitten koneen kimppuun 
                     
ja virta päälle. Tuskin jaksat odottaa että se on käynnistynyt, kun jo 
                     
naputat koodia editorissa. 
                     
                     
                     
Yleensä noin 23:n aikoihin samana iltana huomaat, tuhansien ohjelmarivien
                     
jälkeen, että olet törmännyt pahaan virheeseen muuten hienossa 
                     
ajatuksessa. Korjaat, leikkaat, liimaat, ja koodaat uudelleen kiertääksesi 
                     
esteen. Aiemmin täydellisesti pyörineet modulit lakkaavat toimimasta, 
                     
ja alkavat kylvää pommeja kuin B52. Kun aamu sarastaa, raahaat 
                     
ylikuumenneen ST:si roskakoriin ja riutuneet luusi punkkaan saamaan 
                     
ansaitsemaansa lepoa.
                     
                     
                     
Miksi? Miten voi niin hieno idea päätyä sellaiseen kauheaan sotkuun?
                     
Miten ammattilaiset välttävät samanlaisen kohtalon?
                     
                     
                     
Vastaus kysymykseen on, että ammattilaiset törmäävät useinkin samaan
                     
lopputulokseen. Ainoa ero on homman mittasuhteet ja seuraukset. 
                     
(Muistelepa veroviraston ATK-sotkua!) Kun 20 ihmistä on työskennellyt 
                     
kaksi vuotta projektin kimpussa, heitä todellakin harmittaa huomata, ettei 
                     
se koskaan ollut edes lähellä onnistumista. He ponnistelevat valtavasti 
                     
etsiessään vikakohtaa ja heidän epätoivonsa on raskas kantaa.
                     
                     
                     
Itse Einsteinilla olisi vaikeuksia selvittää ohjelmien aikataulujen
                     
tekemiä aika-avaruushyppyjä. " Ajallaan valmistuvaksi " ilmoitettu 
                     
ohjelma "valmistuukin 18 kuukauden" kuluttua. Tämä tapahtuu kun 
                     
projektin johtaja kiertää kyselemässä jäseniltään miten homma sujuu. 
                     
"Hienosti", "tämä osa on melkein valmis, pomo", ja niin kaikki ovat 
                     
onnellisia kunnes jonakin harmaana aamuna jotakin todella toimivaa pitäisi 
                     
esittää. Silloin kannattaa olla kaukana kun p*ska osuu tuulettimeen. 
                     
Samanlainen mutka fysiikan laissa pätee kun ohjelmaa edistyy 90 %:sti 
                     
valmiiksi ja pysähtyy iäksi.  
                     
                     
                     
            Eikö Reiska vieläkään koodaa?
                     
                     
                     
Epäonnistumiseen on monta syytä, ja osalliset niitä tuskin koskaan 
                     
huomaavat. Yksi tärkeimmistä on usko, ettei mitään merkittävää tapahdu 
                     
ennenkuin joku todellakin ohjelmoi. "Eikö Reiska vieläkään koodaa?", 
                     
on vastuullisessa asemassa olevan henkilön tunnettu lääketieteellinen 
                     
oireyhtymä. Ainoa tunnettu hoitokeino on terävä potku sellaiseen 
                     
kehonosaan, joka aiheuttaa pitkällistä ja sietämätöntä kipua.
                     
Jos ammattilaisilla on tällaisia ongelmia, miten voisit sinä murtoosalla
                     
heidän resursseistaan onnistua pysymään vaikeuksista kaukana? Itse asiassa
                     
sinulla on etu, koska vain sinä itse olet huolestumassa. Voit tarkkailla
                     
mitä teet ja miten, tarvitsematta hyväksyttää aikeitasi muilla joilla on
                     
erilainen näkemys.
                     
                     
                     
Tutki aluksi tarkkaan aluetta jolle olet menossa. Olisi huvittavaa 
                     
julkaista kuvia "työpöydistä", joilla on pinoittain diskejä, lehtiä, 
                     
listauksia, muistilappuja, kyniä, kahvikuppeja, ja muuta roinaa. 
                     
Ympäristö vaikuttaa varmasti siihen kuinka paljon ja millaista koodia 
                     
saat aikaan.
                     
                     
                     
                Tilakysymys
                     
                     
                     
Tarvitset tilaa. IBM:llä annetaan ohjelmoijalle kolmen neliömetrin
                     
työpöytä, ja koska Big Blue on mukana bisneksessä tehdäkseen rahaa,
                     
se on varmasti mitoitettu oikein. Laitteistosi pitää pystyä pystyt-
                     
tämään mukavasti ja hyviin asentoihin, ja tarvitset paljon tasaista
                     
pintaa listauksille, kaavioille ja käsikirjoille.
                     
                     
                     
Jos ST:si on puolen metrin korkuisella kahvipöydällä telkkarin edessä,
                     
aiheutat vain ruumiillesi vakavia vahinkoja. Vaikka sinulla olisi 
                     
kunnollinen työpöytä, onko monitorisi silmän korkeudella? Onko tuoli 
                     
oikean korkuinen ja tukeeko se selkää?
                     
                     
                     
Jos monitorisi on liian lähellä, silmäsi rasittuvat ja voit saada liikaa 
                     
säteilyä. Sähkömagneettinen kenttä kuvaputken ympärillä houkuttelee 
                     
miljoonia pölyhiukkasia. Kun ne osuvat kuvaputkeen, ne kimpoavat siitä 
                     
erittäin suurella nopeudella, ja jos silmäsi on reitin varrella...
                     
                     
                     
Niskasikin voi rasittua huonosti asetetusta monitorista ja toistuvasta 
                     
rasituksesta. Jos käytät paljon hiirtä, varo nojaamasta vapaaseen käteesi 
                     
tai saat tenniskyynärpään.
                     
                     
                     
Kaikki toiminta joka vaatii tehokasta keskittymistä, olipa se lukemista 
                     
tai ohjelmoimista, saattaa sinut melkein transsinkaltaiseen tilaan jossa
                     
sulaudut kokonaan siihen mitä teet ja unohdat kaiken muun. Tätä voisi 
                     
kutsua sujumiseksi, ja kun saavutat sen, olet tuottavimmillasi; ideat 
                     
tulevat selkeinä ja nopeasti, ongelmat ratkeavat hetkessä. Jos sujuminen 
                     
keskeytetään, menee 15-20 minuuttia ennenkuin saat uudestaan saman huipun. 
                     
                     
                     
Ota siis puhelin seinästä, lukitse työhuoneen ovi, ja kerro, ettei sinua 
                     
saa häiritä muun kuin välittömän kuolemanvaaran vuoksi. Tämä ei tarkoita 
                     
että työskentelisit koko päivän, voit keskittyä tuolla tavoin korkeintaan 
                     
noin 20 minuuttia kerrallaan. Senjälkeen tarvitset 10 minuuttia antaaksesi 
                     
aivojesi levähtää ennenkuin saat ne uudelleen työhön.
                     
                     
                     
                Hajoittavat tekijät
                     
                     
                     
Taustamelu vaikuttaa tuottavuuteesi, varsinkin jos tapanasi on kuunnella 
                     
musiikkia ohjelmoidessasi. Aivot ovat kaksiosaiset, joista 
                     
vasemmanpuoleinen hoitaa logiikkaa vaativat asiat, matematiikan ja 
                     
hallinnan, ja oikea puoli kontrolloi luovuutta ja taiteellisia puoliasi. 
                     
Musiikin kuuntelu on oikean aivopuoliskon hommia, joka käy hyvin niin 
                     
kauan kuin ohjelmoit tavallisia rutiiniasioita. Kun tarvitset suurta 
                     
luovaa ponnistusta kohdatessasi ongelman, kytkeytyy aivosi uudella tavalla
                     
muistuttaen lihapullaa. 
                     
                     
                     
Hyvinhoidettu ammattimainen projekti on tavallisesti jaettu useisiin 
                     
lohkoihin, tyypillisesti esim. käyttäjäympäristön määrittely, 
                     
oppimishelppouden tutkimus, toiminnallinen määrittely, ohjelman kehittely,
                     
testaus ja niin edelleen. Huomaa että vain yksi koskee ohjelmointia, 
                     
muut huolehtivat tehtävän asettelusta ja ratkaisun suunnittelusta.
                     
                     
                     
Aika jonka käytät istumalla ja miettimällä asioita läpi ja 
                     
suunnittelemalla mitä pitää tehdä tulee moninkertaisesti voitetuksi kun 
                     
ryhdyt koodaamaan. Kaupallisessa maailmassa jaetaan projekti yleensä 
                     
kolmeen ajallisesti yhtä pitkään osaan: analyysi, ohjelmointi ja testaus. 
                     
Jos oikaiset analyysissa, kärsit myöhemmissä vaiheissa. Jos oikaiset 
                     
testauksessa, se kummittelee sinulle koko systeemin elinajan. Nämä 
                     
perusperiaatteet pätevät huolimatta käytitkö Assembleria vai Superbasea.
                     
                     
                     
                     
                     
             Viiden pisteen suunnitelma
                     
                     
                     
Klassisen projektikehittelyn vaiheet ovat hyvä opas siihen millaisia
                     
kysymyksiä asetat ennenkuin rupeat näppäilemaan.
                     
                     
                     
Mikä on tarkoitus tehdä?
                     
                     
                     
Ellet ole varovainen, huomaat lisäileväsi loputtomiin pikkuhienouksia
                     
valmiiseen ohjelmaan. Se käy rasittavaksi, koska se ei lopu koskaan,
                     
etkä pääse hyödyntämään tuotettasi. Päätä tavoite, johon päästyäsi
                     
pysähdyt ja taputat itseäsi selkään. Suhtaudu kaikkiin senjälkeisiin
                     
lisäyksiin ja muutoksiin uusina projekteina.
                     
                     
                     
Onko se mahdollista?
                     
                     
                     
Muutaman sadan ohjelmarivin jälkeen ei ole mukava huomata, ettei ST:n 
                     
muisti riitä tai tarvitset toisen levyaseman tai nokkela POKE johon 
                     
työsi perustuu tuottaakin rivin pommeja.
                     
                     
                     
Jos työhön liittyy tekniikkaa jota et ole aiemmin käyttänyt, outo 
                     
ohjelmointikieli tai kokeilematon sovellus, tee ensin pieni koeohjelma 
                     
nähdäksesi pyörivätkö rattaat kuten oletat niiden pyörivän. Voit tehdä 
                     
tyhjiä moduleita jotka vain ilmoittavat "tähän tulee menu " ja 
                     
näyttävät parametrilistan jonka ne saavat pääohjelmalta.
                     
                     
                     
Kauanko se kestää?
                     
                     
                     
Projektihallinnon vaikeimpia asioita on arvioida miten kauan menee, 
                     
ennenkuin tulee valmista. Parasta on tähdätä kohtuullisen lähellä olevaan
                     
maaliin. Mitä odotat saavasi valmiiksi ennen lounasta, tai kahdessa 
                     
tunnissa? Pysähdy joko tavoitettuasi maalin tai tavoiteajan kuluttua 
                     
umpeen, kumpi vain ensin tuleekin. Voit sitten suunnitella työsi seuraavan
                     
osan, ajatella uudelleen koko homman, tai päättää luopua koko roskasta, 
                     
riippuen siitä miten hyvin olet saavuttanut tavoitteesi. 
                     
                     
                     
Kenelle se on tarkoitettu?
                     
                     
                     
Jos teet ohjelmaa helpottaaksesi omaa elämääsi, olet valmistautuneempi
                     
hiomaan rumia kohtia ja etsimään virheitä. On parasta aloittaa tuolla
                     
asenteella joka tapauksessa; saada perusrakenne toimimaan ja lisätä
                     
ralliratti ja vauhtiviivat myöhemmin.
                     
                     
                     
Kun kirjoitat toiselle henkilölle, tai julkaistavaksi tarkoitettua
                     
ohjelmaa, tai vaikkapa sharewareksi tai myyntiin tarkoitettua työtä,
                     
sinun on pantava paljon huomiota tuotteen ulkonäköön ja tuntumaan.
                     
Käytä enemmän aikaa varsinkin testaukseen, ja sinun on huomioitava ja 
                     
suunniteltava ohjelman rakenne helposti hallittavaksi.
                     
                     
                     
Miten se testataan?
                     
                     
                     
Testaus tarkoittaa että ohjelmaa käytetään kaikin mahdollisin tavoin ja 
                     
kuljetaan ohjelman jokainen mahdollinen polku läpi. Mitä enemmän ihmisiä 
                     
sitä tulee käyttämään, sitä elintärkeämpää perusteellinen testaus on.
                     
Ensimmäinen asia jonka käyttäjä tekee on varmasti viimeinen mitä itsellesi
                     
tulisi mieleen tehdä. 
                     
                     
                     
Tarvitset melko varmasti myös testitiedostoa. Kuinka paljon ja kuka sen 
                     
tekee? Kuka ottaa selville, millaisia tulosten olisi oltava?
                     
Testaus vie aina enemmän aikaa kuin kukaan uskoisi, ja älä unohda, että 
                     
kun olet korjannut virheet, alkaa uusi testikierros. Et voi olettaa että 
                     
kaikki on nyt kunnossa.
                     
                     
                     
                     
                     
Jos systeeminkehittely 
                     
kiinnostaa, on aiheesta
                     
hyviä ja valitettavasti
                     
kalliita kirjoja, esim:   
                     
                     
                     
                The Brain Book                   
                     
                ISBN 0 7100 0706                   
                     
                tekijä: Peter Russel            
                     
                kustantaja: Routledge , Keegan Paul
                     
                     
                     
                     
                     
                Peopleware                      
                     
                ISBN 0 93263305 6               
                     
                tekijät:                        
                     
                Tom De Marco                    
                     
                Timothy Lister                  
                     
                kustantaja: Dorset House Publishing
                     
                     
                     
                     
                     

Takaisin

(C) Marko, Suomen Atari-sivut / ArkiSTo 2003