Miten muissa firmoissa tämä raja menee. Itse ainakin ylläpitotehtävissä tulee tehtyä määrittelyn, koodaus ja testaus (asiakkaan kanssa) itse. Tuntuu jotenkin typerältä puolin ja toisin tehdä kahden päivän juttua niin että erikseen määritellään, toteutetaan ja testataan enkä usko että laatu/hinta suhde tästä ainakaan paranee. Muutenkin meillä määrittelyt tehdään korkealla tasolla ja koodaamistyö ei ole pelkää koodaamista vaan suunnittelija/koodaaja tekee omat ratkaisunsa ja hänen pitää tuntea myös järjestelmä mitä hän koodaa. Pelkästä koodarista joka ei tunne järjestelmää ei ole hirveästi lisäarvoa. Asia ovat varmaankin toisin kun puhutaan kokonaan uuden järjestelmän rakentamisesta?
nörtti
raja määrittely/koodaus
6894
0Äänestä
Muut lukivat myös
Odottaa vastausta
Näihin keskusteluihin ei ole vielä vastattu. Ole ensimmäinen.
Vastaukset 6
Vanhimmat
Se itse koodaus on jotain 20% koko hommasta yleensä.
En tiedä onko teidän firma laatusertifikoitu. Jos on, niin silloin ainakin dokumentteja pitää tehdä kolme päivää yhden päivän työtä varten.
No, vuoden vaihteessa minä palaan vanhaan puljuun töihin; siellä ainoa dokumentti mikä pitää ohjelmistoprojektista tehdä on käyttäjän opas :))) Eli koodaukseen saa käyttää 95-99% ajasta.
Jos tulee auditti niin voi joutua vähän selittelemään. Tuo käyttöohjeen tekeminen kuulostaa järkevämmältä kuin meidän tekemä tekninen dokumentti/määrittely josta ei ota selvää kuin toinen suunnittelija/koodari.
Käyttöohje on se mitä tarvitaan aina. Siis käyttäjä.
Ne muut 20 dokumenttia on ohjelman ylläpitäjää varten. Osa niistä on kyllä ihan tarpeellisia, mutta kyllä ihan turhaakin työtä tuo sertifikaatti teettää...
Ei se auta muuta kuin väsätä niitä dokkareita. Onnea ja menestystä (ja jaksamista) työhön.
"Ne muut 20 dokumenttia on ohjelman ylläpitäjää varten. Osa niistä on kyllä ihan tarpeellisia, mutta kyllä ihan turhaakin työtä tuo sertifikaatti teettää... "
Suurin osa dokumentaatiosta on hyödytyntä, sillä ne ovat lähes poikkeuksetta huonosti kirjoitettuja. Koodari kun ei ole välttämättä kirjailija. Lisäksi dokumentaatio on lähes poikkeuksetta jäänyt jälkeen todellisesta toteutuksesta.
Dokumenttien kirjoittaminen on huomattavasti vaativampaa kuin koodin kirjoittaminen. Ehkä juuri siksi maailmassa on niin paljon NULL-dokumentaatiota.
Olen 110% samaa mieltä. Usein järjestetään katselmointeja, joissa koko tiimi lukee speksin/koodin läpi ja sitten kerrotaan löydetyt virheet. Tämän toiminnan tarkoituksena on saada aikaan hyvä ja täydellinen spesifikaation.
Tosielämässä voi jo suoraan sanoa, ettei henkilön X kirjoittama speksi ole hyvä. Monesti kielenä on englanti. No herra X ei osaa englantia paskan vertaakaan, jokaisessa lauseessa on vähintään 3 virhettä. Voit listata ne tuhannet virheet hänelle, mutta korjatussa versiossa on sama määrä uusia virheitä. Jopa kotimaisella kielellä jälki saattaa olla lukukelvotonta.
Vaikka tarkoituksena ei olekaan tuottaa kohottavaa proosaa, niin voisi sitä edes jotenkin pysyä aiheessa. Jos puhutaan palikasta A niin miksi pitää tekstissä vaeltaa jonnekin palikkaan B ja vielä syvemmälle?
Monesti kirjoittajalla ei ole edes käsitystä siitä miten oman tekeleen pitäisi toimia (tai miten se toimii). Silloin speksi otetaan suoraan itse koodista. Korvataan AND sanalla "ja" ja OR "tai":lla. Lopputulos on piiitkä lista täysin tyhjänpäivästä muuttujalistausta joka ei kerro kenellekään yhtään mitään.
Joukossa saattaakin olla täydellisesti englantia hallitseva guru. Ja hän tietää sen itsekin. Siksi speksi pitää kirjoittaa mahdollisimman hankalilla lauserakenteilla. Jos väliin saa ängettyä ranskankieilisiä termejä niin vielä parempi. Lukijan tuleekin tuntea itsensä mitättömäksi tämän suuren hengen jättiläisen varjossa. Itse koodi on samaa huttua. Elämää suuremmalle akateemikolle ei kelpaa yksinkertaiset ratkaisut. Jokaista koodauskielen featurea pitää käyttää vaikka väkisin, ja mahdollisimman monen loopin ja ehdon kautta. Se että koodia on hankala tai mahdoton kääntää tai käyttää jälkeenpäin ei haittaa, se olkoon mitättömyyksien ongelma.
No miten tämä liittyy niihin katselmointeihin sitten? No sillä tavalla että kun samaa skeidaa joutuu lukemaan ja kuuntelemaan tarpeeksi kauan, niin helpointa on sanoa vain "joo on se hyvä, pistä painoon". Näin pääsee nopeasti takaisin vääntämään sitä omaa speksiä, ja samalla toivoo ettei nyt vaan ikinä joutuisi edellisen speksaajan tekeleitten pariin...
Joskus näkee hyviä speksejä. Ne menevät vielä "managereiden" suodattimen läpi. Ylimääräiset kuvat, taulukot ja selityksen pitää poistaa. Ja lyhenteiden määrää lisättävä ;)
Varmaankin totuus löytyy siitä
että pitää löytää paras tuotto suhde
dokumentointiin tarvittavan ajan, kustannuksen
ja käytettävissä olevan ajan kanssa. Esim minusta raporteista ja kyselyistä ei tarvitse tehdä samanlaisia speksejä kuin kriittisistä ylläpitonäytöisä. Kuitenkin pohja ja vaatimukset ovat samat. Ei mitään järkeä.. minusta