Millainen on ohjelmoijan työviikko? Asia kiinnostaa akuutisti tällä hetkellä sillä pitäisi kirjoittaa aiheesta raportti enkä ole tehnyt tuota ohjelmoijan työtä päivääkään...eli jos hieman apua saisi täältä.
Ohjelmoijan työviikko
Nimetön
3806
0Äänestä
Muut lukivat myös
Odottaa vastausta
Näihin keskusteluihin ei ole vielä vastattu. Ole ensimmäinen.
Vastaukset 3
Vanhimmat
Maanantai: aamulla palaveri, jossa hoidetaan ohjelmointitiimin työnjako ja tarvittava ohjeistus. Loppupäivä mietitään mistä aloittaisi. Siinä sivussa voi pistää alulle jonkin oman sivuprojektin (matopeli tms.) ja chattailla netissä kollegojen kanssa (=ideointivaihe).
Tiistai: Surffailua netissä kiireisen näköisenä. Työtermein tätä kutsutaan tiedonhauksi. Hankittua tietoa, mikäli sellaista pornosivujen ja chattipalstojen selaamisen ja MP3:sten latailun ohessa löytyy, voi soveltaa (eli "testata") matopelissä.
Keskiviikko: Ollaan tekevinään töitä ja yritetään näyttää mahdollisimman stressaantuneelta. Kaikkiin vähänkään epämiellyttäviin nakkeihin vastataan "en mä nyt ehdi kun on kiire tämän tärkeän xyz-projektin kanssa". Näön vuoksi voi matopelistä kopioida muutaman hyödylliseltä näyttävän funktion varsinaiseen projektiin.
Torstai: Perjantaipalaveri häämöttää. On siis keksittävä joukko hyviä tekosyitä ja selityksiä kun ei viikon aikana saanut aikaiseksi ainuttakaan järkevää koodiriviä. Mitään uutta ei tässä vaiheessa kannata aloittaa, sillä viikkohan on jo melkein ohi. Matopeli sen sijaan on ehdottomasti saatava valmiiksi, sillä viikonloppuna ei sellaiseen turhuuteen ole dokaamisen ohella aikaa.
Perjantai: Yritetään näyttää mahdollisimman väsyneeltä, kiireiseltä, ärtyneeltä, stressaantuneelta ja kaikkensa antaneilta ja siinä sivussa tehdä viimeisiä viilauksia matopeliin. Iltapäiväpalaverissa syytellään kaikkea kuviteltavissa olevaa (työtovereiden hidastelu ja heidän buginen koodinsa, koneongelmia, päänsärkyä, mitä hyvänsä) siitä ettet voinut tehdä koodiasi valmiiksi. Tässä on syytä olla vakuuttava, sillä ethän halua itse osoittautua syylliseksi omaan saamattomuuteesi ja projektin valmistumisen lykkääntymiseen. Palaverin jälkeen voikin sitten aloittaa valmistautumisen viikonlopun viettoon, soitella kavereille ja lyödä lukkoon viikonlopun ohjelma.
Voihan se noin toimia jonkin aikaa. Ei tuolla menolla kyllä matopelejä kummempaa saakaan aikaiseksi. Taitaa olla proosaa pikemminkin kuin todellinen päiväkirja tai sitten KoodiGurun kannattaisi tosiaan ryhtyä kirjailijaksi :)
Tosiasiassa ohjelmointityö on pitkäjänteistä hommaa. Ohjelmistoprojekti kestää tyypillisesti kuukaisia, joissakin tapauksissa jopa vuosia jos kysymyksessä on laaja järjestelmä. Viikko on siten ehkä liiankin pieni tarkastelujakso, siinä ei paljon ehdi tekemään. Design, toteutus, integrointi ja bugikorjausvaiheet eroavat kuitenkin toisistaan, vaikkakin vaiheita on joskus vaikea erottaa toisistaan. Koskaan design ei ole täydellinen ja siihen joudutaan toteutusvaiheessa palaamaan, samaten kuin integroinnissa joudutaan toteuttamaan ehkä jotain uudelleen kun havaitaan että toteutus ei sellaisenaan kelpaa. Lisäksi totetusympäristö mihin softaa tekee vaikuttaa suuresti millaista työ käytännössä on. Esimerkiksi työasemalle (windows/linux jne) tehtävä softa on huomattavasti helpommin testattavissa kuin sulautetut ohjelmistot, esim matkapuhelinsofta jossa rajalliset resurssit (muisti, prosessointikapasiteetti, virrankulutus) on otettava huomioon koodia tehtäessä ja etenkin jo design-vaiheessa. Puhumattakaan debuggauksesta joka saattaa vaatia softan lataamisen puhelimeen, puhelimen käynnistyksen ja logien ulos ottamisen esim. sarjaväylän kautta, jotta näkee mitä softassa tapahtuu.
Mutta itse kysymykseen työviikosta (tämä tietysti on värittynyt oman kokemuspohjani mukaisesti). Tälle viikolle on projektisuunnitelmassa ominaisuuden X ja Y toteutus. Päivä-pari päivää menee hahmotellessa toteutusideoita (karkealla tasolla design speksit tietysti määrittävät jotain). Asiathan voi aineettomassa softamaailmassa tehdä rajattomalla määrällä vaihtoehtoja. Ensimmäisen hahmotelman testauksessa huomaan, että tuonhan olisi voinut toisella tavalla paremmin. Lisäksi se ei koskaan toimi niin kuin haluaa ensimmäisellä kerralla. AINA tulee tehtyä virheitä. Paranneltu versio taas sisältää täysin käsittämättää ajonaikaista toimintaa - ei voi toimia noin, kääntäjässä varmaan vikaa! Ja sitten kaveri kurkkii olan yli ja kysyy miksi tuossa on tuommoinen ehtolause - tätä kutsutaan "hyvin epäviralliseksi koodikatselmoinniksi" (virallisessa käydään porukalla softamokkulan koodit läpi semanttisten/loogisten virheiden ja epäloogisuuksien sekä optimointien ja muiden parannusehdotuksien löytämiksi). Hupsis, viikko meni jo! Ominaisuus Y siirtyy seuraavaan viikkoon, project planit uusiksi, ilmoitus managerille (ettei testaajat turhaan ihmettele miksei Y toimi ja raportoi virhettä). Tässä kohtaa voikin mainita, että ohjelmoijan työ ei ole omassa nurkassa näpertelyä, mitä laajempi järjestelmä sitä tärkeämpää on kommunikointi akselilla koodarit-managerit-testaajat-integroijat-lokalisoijat ( muut isoissa projekteissa olevat henkilöt).
Ohjelmointityö on käytännössä monitasoista ongelmanratkontaa ja tietyssä mielessä jopa taidetta (jokaisella taiteilijalla on oma käsialansa ja tyylinsä). Bugien korjaus menee jo pitsinnypläyksen puolelle ja voi monesti tuntua turhauttavaltakin. Toisaalta onnistumiset työntävät turhaumat syrjään (jolloin syvästi katuu hajotettua näppäimistöä).
Noh työviikot ei aina ihan samanlaisia. Meillä ainakin ohjelmointityöt aika isoja ja projektiluenteisia. Yhtä projektia tehdään ehkä pari kuukautta. Projekti alkaa siitä, että myyjä saanut myytyä asiakkaalle jonkun kilikkeen, softan, portaalin, laajennuksen, päivityksen tms.
Sitten hommaa pääsee määrittelemään ja suunnittelemaan ja hahmottelemaan. Päättää käytettävät teknologiat ja kielet. Yleensä sitä alkaa koodaamaan sillä mitä parhaiten osaa.
Määrittelyt ehdotellaan asiakkaalle ja se hyväksyy ne muutoksin. Sitten aletaan koodaamaan yksin / tiimissä riippuen homman koosta. Koodatessa ollaan samalla välillä yhteydessä asiakkaaseen joko suoraan tai myyjän tms. välityksellä.
Aika paljon saa/joutuu käyttämään koodia, mitä on jo joskus aikasemmin firmassa tehty. Välillä pitää kysellä 10 vuotta firmassa olevilta guruilta, että miten homma ois paras tehdä/mistä löytyis esimerkkiä.
Sitten testaillaan ja saatetaan valmis softa loppukäyttäjälle tai ainakin jollain tapaa asiakkaalle. Sitten sitä käy ehkä kouluttamassa asiakasta ja sen jälkeen tukee vielä puhelimitse ja sitten rupee korjailemaan bugeja. Ja samalla tietty toinen tai kolmaskin ihan uusi projekti jo käynnistynyt ja dead linet pukkaa päälle =).
Mut tässä ny oli vaa pintapuolinen raapasu. Ei tämmösiä mihkään kannata laittaa.