Som jeg beskrev sidste uge, var det tid til at afkoble settingsdelen fra selve plugindelen, en opgave som jeg godt vidste ikke ville blive let. Jeg blev faktisk så udfordret, at jeg begyndte at tænke på, hvordan jeg kunne lette arbejdet, og prøvede at tænke lidt over, hvad vi har lært på uddannelsen omkring system udvikling. Jeg tænkte hovedsaligt på modeller og charts, som kunne hjælpe mig visuelt, med at få mine tanker ned på papir.
Det er vel også derfor vi lærer forskellige metoder og teknikker, så vores mentale værktøjskasse bliver fyldt op med værktøj, som vi kan bruge til de respektive begivenheder, som kræver mere end bare rutinen.
Hvis jeg lige kort skal forklare min problemstilling:
Det kan godt være lidt forvirrende, og lidt svært at sætte ord på, derfor ville det være rart at kunne visualisere det, og ud fra en model/chart, konkretisere ens tanker omkring arkitekturen i koden. Det prøvede jeg sidste uge, samtidig med at jeg prøvede at finde ud af den bedste "Angular" måde at kode interaktionen mellem komponenterne på. Det er absolut en mega spændende opgave, men den gør mig også lidt gråhåret.
Jeg fik hurtigt afkoblet selve koden, ud i deres egne komponenter, og fik lavet en overordnet wrapper, som håndterer genereringen af indhold i de respektive komponenter. Jeg lavede en mockup json fil, hvor man indtaster hvilke settings komponenter man vil have, under et settings array, så hvis man gerne vil have en dropdown i sine plugin indstillinger, så ville man skrive type: "DropdownComponent", samt give den et unikt navn ala, name: "Simpel Dropdown".
Herefter kan man tilgå den dropdown i sin kode, via det unikke navn, da man måske gerne vil have flere dropdowns, eller flere ens indstillinger til ens plugin... det er i hvert fald planen, jeg er der ikke helt endnu, hvilket bringer mig hen til essensen i denne rapport.
Hvordan håndterer vi Get/Set af data på indstillingerne mellem plugin komponent og de indstillinger som det bruger? Vi skal jo gerne kunne ændre på indstillingerne dynamisk, og koden skal være modulær, let at vedligeholde og let at bruge
Min første tanke var at lave et klasse diagram, da jeg kommer til at have en del klasser og komponenter, men jeg har egentlig aldrig været fan af klasse diagram, det bliver hurtigt uoverskueligt. Jeg hælder mere til at bruge domæne model, hvilket jeg er lidt fan af, da en domæne model, per automatik tvinger en til at tænke over den fælles forståelse af problemstillingen i henhold til ens kode.
Jeg glemmer til tider, at det ikke kun handler om at levere et produkt der virker, men også sikre at det i fremtiden er muligt for andre udviklere af produktet, at forstå og udvide koden.
Når man laver en domæne model, bliver navngivningen på ens klasser og metoder en vigtig process, som man tænker lidt mere over, end når man bare koder derudaf. Heldigvis bliver man med erfaring dygtigere og dygtigere til, at navngive klasser m.m. i sin kode, men når man laver en domæne model, får man et bedre overblik over hele funktionaliteten i ens kode, og kan bedre navngive de enkelte sammenhænge mellem datalaget, businesslaget og præsentationslaget.
Jeg begyndte at oprette en domæne model, og nu skal det siges jeg ikke sidder og kigger i Larman når jeg laver mine modeller, hvilket måske er en fejl. Jeg har en idé omkring hvordan jeg vil tegne dem, og så kigger jeg på et par eksempler, og går ellers i gang.
Det vigtigste for mig er: Giver det mening for mig og for andre. Det skal helst styrke den fælles forståelse for koden, ellers giver det meget lidt mening at bruge tid på at lave dem.
Efter at have læst lidt dokumentation, tænkte jeg at en Shared Service ville være det oplagte valg, så jeg lavede min domæne model, ud fra den tankegang. Jeg ville lave en SettingsService, som skulle binde dataen mellem Settings<->Plugin, der var en del eksempler på Angulars hjemmeside, det virkede overskueligt.
Jeg hev en kollega ind, fik ham til at kigge på domæne modellen, og forklarede imens.
Han mente jeg komplicerede tingene, og bare burde lave en View Model, som jeg lagde den relevante data ind i, og så ellers inkluderede i de respektive komponenter. Når man så ændrede i modellen, ville dataen takket være Angular's data-binding, automatisk opdatere alle de steder man har inkluderet modellen.
Det her er groft pseudo-kode skrevet, der er en del inheritance, implementering, inputs... grundlæggende kode, som gør det muligt, og der skulle laves mange klasser og komponenter. Men vi snakkede lidt om det, og sad og kørte lidt extreme programming i et par timer, hvilket er absolut det fedeste ved dette projekt, jeg elsker pair-programming, og til slut, havde vi et solidt fundament, som jeg så skulle kode videre på. Vi var ikke færdige, men godt på vej.
At lave en domæne model, var en stor hjælp, og nu skal den bare opdateres, og bruges gennem resten af forløbet.
Det er rart at have værktøjer man kan bruge til at hjælpe med den fælles forståelse. Men det er ikke nok at have en fyldt værktøjskasse, man skal også vide, hvornår det enkelte værktøj bruges bedst. Nogle gange er der flere løsninger, og så er det bare at vælge det værktøj man har det bedst med at bruge.