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
|