Slutprojekt: bygge

Från skiss till körande program

Du startade med ett skript som skrev ut en rad text, och innan det första temat var slut hade du byggt ditt första textäventyr. Sedan kom fightingspelet med slumpad skada, och därefter ett chiffer från romarriket som både krypterar och tar sig tillbaka. Tre program, alla dina, och inget av dem fanns när du började.

Ett av dem valde du redan i Slutprojekt: design, tillsammans med vem det är till för och hur det ska se ut. Nu bygger du det. Det är steget från kod som fungerar till mjukvara som levereras.

Det är också sista gången i kursen någon talar om för dig vad du ska bygga. Städningen och dokumentationen väntar i nästa del, men själva programmet avgörs här. Nästa gång du ser ett problem och vet hur du löser det skriver du koden utan att någon bett dig om det. Det är vad en programmerare är.

Uppdraget

Det här är en inlämningsuppgift som bedöms, men vi arbetar som på riktigt: förstå problemet, bygg i små steg, testa, lämna ifrån dig något som fungerar.

Bygg ett fullständigt, körbart program baserat på ett av dina egna program från kursen. Det ska fungera som en fristående applikation: användaren startar det, tar sig igenom det utan att behöva läsa koden, och avslutar det på ett sätt programmet självt erbjuder.

Programmet ska vara designat för den målgrupp du definierade i Slutprojekt: design, och följa skissen du ritade där. Avviker du från skissen är det ingen katastrof, det är information: skriv ned varför. Det är precis en sådan sak bedömningssamtalet handlar om.

I den här delen är målet att få programmet att fungera. Städningen kommer sedan, i Slutprojekt: leverans, och ordningen är avsiktlig. Att kräva vacker kod av någon som fortfarande brottas med logiken är att kräva två saker samtidigt.

Två spår, samma ribba

Du väljer själv vilken form applikationen får.

Grafiskt gränssnitt. Programmet öppnar ett fönster och användaren arbetar i knappar, textfält och etiketter. Formen är bekant för alla och kräver att du håller ordning på tillstånd och visning samtidigt.

Terminalgränssnitt. Programmet kör i terminalen med en meny som återkommer efter varje val. Ingen grafik, men allt annat gäller: tydliga instruktioner, begripliga felmeddelanden, en väg ut och ett tillstånd som överlever att programmet stängs.

Terminalspåret är inte den enklare vägen, det är den andra vägen. Ett terminalprogram med genomtänkt meny, tåliga inmatningskontroller och sparad data är ett bättre slutprojekt än ett fönster med tre knappar som kraschar på tomt fält. Bedömningen tittar på samma saker oavsett vilket du väljer.

Mönster du behöver

Nu är det Mönsterkortet som betalar tillbaka. Identifiera varje mönster i din kod och namnge det i din README.md. Den listan är också vad bedömningssamtalet i nästa del utgår från när du ska förklara en funktion du är nöjd med.

“Håll koll på poäng eller HP” -> Räknaren

“Programmet lyssnar tills användaren väljer att sluta” -> Menymönstret, i terminalspåret din egen while-loop, i fönsterspåret sköter tkinter loopen åt dig

“Fånga en inmatning som inte går att lita på” -> Valideraren, mot ett input() eller ett Entry-fält

“Ladda sparad data vid start” -> Persistent lagring, ladda() och spara() från Filen som minns

“Visa användaren vad som gäller just nu” -> Presentatören, en funktion som är ensam om att skriva ut eller uppdatera, så att resten av koden bara ändrar data

“Kontrollera om inmatning eller ett spelvillkor är giltigt” -> Valideringsfunktionen, returnerar True eller False

“Håll tillstånd, ändra det via val, visa om” -> Tillståndsmönstret, tillstånd i variabler, logik i funktioner, visning i en separat funktion. I fönsterspåret är det GUI-tillståndsmönstret från Knappar & räknaren

Bygget, steg för steg

Ordningen spelar roll. Varje steg ska sluta med ett program som går att köra, och en commit.

1. Skapa mappen och main.py. Kopiera in ditt gamla program och kör det, oförändrat, en sista gång. Det är din utgångspunkt, och den fungerar redan.

2. Bygg det tomma skalet. Ett fönster som öppnas och går att stänga, eller en meny som visas och har ett alternativ som avslutar. Ingen funktionalitet alls ännu, bara vägen in och vägen ut. Kör det. Nu har du en applikation, om än en tom.

3. Koppla in en enda sak. Ett val, en knapp eller ett menyalternativ som gör något riktigt från ditt gamla program. Kör det. Det är den viktigaste körningen i hela projektet, för nu vet du att de två halvorna kan prata med varandra.

4. Fyll på, en sak i taget. Ett val, en körning, en commit. Frestelsen är att skriva allt och köra på slutet. Motstå den. Buggen du hittar direkt tar minuter, buggen du hittar bland femtio nya rader tar timmar.

5. Var elak mot ditt eget program. Tryck enter på ett tomt fält. Skriv hej där det ska stå ett tal. Välj alternativ 9 när det finns tre. Klicka tre gånger snabbt. Varje krasch du hittar nu är en krasch din målgrupp slipper.

6. Kör hela vägen som din målgrupp. Starta, gör det de skulle göra, avsluta. Startar du igen ska det som ska ha sparats finnas kvar.

Kraven, i tre nivåer

Nivåerna bygger på varandra. Den övre finns inte utan den under.

Grunden

Det här är hela uppdraget, och det räcker långt.

Ett färdigt gränssnitt. Programmet startas med python main.py. Användaren möts av något som förklarar sig självt och kan göra allt programmet erbjuder utan att läsa koden. Väljer du fönsterspåret sker all interaktion i fönstret, inga input()-anrop mot terminalen finns kvar i den slutliga versionen. Väljer du terminalspåret möts användaren av en meny som återkommer efter varje val, med ett alternativ som avslutar programmet ordnat.

Ursprungligt projekt. Programmet bygger direkt på ett av dina egna program. Den ursprungliga logiken ska vara kvar, du lägger ett gränssnittslager ovanpå befintlig kod, du skriver inte ett nytt program från grunden.

Kraschsäkring. Programmet ska inte falla på tomma fält, bokstäver i numeriska fält eller snabbt upprepade klick. Använd try/except och läs_int() eller likvärdigt där det behövs.

Målgruppsanpassning. Ordval, felmeddelanden och flödet genom programmet ska motsvara den person du definierade i designfasen, inte en abstrakt användare. I fönsterspåret gäller det även text- och knappstorlek.

GitHub. Koden ligger i en namngiven mapp i ditt kursrepository med main.py som startpunkt, och historiken visar hur programmet växte fram.

Utbyggnaden

Grunden plus något som inte fanns i originalet, byggt av dig, ovanpå din egen kod.

Det tydligaste exemplet är ett minne: minst ett tillstånd som sparas till fil och laddas vid nästa start, med tekniken från Filen som minns. Men minnet är inte det enda som räknas. En andra fiende i Brawl med eget beteende, en sökfunktion i inventoryt, kapitel som låses upp av något du bär med dig: allt som gör programmet till mer än originalet i ny förpackning duger, så länge du kan förklara vad du byggde och varför.

Kombinationen

Två av dina program som möts i ett, så att det ena använder det andra. Exemplen står i Slutprojekt: design, och valet gjorde du redan där.

Det svåra är inte att få båda att köra. Det svåra är att bestämma vem som äger tillståndet: håller striden reda på hjältens hälsopoäng, eller lånar den bara ett värde och lämnar tillbaka det? Bestäm det innan du kodar och skriv ned svaret. Det är en fråga varje riktigt system förr eller senare måste besvara.

Det du inte måste göra

Programmet behöver inte vara vackert. tkinters standardutseende räcker, och en terminalmeny av ren text räcker, om funktionaliteten och strukturen är rätt.

Du behöver inte lösa varje tekniskt problem du stöter på. En välstrukturerad, delvis fungerande applikation med ärlig dokumentation av vad som saknas är mer värd än en rörig applikation som påstår sig fungera.

Och du behöver inte städa koden ännu. Det steget har en egen del.