Följande regler gäller när man använder kod som man inte har skrivit själv (ensam).

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!

Skapa också ett nytt IDEA-projekt i den resulterande arbetskopian. Detta måste i vilket fall som helst göras före inlämning, även om ni huvudsakligen använder ett annat verktyg vid utvecklingen.

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.

• Tänka på hur projektet kommer att bedömas, så att ni inte missar viktiga aspekter.

• 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.

• Gå genom IDEAs kodinspektioner minst en gång i veckan (Analyze | Inspect Code, välj profil TDDD78-2020-v1), och hålla koll på färgläggningen som visas direkt i koden. 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!

När ni har kvar runt 10-20 av de 80 arbetstimmarna är det dags att sluta lägga till nya finesser. Då sätter ni istället av tid till att:

• Återigen gå genom alla IDEAs kodinspektioner och fixa eventuella problem som hittas.

• 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!

• 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 labbtillfä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.

• (Här sa vi tidigare att ni ska lämna in ett ifyllt labbomslag (papper). Det behövs inte längre.)

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