Under projektstarten skapar vi regelbundet nya Git-repon för projektgrupperna, allteftersom deltagarna anmäler sig. Titta om ditt/ert repo finns tillgängligt – annars bör det komma inom kort.

Gör en klon av det nya repot, på samma sätt som för labbarna – se de tidigare instruktionerna!

Repot innehåller ett nytt IDEA-projekt. Ni får gärna använda andra verktyg under utvecklingen, men tänk på att:

• IDEA-projektet måste vara korrekt konfigurerat, inklusive eventuella klassbibliotek, för att kodanalysen ska fungera och för att ni ska kunna lämna in det slutliga projektet.

• IDEA kan hjälpa till att åtgärda ganska många indikationer i kodanalysen med hjälp av QuickFix, för en indikation i taget eller för hela projektet.

Under hela programutvecklingsfasen ska ni:

• Följa milstolparna i projektplanen. Upptäcker ni problem eller vill göra ändringar uppdaterar ni helt enkelt projektplanen – den är inte en kravspecifikation, utan projektet kan vid behov ändras under tiden.

• Testa regelbundet, så att ni hittar problem tidigt.

• Putsa och förbättra koden regelbundet, så att ni inte har allt detta kvar till slutet. Nya features är roliga, men hög kvalitet är viktigt.

• Dokumentera regelbundet. Många tidigare studenter skriver att de önskar de hade dokumenterat under kursens gång – efter ett tag glömmer man t.ex. vilka designbeslut man gjorde! Fyll i projektrapporten under tiden, alltså den andra delen av projektmallen.

• Välja objektorienterade lösningar så att ni kan lära er, och visa att ni har lärt er, både Java och objektorientering.

• Titta på kodanalys-issues ofta, och minst ett par gånger i veckan. Detta är ofta ett utmärkt sätt att starta reflektioner över den egna koden och att lära sig något nytt. Ibland kan det så klart ge "falska varningar", och dessa ska då kommenteras så att handledaren får er motivering till varför varningen finns kvar.

• Ge oss omedelbar feedback om det uppstår tekniska eller andra problem.

Det är bättre, både ur betygssynpunkt och för inlärningen, att ha ett projekt med något mindre omfattning men högre kvalitet än att ha ett större antal features som tyvärr inte riktigt fungerar.

Så är det även i "verkligheten", och i många projekt sker därför en feature freeze en tid innan en ny version faktiskt görs tillgänglig. Man slutar alltså lägga till nya finesser och spenderar tid enbart på att fixa problem och "städa upp".

Detta är extremt viktigt och ska göras även i detta projekt!

På slutet kan ni behöva sätta av 10-20 timmars arbetstid där ni slutar lägga till nya finesser. Då spenderar ni istället tiden på att:

• Återigen gå genom kodinspektionen och fixa så många indikationer som möjligt.

  Många får komplettering för att de struntar i problem som kodanalysen redan hade påpekat. Vi kräver givetvis inte perfektion, men ju starkare en varning är, desto viktigare är det att den åtgärdas. Vi kan inte säga exakt när det "räcker" i förväg: Precis som på en tenta gör man sitt bästa innan inlämning och får sitt betyg i efterhand.

• Se över den övergripande strukturen på hela projektet och se om den kan förbättras.

• Gå tillbaka till koden ni skrev i början, och uppdatera den nu när ni kan mer och vet bättre!

• Leta efter ineffektiv och duplicerad kod. Hitta sätt att reducera detta. Finns det till exempel ställen där kod från många liknande klasser egentligen borde ligga i en gemensam superklass? Detta kan ge komplettering!

• Titta på namngivning. Finns det namn som kan ändras och förtydligas? Det är enkelt med Refactor/Rename. Finns det kodrader med som inte är helt lätta att läsa på grund av långa uttryck eller uttryck vars betydelser inte är glasklara? Extrahera dem till variabler med informativa namn; det är lätt med Refactor/Extract/Variable. Svårläst kod kan ge komplettering!

• Uppdatera dokumentationen och kommentarerna.

• Uppdatera projektrapporten (den slutliga delen).

• Finputsa programkoden på "detaljnivå".

• Och så vidare...

Beroende på antal projektgrupper kommer ni att ha cirka 8–12 minuter på er att demonstrera ert projekt för labbhandledaren. Två specifika tillfällen är reserverade för detta. Det går även bra att demonstrera tidigare om handledaren har tid, men vi bedömer ändå alla projekt tillsammans efter deadline.

Använd lite tid närmast innan demonstrationen till att "polera" projektet enligt ovan.

Var förberedda på själva demonstrationen! Allt ska gå att starta smidigt när labbhandledaren kommer till er. Testa att demonstrera för varandra i god tid, så att ni inte hittar uppenbara buggar under demonstrationen för handledaren.

Demonstrationen går till så här.

• Hos de grupper som vill demonstrera ska alla gruppmedlemmar vara närvarande för att svara på frågor (som på en tenta). Kan någon medlem inte komma hänvisar vi till tidigare labbtider eller nästa omredovisningstillfälle.

• Demonstrationen inleds med att ni själva demonstrerar funktionaliteten i projektet under några minuter. Var beredda på att visa hur det används och att visa upp de finesser ni själva tycker är viktigast givet tidsbegränsningen.

• Därefter fortsätter handledaren med egna tester och frågor. Bland annat kan vi testa er kunskap om koden och kontrollera att ni vet varför ni har gjort som ni har gjort. Frågorna kan ställas till en specifik person. Alla ska känna till alla aspekter av koden!

  Detta garanterar inte att alla problem upptäcks – inte ens de som kan verka "uppenbara". Den riktiga genomgången av programkoden sker efter inlämning, när handledaren får tid att sätta sig en timme eller två med enbart ert projekt!

• Labbhandledaren kan också välja att ställa några (individuella!) frågor runt objektorienterad programmering: Vad menas med polymorfism? Varför vill man gömma information? Vad är skillnaden på ärvning mellan klasser och när man implementerar ett gränssnitt? Och så vidare. Var beredda på att svara.

• Om projektet är buggigt kan handledaren välja att gå vidare till en annan grupp så att ni får försöka igen senare. Är programmet för buggigt när demotillfället närmar sig sitt slut kan ni bli hänvisade till omredovisning under nästa planerade demotid.

Projektrapporten lämnas in till oss tillsammans med koden, incheckad i Git – inte vid demonstrationen.

Deltagare i TDDE30 behöver också lämna in projektrapporten till separat rapportgranskning (IKOS).