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 projektbeskrivningen. Upptäcker ni problem eller vill göra ändringar uppdaterar ni projektbeskrivningen – 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.

• 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-2019-v1), och håll 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.

• Diskutera projektet med labbhandledaren då och då. Be om feedback på lösningar ni har gjort och ta chansen att fixa eventuella problem så tidigt som möjligt, även om vi så klart inte kan garantera att allt upptäcks. Att använda handledaren är inte en svaghet utan en styrka!

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

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

Fyll i ett labbomslag där ni skriver under att ni har följt alla labbregler på IDA. Labbomslag bör finnas i kartonger i skrivarrummen och kan också skrivas ut från en PDF. (Ja, vi önskar oss också elektroniska signaturer istället.)

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.

• När allt är klart lämnar ni in det ifyllda labbomslaget som ni förberedde.

Projektbeskrivningen lämnas in tillsammans med koden, inte vid demonstrationen.

1. Se till att projektet är i IDEA-format så att vi snabbt kan öppna det, inspektera det och navigera genom koden.

   Har du använt en annan miljö: Skapa ett nytt projekt enligt instruktionerna.

2. Läs genom betygskriterierna en gång till och se till att koden uppfyller grundkraven, inklusive krav på felhantering, resurshantering med mera. Gå genom de specifika tipsen.

3. Kör IDEAs kodinspektioner en sista gång. Det här är till stor del ett sätt att lära sig skriva kod som inte bara gör vad den ska utan även är välskriven och strukturerad.

   Förstår du inte en varning? Utmärkt! Då har du en chans att lära dig något nytt, redan innan du lämnar in koden! Läs IDEAs inbyggda beskrivningar, sök efter varningen i de specifika tipsen, och om det inte hjälper, fråga gärna assistenten eller examinatorn.

   1. Välj Analyze | Inspect Code i menyn.
   2. Välj inspektionsprofil "TDDD78-2019-v1" och tryck OK.

   Inget automatiskt inspektionsverktyg är 100% korrekt. Det kan alltså finnas varningar som är "felaktiga". Alla sådana måste kommenteras på plats på plats i koden, med god motivering. Övriga varningar ska korrigeras. Annars får ni tillbaka projektet!

   Är du osäker? Fråga handledaren, helst i god tid!

4. Dubbelkolla att projektrapporten är uppdaterad. Den ska använda mallen och ska innehålla all den information vi efterfrågar med korrekt numrering av avsnitt. Se den som en tenta – en viktig del av betyget!

   Se till att rapporten är exporterad till PDF-format Använd t.ex. File | Export to PDF i OpenOffice Writer. Döp beskrivningen enligt följande mönster, utan mellanslag i filnamnet. ID måste alltså finnas med.

   • liuid123-liuid456-rapport.pdf

   Se till att rapporten och PDF-filen är adderade till Git och incheckade.

5. Är detta en komplettering? Beskriv i så fall i filen "kompletteringar.txt" hur varje enskild kommentar från handledaren har hanterats: Vad som ändrats och var i koden (klass/metod), hur ni har löst problemet, och annan information som är relevant för att handledaren lätt ska se vad som gjorts.

   Gör ni flera kompletteringar ska gamla kommentarer vara kvar och tydligt skilda från nya kommentarer (markera med kompletteringsdatum). Detta underlättar för oss och är en del av examinationen där ni visar att ni förstår varför kompletteringen behövdes.

   Se till att filen är adderad till Git och incheckad.

6. Checka in all kod och dokumentation, och pusha till det Git-repo du har fått på IDAs GitLab. Kontrollera noga att allt verkligen är incheckat, inklusive IDEAs projektfiler (katalogen .idea eller filen (projektnamn).ipr samt eventuell kompletteringsfil. Om ni använder externa klassbibliotek ska även dessa finnas med – vi använder inte verktyg som Maven etc. för att hämta dem. Alla incheckade och pushade filer kan ses direkt i Gitlabs webgränssnitt.

7. Skapa en tagg (etikett) i Gitlab. Detta visar oss vilken version av koden som lämnades in vid inlämningsdatumet.

   1. Logga in på gitlab.

   2. Gå till ditt projekt och välj "tags".
      

   3. Välj "New tag".

   4. Sätt taggnamnet till "t1" om detta är första gången du lämnar in. Om du får komplettering får du nästa gång sätta en ny tagg "t2", och så vidare.

   5. Låt "Create from" vara kvar på "master".

   6. Meddelanden och "release notes" behövs inte.

   7. "Create Tag"!

8. Dubbelkolla och trippelkolla att allt är korrekt. Inlämningar som har okommenterade varningar, saknar nödvändiga filer eller uppenbart bryter mot viktiga regler kommer att returneras utan bedömning.

9. Lämna in via vårt centrala gitlab-repo! Annars vet handledaren inte att du är klar. En issue ska skapas innan deadline. Följ instruktionerna och använt vårt repo, inte ditt.