Vertaisarviointi 2

[Aikamoine]

Ohjelmakoodi ladattu 14.6.2021 klo 15:30

Ohjelman toiminnasta

Miinaharava-peli vaikuttaa toimivan oikein hienosti! Tyhjien ruutujen avaamiseen käytetty syvyyshaku on onnistuneesti implementoitu.

Käytännön parannusehdotus: merkattua ruutua ei pitäisi pystyä klikkaamaan. Kyllähän se ottaa aivoon, jos on löytänyt 98 miinaa ja vahingossa klikkaa jo löydetyksi merkattua. Voisin kuvitella :D

Dokumentaatiosta

Tällä osa-alueella olisi aika paljon tehtävää. Tässä muutamia erillisiä huomioita, millä dokumentaatiota voisi parantaa:

• Määrittelydokumenttiin linkki/lähdeviite käytettyihin lähteisiin
• Committien nimeämistä kannattaa miettiä. Jos joskus joutuu menemään versioissa takaisinpäin, niin arpominen commitin ”koodia päivitetty” ja ”lisäys” välillä voi osoittautua vaikeaksi. Tähän syntiin syyllistyy kyllä jokainen ohjelmoija :)
• Koodin kommentointi. Etenkin UI-luokassa on paljon koodia, missä käytetään kokonaislukua osoittamaan koordinaattia - tämän tulkinta muille kuin alkuperäisen koodin tekijälle on tosi hankalaa.
• Docstring. Oletkin jo joissakin metodeissa kommentoinut metodin alkuun, että mistä siinä on kyse. Tällainen kommentointi tulisi tehdä docstring-merkintöjä käyttäen.
  • Tämä käytännössä vain tarkoittaa, että metodin alkuun kirjoitetaan selvitys kolminkertaisten lainausmerkkien sisään. """Ikäänkuin näin""".
  • Täällä lisää aiheesta
  • jos käytät Visual Studio Codea, niin sinne saa ladattua lisäosan Python Docstring Generator
• Käyttöohjeelle olisi tarvetta. Vaikka ohjelman käynnistämisen jälkeen käyttöliittymä onkin aika simppeli, niin asennusohje pitäisi löytyä. Nytkin käyttäjän pitää itse ymmärtää asentaa Poetry, jotta ohjelman saa toimimaan oikeilla riippuvuuksilla.
  • Poetryn riippuvuuksista puuttuu Pygame, muista lisätä se!
• Muista myös tehdä muut kurssilla vaaditut dokumentit: testaus ja toteutus

Koodin laadusta

Kirjoitettu koodi on sinänsä varsin selkeää ja esimerkiksi nimeämiskäytännöt ovat hyviä. Kaksi laadunhallinnan konseptia nostaisin tässä kuitenkin esiin: Primitive Obsession ja käyttöliittymän sekoittuminen ohjelmalogiikkaan.

Primitive obession näkyy tässä siten, että ohjelmakoodi sisältää todella paljon kokonaislukuja. Nämä olisi hyvä abstraktoida edes muuttujien taakse, niin ohjelman dynaaminen muuttaminen onnistuisi helpommin. Voi myös miettiä, että mille kaikelle voisi tehdä oman luokan.

Käyttöliittymän ja peliruudun piirtäminen olisi hyvä erottaa omaksi luokakseen. Nyt pelilogiikka piirtää tapahtumia, mikä tekee todellisten pelilogiikan tapahtumien seuraamisesta vaikeaa. Lisäksi mahdollinen käyttöliittymän koon/tyylin muutos vaikuttaisi kaikkialle koodiin. Tein itse ohjelmistotekniikan kurssilla sudokun, jossa käyttöliittymän piirtävällä luokalla oli oliomuuttujana pelin mekaanisesta tilasta huolehtiva luokka. En nyt sano, että tämä olisi paras (tai edes suositeltu) tapa, mutta itselleni se ainakin toimi melko hyvin.

Voisiko font-muuttujasta tehdä oliomuuttujan? Tietääkseni sitä ei tarvitse alustaa jokaista tekstipätkää varten erikseen, mutta nyt täysin sama olion luonti tehdään monesti.

Jos suorituskykyä haluaa miettiä, niin olisiko tehokkaampaa pitää kirjaa oikein epäillyistä miinoista, tai pitää muistissa avattujen ruutujen määrä sekä miinojen määrä? Näin pystyisi yhdellä laskutoimituksella selvittämään onko peli voitettu, eikä tarvitse aina lukea koko taulukkoa läpi

Muuta

Tässä vaiheessa projektia en lähtisi enää lisäämään, mutta kannattaa ehkä tutustua pygame-menu -kirjastoon. Se on varsin intuitiivinen ja helpottaa valikoiden tekemistä.

Ei ole tarkoitus mainostaa, enkä ole ohjelmistotekniikan harjoitustyöstäni edes mitenkään erityisen ylpeä, mutta voisit sieltä saada hieman vinkkejä tähän työhön. Vaikuttaa ainakin siltä, että olen paininut hyvin samankaltaisten ongelmien kanssa. Repositorio löytyy täältä.

Toivottavasti saat loputkin toiminnallisuudet tehtyä - tässä on hyvä asetelma. Tsemppiä!