20 månader har jag jobbat med mjukvaruutveckling i ett och samma projekt. Utöver det har uppskattningsvis 50 manmånader lagts på förstudier, säkerhetsanalyser, arkitektur, design, planering, testspecifikation, kravnedbrytning, omdesign, omplanering, interfacespec, konfigurationshantering... för den mjukvara jag ska ta fram innan årsskiftet. Så tro inte att det är mycket programmering i mjukvaruutveckling av luftburen mjukvara. Max 10% av tiden.
När jag skrev mitt första program vid 10 års ålder var det inte mycket fokus på dokumentation. Inte i gymnasiet heller. Inte en enda gång under min civilingenjörsexamen inom datateknik dokumenterade jag min mjukvara. En del labbrapporter och övriga rapporter skrevs , men i det stora hela existerade inte dokumentation under utbildningen. Alltså jobbar jag 90% av tiden med någon som var några % i min utbildning. Och ändå jobbar jag exakt med det jag är utbildad för.
Vad jag egentligen vill komma till är att jag idag fick en ordentlig bakläxa på min software detailed description som var på tok för oläslig. Sluta klaga, jag kan systemet i utantill ändå! Efter mycket mutter och tysta svordomar käkade jag upp det sura äpplet och insåg att koddesignen föll på plats av sig själv, bara av att beskriva så att även en stressad projektledare förstår. Det kan kännas bortkastat, dyrt och överarbetat, men det är inte särskilt stora system man kan hålla i huvudet utan att göra en endaste tankevurpa. Och det är dessutom ingen som kan granska odokumenterade tankar, inte ens du själv.
3 kommentarer:
Dessutom är dokumentation viktig för framtida förståelse. Om tio år ska kanske någon annan än du göra uppdateringar i din kod och då är dina tankar viktiga...
Menar du kommentarer i koden också (som överskriften antyder) eller bara dokumentation utanför koden? Kommentarer i koden var jag hyfsat ambitiös med under slutet av min studietid. Men övrig dokumentation av koden håller jag med om att man inte får lära sig speciellt mycket om. Även om jag kan minnas iaf två projektkurser där vi skulle skriva ordentlig dokumentation.
Per: Precis, eller om ett halvår, eller kvart. Detaljerna om hur man tänkte försvinner när man går på fika.
Piggen: Med min något vilseledande rubrik menade jag dokumentation i rapporter av olika slag, alltså utanför koden. Till exempel kan man markera i use case diagram hur vissa krav uppfylls, eller visa beroenden och arv i andra diagram. Om man för varje funktion beskriver dess förutsättningar blir man själv medveten om dem och skriver kanske om funktionen så den blir robustare. Typ :)
Skicka en kommentar