Grubblerier

Våndor i utveckling.

Jag tänkte skriva lite om det idag.

Fortress Defender - en skärmdump

Som du kanske vet sedan tidigare håller jag på att utveckla ett minispel mha. multimediabiblioteket PyGame. Man skulle kunna säga att spelet ”är ett PyGame”.

Nå först byggde jag ”kanonbollarna”, kallade ”Ball” i koden. De rör sig linjärt över skärmen, genom centrumpunkten (eftersom fortet befinner sig i centrum av havet).

När jag började koda attackbåtarna, ”Boat”-klassen, igår upptäckte jag att de har stora likheter, dessa två entiteter. De rör sig båda linjärt, och de består av en enda bild som ritas ut på skärmen. Dessutom triggar de varsin händelse när de är ”klara”. I Ball-fallet triggas ”ta bort mig”-händelsen. I Boat-fallet triggas ”game over”.

En snutt av Boat.py-filen

Båda klasserna är enhetstestade och fina, fast testerna är ganska så likartade. De testar ”var befinner sig entiteten i början”, ”var i slutet” och ”var i mitten” (av sin bana/livstid). Dessutom kollar de så att rätt händelse triggas på slutet.

Så långt allt väl. Men vän av ordning vill såklart bryta loss den gemensamma funktionaliteten i detta – förenkla ”uttrycket” som koden kan ses som. Alltså faktorisera ut en basklass eller hjälpklass som har förmågan att ”röra sig från A till B på tiden T, och triggar händelsen H när den är framme”.

Om jag då skulle utveckla en sådan tredje, mera generell klass, kanske kallad Entity eller något lämpligt, så skulle jag få  ytterligare enhetstester som gör samma sak .

En tredje gång.

Aj.

Så med denna vånda har jag vankat fram och tillbaka i tankevärlden idag.

Du som är lite tekniskt insatt förstår – kanske programmerat några rader själv nångång – att dessa ting inte är tekniskt/matematiskt avancerade. De är snarare psykologiskt påfrestande.

Jag kan ge ett annat exempel på hur mycket psykologi påverkar programmerare. Åtminstone denna programmerare.

Jag kodar spelet i Python – men till vardags jobbar jag i .NET med programspråket C#. Där skrivs klasser så här ”DettaÄrEnKlass”, och metoder likadant: ”DettaÄrEnMetod”. Så naturligt nog använde jag samma konvention i detta projekt av gammal vana.

Igår hittade jag till ett slags Python-konventions-dokument. Metoder skrivs av tradition ”detta_är_en_metod” i Python. Klasser skrivs med samma konvention som i .NET.

Så? Vad betyder detta då? Ja inte ett smack rent tekniskt. Spelet kommer att funka precis lika bra eller dåligt oavsett hur namnen skrivs i källkodsfilerna. Men det är ett sådant där litet dammkorn i ögat varje gång jag nu ser metoder och metodanrop som är skrivna på ”fel” form. Rent psykologiskt.

Jaja. Nu ska jag fortsätta våndas över att jag kommer att ha tre-gånger-upprepade enhetstester i mitt projekt, tills dess jag kommer på en elegant lösning. Hjälpa mig?

Taggar: programmering, fortdef, psykologi

Annons