Et godt solidt stykke arkitektur syntes jeg. Jeg har fået kodet et modul, som er let at vedligeholde, det er en 3-lags arkitektur, hvor selve viewet i præsentationslaget indeholder en wrapper til de komponenter man nu måtte udvikle til modulet i fremtiden. Det er skalerbart, du kan tilføje alle de komponenter til modulet som du ønsker at udvikle, og så ellers dynamisk udvælge de komponenter, du ønsker skal vises.
Jeg prøver altid at sigte efter GRASP når jeg udvikler applikationer/programmer. Jeg har især taget Low Coupling og High Cohesion til mig, og i Angular 2, nu 4! (Ja, vi er gået over til Angular 4), anbefales det at hver komponent kun udfører én hovedfunktion... hvilket passer meget godt med, at vi sikrer os Chart komponenten kun har med charts at gøre... og info komponent ligeså kun har med info beskeder at gøre.
Det gør det utroligt let at vedligeholde i fremtiden, når der skal ændres, eller rettes i koden og/eller i den overordnede funktionalitet.
Jeg er begyndt at bruge Bjarke lidt mere, når jeg har nogle problemer, hvor jeg lige vil sikre, at jeg er på rette vej, i forhold til projektets omfang. Det har udløst et par pair programmings sessioner, hvor vi har sat sammen, og arbejdet med konkrete problemer. Det er noget af det jeg savner mest fra diverse projekters gruppearbejde.
Det har været essentielt for mig, at have den mulighed, for både at sikre min arkitektur er korrekt, men også at vi bruger samme kode struktur og naming conventions.
Det var især noget jeg lærte i mit samarbejde med Hesehus, hvor kvalitetssikring af koden, er noget de bruger meget tid på, via deres udviklingsprocess (Test Driven Development). Jeg kører ikke TDD endnu, men satser på at bruge det i udviklingen af fremtidige komponeter, da jeg ved vi har en dygtig udvikler (Dan), som elsker unit tests og integrations tests, og som jeg håber kan give et par tips til, hvordan man får unit testing ind i sit arbejdsflow i Angular 4.
Jeg har også skulle kigge lidt på gammel kode, hvor jeg måtte omskrive en del af den, og "Angularficere" den. Men da den funktion jeg skulle omskrive, var skrevet i JavaScript, var det nu ikke så slemt. Men jeg syntes stadig det forpligter lidt, at ændre i andres kode, og skære det fra som man ikke mener der skal bruges. Derfor havde jeg også fat i Bjarke inden jeg tog nogle drastiske valg, men da han gav mig ret, og endda fjernede mere kode end jeg havde gjort, var det jo fint. Man kan sige at vi simplificerede koden, så den funktion vi nu kalder, kun gør det vi beder den om, i henhold til GRASP igen.
Jeg har altid været lidt imod at vores projekter i skolen skulle være gruppearbejde, da folk tit slacker, men er der en ting jeg savner, er det Pair Programming med folk der virkelig gider at kode
Nu hvor chart virker perfekt, pånær lidt design forbedringer, var det tid til udvikle resten af komponenterne. Jeg tog fat i resten af teamet, og fik lagt en kort plan, omkring hvilke komponenter jeg skulle starte med. I den her fase, ville jeg nok foretrække vi kørte noget KanbanScrum, hvor vi fik lavet relevante tasks, og deadlines. Jeg foretrækker at arbejde med en konkret use case, derefter udvikle en prototype, teste koden og commit-pull-push... voila.
Jeg udviklede en simpel cyclustid komponent, hvor jeg subscriber til et topic, som indeholder alle de cyclustider, som man har brug for at se. Da fundamentet var kodet, er det utroligt simpelt at udvikle nye komponenter, så det tog ikke lang tid. Dog var der en gammel funktion der skulle omskrives lidt.
Nu kan man vælge at se cyclustider i operatør vinduet, som vises Live, når robotten er aktiv. Det tog næsten ingen tid at kode... nok en 2-4 timer, og det var inklusiv omskrivning af gammel kode.
Man kunne potentielt automatisere en del af den her process, da det er meget af det samme man gør, det er kun de funktioner som komponenten indeholder der kan variere meget. Måske i fremtiden...
Når jeg først er forbi planlægningsfasen, hvor jeg har lavet potentielle diagrammer og modeller, så tænker egentlig ikke meget over det jeg har lært i skolen. Det lægger lidt i baghovedet det fundamentale vi har lært. Det er blevet simpel logik, at man gør koden overskuelig, man placerer sine funktioner/metoder de korrekte steder, og man sikrer sig at koden er genbrugelig. Små simple ting, som gør at man allerede er kommet langt i sin udviklingsproces.
Der hvor jeg virkelig syntes jeg har lært noget som jeg bruger næsten dagligt, er når der skal planlægges. Jeg kan næsten ikke se mig selv arbejde i et miljø, hvor der ikke bruges Kanban/Scrum og hvor man ikke arbejder agilt.
I praktikforløbet indtil videre, har jeg arbejdet agilt, og ved at udvikle prototyper løbende, sikret mig at koden hele tiden har været up to date, og hvis Product Owner kom imorgen og sagde "SLUT, der skal ikke udvikles mere", så ville de have et fungerende produkt... dog med lidt begrænsede funktioner, men virke, ville det.
Jeg har også i flere iterationer været forbi grundkoden af mit modul, for at forbedre koden, når min forståelse er blevet bedre og bedre... Man har en idé om, hvordan man vil kode tingene, og hvordan arkitekturen skal være, men når man udvikler i iterationer, lærer man hurtigt mere og mere, om hvordan man kan forbedre, og potentielt, rette fejl der opstår.
Agile, waterfall, iterative, kanban... Jeg syntes tit det hele flyder lidt sammen. Men i bund og grund handler det om at jeg arbejder fleksibelt, og konstant prøver sikre mig at det endelige resultat bliver ligesom kunden vil have det, med god kode, der er let at overskue.
Det eneste jeg rigtig godt gad, var at få unit testing/integrations testing ind i mit arbejdsflow, for at have et ekstra lag af kvalitetssikring, når man ændrer kode, der påvirker flere dele af produktet.
Jeg burde måske have startet med at teste, og måske endda arbejde med TDD, og det var måske en fejl. Jeg følte bare at det var vigtigere for mig, at lære at begive mig rundt i hele det store CoWorker system, samt at lære så meget som muligt, omkring Angular og alle de komponenter vi bruger.
Jeg har besluttet at jeg vil bruge den kommende tid, på at få indført tests (Karma?) i mit abejdsflow, da jeg mener det vil kvalitetssikre min kode, og øge produktets kvalitet generelt. Måske kan jeg endda indføre det i hele CoWorker systemet, men det er nok en større opgave.
Den står på oprettelse af alle komponenter (funktioner) fra den gamle CoWorker, en af gangen. Skulle gerne have nøjagtig det samme operatør modul, når ugen er omme. Jeg vil også gerne, køre unit testing ind i mit arbejdsflow. Det er planen!