na-na13 / minesweeper Goto Github PK

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

Projekti kloonattu 11.6.2021 klo 15.23 EEST (GMT+3)
(Latest commit 4b8881d)

Yleinen palaute

Koodi on yleisesti helppoa lukea, mutta jonkin verran ns. "copy-pastea" olisi
selvästi mahdollista vähentää. Joitakin rivejä voisi myös mahdollisesti hieman
lyhentää esimerkiksi pilkkomalla ne useammalle riville ja siirtämällä joitakin
koodin osia omiksi funktioikseen. Erityisen vahvasti naapurien käsittelyssä
olevat listat if-lausekkeista vaikuttavat turhahkolta "copy-pastelta".
Pylint on selvästi löytynyt jo, joten kannattaa ihmeessä korjata mahdollisimman
suuri osa sen ilmoittamista tyylivirheistä. :)

Itse peli toimii hyvin, joskin valikoiden osalta käyttöliittymä voisi kaivata
pientä hiontaa. Käyttöliittymä kuitenkin selvästi toimii, joten tämä vain hieman
selkeyttäisi valikoita.

Bottia en pahemmin päässyt kokeilemaan, sillä pienellä kommentoidun koodin
ottamisella käyttöön sain sen tekemään vain ensimmäisen painalluksen.

Ohjelman testaus vaikuttaa tässä vaiheessa kurssia vielä melko puutteelliselta,
sillä testejä on kaksi ja niistä toinen (test_hints_correct) ei ainakaan
itselläni mennyt läpi.
Sain kuitenkin viikkoraporteista sen käsityksen, että et ole aiemmin tehnyt
mitään vastaavaa Pythonilla, joten testauksen vähäisyys mm. kielen
tuntemattomuuden vuoksi on aivan ymmärrettävää.

Dokumentaation osalta ainakin jonkinlaisesta pienestä käyttöohjeesta olisi
voinut olla hieman apua, sillä päädyin ensin suorittamaan tiedoston
minesweeper.py enkä ui.py. Molempien lopusta kun löytyy
if __name__ == "__main__": .... Tämä pieni ongelma toki ratkesi tutkimalla
koodia hieman lisää.

If-lausekkeiden vähentäminen

Ympäröivien ruutujen läpikäymisessä voisi olla selkeämpää käyttää kahta
sisäkkäistä for-silmukkaa kuin pitkähköä listaa if-lausekkeita.
Esimerkiksi:

for i in range(-1, 2):  # [-1, 0, 1]
    for j in range(-1, 2):  # [-1, 0, 1]
        if i == j == 0:
            continue
        ...

Halutessaan voi käyttää myös vain yhtä silmukkaa:

naapurit = [(-1, -1), ..., (1, 1)]
for i, j in naapurit:
    ...

Automatisoitu testaaminen

Pip-työkalulla saa asennettua paketit pytest-cov ja codecov, joiden avulla
saa lisättyä GitHub-repositorioon melko helposti testikattavuuden näyttävän
badgen. Kannattaa myös ottaa käyttöön GitHub Actions ja ajaa siellä testit
automaattisesti. Tästäkin saa lisättyä badgen repositorioon.

Pytest-cov on helposti käytettävissä myös ajaessa testejä omalla koneella, joten
sen kanssa ainakin rivikattavuuden seuraaminen on helppoa.

Lisäksi ainakin oman kokemukseni mukaan parhaita testejä saa kirjoitettua
löytämällä bugeja manuaalisesti ja kirjoittamalla sitten testin tätä bugia
varten. Näin vaikka vain kyseisen testin voi ajaa jokaisen muutoksen jälkeen
kunnes bugi on korjattu. Lisäksi on myös helppoa myöhemmin huomata, jos sama
bugi vielä joskus ilmaantuu takaisin koodiin.

Toivottavasti saat vielä kurssin lopun aikana valmiiksi ohjelman, joka onnistuu
ainakin useimmiten tehokkaasti pelaamaan läpi miinaharavan. Ja toivottavasti
tästä vertaisarvioinnista on edes jonkinlaista pientä apua. Hyvää loppukesää!