Når man arbejder agilt, kommer man ofte i den situation, at den funktion/metode man arbejder på, virker som den skal, man kunne fristes til at sige, den er helt perfekt. Men... så er det at man tager et skridt tilbage, og kigger på koden. Er der nogle relationer imellem komponenterne, som man måske kunne afkoble, for at sikre at koden bedre kan genbruges, og vedligeholdes i fremtiden.
Når jeg skriver afkoble, så mener jeg, er der noget kode, som man allerede kan se, bliver genbrugt i andre dele af koden, (vi gider nemlig ikke skrive dobbelt kode), så er det god kodeskik, at afkoble den del af koden, og placere den i en klasse, ellere flere klasser, for sig selv.
Det kan godt virke lidt tåbeligt at ødelægge noget der virker, og alt afhængig af projektet, og ens deadline, så har man måske ikke mulighed for flere iterationer, og kunden vil ikke kunne se forskel på det endelige produkt. Dog vil man med disse ekstra iterationer, sikre at fremtidig arbejde med koden, vil være både hurtigere og effektiv, hvilket betyder at det i sidste ende, bliver en billigere løsning for kunden. Det kan godt være at det koster lidt mere i udviklingstimer i første omgang, men i sidste ende, kan det godt betale sig... dog er det ikke altid så sort og hvidt, nogle gange vil der ikke være behov for senere udvikling på produktet, så det er altid en samtale, man skal have med sin PO, til hvert projekt, og så vælge sin arbejdsmetode/arbejdsproces derefter.
Udvikling af fremtidige komponenter/plugins til operatør modulet, vil på nuværende tidspunkt være en nogenlunde behagelig arbejdsproces. Dog vil det ikke kunne undgås at dubleret kode vil opstå, når man begynder at tilføje settings til sit plugin. Hvis man f.eks. skal bruge checkboxe, input felte eller andre html elementer til sine settings, kan det hurtigt blive en lidt anarkistisk arbejdsproces, så næste iteration består i at afkoble settingsdelen med selve plugin delen, og ikke kun det.
Hvis man derudover kan afkoble de enkelte settingskomponenter fra hinanden, så man i fremtiden i sin json fil, kan indtaste navnene på de enkelte settingskomponenter man ønsker at bruge i sin settingskomponent, så ville det virkelig gøre fremtidig kode let at overskue, vedligeholde og ikke mindst genbruge!
Der kommer til at være en del omskrivning af eksisterende kode, og det bliver ikke en let omgang. Jeg hælder til at en designproces med måske en domæne model, eller et klasse diagram bliver nødvendig for at sikre at alle i teamet, har en fælles forståelse af den nye arkitektur i operatør modulet. Jeg har allerede en idé i mit hovede, og vi har da snakket lidt, men det vil kun være en fordel, og mere korrekt føler jeg, at få det visualiseret.
Ude i den virkelig verden, sidder man som regel ikke kun og arbejder med ét projekt. Det kommer jeg heller ikke til. Jeg skal hjælpe med en anden GUI den kommende uge, hvor der skal laves et mockup, der kan vises til PO. Vi har afholdt et indledende møde, hvor jeg spurgte lidt ind til funktionaliteten, og om det skulle være en fungerende prototype, hvilket ikke var nødvendigt i første iteration.
Det virker til at være en forholdsvis simpel opgave, hvor jeg skal bruge lidt tid på at sætte mig ind i den eksisterende kode, og komme op med en god måde at præsentere data, samt håndtere input på via nogle service kald.
Der forventes en afslutning af denne opgave, inden ugens udgang, hvilket gør at mit eksisterende projekt, bliver skubbet lidt i baggrunden. Sådan vil det også være i fremtiden. Som datamatiker, og generelt indenfor IT branchen, er det vigtigt hurtigt at kunne omstille sig fra projekt til projekt, hvilket jeg syntes vi er blevet klædt godt på til.
Jeg føler lige jeg må skrive et par ord omkring min mangel på unit testing. Det var planen at jeg skulle begynde denne ugen, på at implementere testing i min arbejdsproces... det er ikke sket, hvofor ikke? Jeg har faktisk ikke noget godt svar, jeg tænkte at det var et perfekt tidspunkt at starte på, med fungerende grundlogik af operatør modulet og de dynamiske komponenter. Men da der i næste iteration opstod et behov for at afkoble settings fra plugin, tror jeg det føltes lidt overskueligt at "begynde" på 2 ting på en gang.
Det virker lidt dumt når jeg skriver det, da denne iteration var et godt sted at begynde med at få unit testing ind i arbejdsprocessen, et eller andet sted, så er alle steder et oplagt sted at begynde, jo tidligere jo bedre! Jeg er lidt skuffet over, at jeg ikke er gået i gang, kunne godt have brugt en der lige sagde "så starter med med at implementere unit/integrations testing i al vores kode... læs den her artikel, sæt igang!".
Da et af mine læringsmål er at "håndtere strukturering og planlægning af daglige arbejdsopgaver", vælger jeg at være den person som siger det. Fremtidige daglige arbejdsopgaver skal have et ekstra lag af kvalitetssikring via unit samt integrations testing! Det kommer nok til at koste mig en dags tid, men i sidste ende, vil det uden tvivl blive en uvurderlig del af min arbejdsproces.