SP3
Da alle har lavet det samme projekt, skal hver gruppe vælge et emne relateret til deres projekt, som de gerne vil præsentere til review.
I præsentationen vil vi gerne præsenteres noget viden I har fået under projektforløbet.
Sørg for at forberede jeres præsentation, gerne med nogle slides.
Fordel taletiden mellem alle gruppemedlemmer. SP3 godkendelse kræver at man deltager i præsentationen af projektet.
Objektorienteret analyse og design: Formålet med objektorientering er at skabe sammenhæng mellem domænet og løsningen, så koden afspejler den virkelighed, den modellerer. Hvordan når man frem til et godt objektorienteret design? Hvilke metoder og teknikker findes, og hvilken rolle spiller de hver især? Hvad opnår man i koden ved at anvende nedarvning, interfaces og polymorfi? Fortæl om, hvordan I brugte domænemodel og klassediagram i udviklingsprocessen, og hvordan de ændrede sig undervejs. Kom også gerne ind på sekvensdiagrammer, use cases og andre måder at nedbryde problemet på.
Samarbejde og kommunikation: Hvilke teknikker kan man anvende, når man er flere om at kode det samme system? Hvad er konsekvensen, hvis kommunikationen i teamet ikke fungerer? Hvordan sikrer man, at alle har det samme billede af, hvad der skal kodes, så man ikke koder i hver sin retning eller oven i hinanden? Hvordan strukturerede I arbejdet i jeres projekt? Brugte I git (branches, pull requests, merge-konflikter), pair programming, Code With Me eller andet? Hvilke diagrammer og andre design deliverables brugte I til at skabe en fælles forståelse af opgaven?
Gruppedynamik, roller og konflikthåndtering: Et projekt lykkes ikke kun på god kode, men også på et velfungerende team. Hvilke faser gennemgår en gruppe typisk (fx forming, storming, norming, performing), og kunne I genkende dem i jeres eget forløb? Hvilke roller opstod der i gruppen – var de aftalt på forhånd, eller opstod de af sig selv? Hvordan påvirkede forskelle i erfaring, ambitionsniveau og arbejdsstil samarbejdet? Lavede I en samarbejdskontrakt eller andre fælles aftaler, og blev de overholdt? Hvordan håndterede I uenigheder, fx om design, kodestil eller arbejdsfordeling, og hvad gjorde I hvis nogen ikke leverede det aftalte? Hvad har I lært om jer selv som teammedlemmer, og hvad ville I gøre anderledes i næste projekt?
Datapersistens: Hvordan sikrer man, at programmets tilstand ikke går tabt fra den ene session til den næste? Skal man gemme ændringer, i det øjeblik de sker, eller først når programmet lukkes? Hvilke fordele og ulemper er der ved de to tilgange? Hvordan adskiller man den kode, der står for at persistere data, fra resten af koden, fx logik og brugerinterface? Fik I bygget en skalerbar løsning i forhold til datapersistens? Hvor nemt ville det være at udskifte datalaget, fx fra tekstfiler til en database? Hvilke udfordringer oplevede I i forbindelse med at gemme og indlæse data? Kom også gerne ind på de datastrukturer, I valgte, og mulige alternativer.
Separation of concerns: En af kongstankerne bag OOP er, at hver klasse har ansvar for en afgrænset del af systemet, og at der er løs kobling mellem ansvarsområderne. Det gør koden lettere at forstå, ændre og genbruge, og det hjælper med at undgå spaghettikode. Hvad betyder det, at en klasse har ét ansvar, og hvordan afgør man, hvor grænsen mellem to ansvarsområder går? Hvad er forskellen på høj og lav kobling, og hvorfor er løs kobling at foretrække? Hvor i jeres kode har I eksempler på dette designprincip, og hvor har I eksempler på det modsatte? Har I klasser, der ved for meget eller gør for meget? Hvordan kunne de deles op? Hvordan delte I jeres program op i lag, fx brugerinterface, logik og data? Hvilke klasser kender til hinanden, og hvad ville der ske, hvis I skulle ændre én af dem? Hvor nemt ville det være at skifte tekstbaseret UI ud med et grafisk UI? Hvordan hænger separation of concerns sammen med testbarhed og muligheden for, at flere kan arbejde på koden samtidig? Hvilke udfordringer stødte I på, da I forsøgte at følge princippet? Kom også gerne ind på navngivning af klasser og metoder, og hvordan et godt navn kan afsløre, om en klasse har ét klart ansvar.
Unit testing: I et større projekt med mange features skal man hurtigt kunne teste, om alt stadig virker, når koden ændres. Hvordan kan unit tests hjælpe med det? Hvad er en god unit test, og hvilke dele af koden er nemme eller svære at teste? Hvordan arbejdede I med tests, og hvilken effekt havde jeres tilgang på udviklingsprocessen og kodens design?
Eget valg: Hvis der er noget helt andet, I gerne vil præsentere, eller hvis I gerne vil snakke om flere af ovenstående emner, så tal med en underviser om det.