iivorait
commented
10 years ago Kiitos kattavasta palautteesta. Tungin App.javaan vähän aiheeseen kuulumatonta tavaraa (arviointiin kuulumaton tulostus ja BFS-algoritmi), jotka kyllä voisi siirtää omiin luokkiinsa. Lisäsin kommentin Verkon lisaaSolmu-metodille. Solmusotkusta olet oikeassa. Suunnittelin aluksi tekeväni verkon vierusmatriisina, mutta päädyin vieruslistaesitykseen sen oliopohjaisuuden vuoksi. Loppupelissä vierusmatriisi olisi saattanut olla yksinkertaisempi ja tehokkaampi ratkaisu, mutta tällä nyt mennään. Testeistä tuli pitkiä syistä että jokainen testattava verkko on erilainen (setUppeja vaikea hyödyntää) ja kun verkko on kerran tehty, niin samalla tehdään sille monta testiä. Linkitetylle listalle ja listasolmulle ei ole testejä (tästä on maininta testausdokumentaatiossa).
Vertaisarvio
Versio: 14:33 14.10.2014
Yleisesti
App.java
Luokka on hoitaa ohjelmansuorituksen(main), suorituskyvyntestauksen, projektin graafisen esityksen sekä tietorakenne ja sovelluslogiikkaa. Kannattaisiko vähentää luokan vastuuta luomalla uusia luokkia.
Verkko -> LinkitettyLista -> ListaSolmu -> Solmu -> LinkitettyLista
Luokat erillisinä näyttivät tosi selkeiltä (Verkon lisaaSolmu metodille olisin toivonut kommentoinnin). Ongelmaksi lähinnä koin sunnittelun. Otsikon on tarkoitus kuvata luokkien riippuvuuksien rakennetta. Intuitiivisesti solmu on projektin atomaalisinosa. Listasolmut ovat käytännössä kehyksiä solmuille, joilla ylläpidetään linkitetynlistan järjestystä. Lähestyessäni tästä näkökulmasta koin ongelmalliseksi vierussolmujen merkitsemisen solmuun linkitettyinälistoina. Ymmärrän syyn ja hyödyn miksi solmujen olisi hyvä tietää viereiset solmut. En ole kuitenkaan varma, että onko solmu-luokka enää kovin atomaalinen/yksinkertainen tällä tavalla toteutettuna. Tietenkin kun oletuksia ei oteta huomioon homma pelaa, mutta sitten herää vain kysymys, mikä on atomaalisin osa(alkio) projektissa.
Testit
Ensisilmäyksellä vaikutti testejä olevan niukasti (26 testiä / 6 testiluokkaa = 4,33 testiä per testiluokka!). Ajoin testit ja kaikki vaikutti toimivan. Seuraavaksi tarkistin sekä coberturan, että pitin tulokset. Jos AppTestiä ei lasketa oli rivikattavuus 100%. Eli vaikka testejä oli vähän, niin silti tulokset olivat tosi hyvät.
Seuraavaksi katsoin testejä tarkemmin. Testien niukkuus yksinkertaisesti johtuu siitä, että testit ovat melko tuhteja. Lähes kaikki testit sisälsivät useamman assert-vertauksen. Ulkopuolisena koin tämän tekevän testeistä melko vaikealukuisia. Esim. testien nimet eivät kuvanneet täsmällisesti mitä testattiin, koska testattavaa oli paljon. Kommentointi testien sisällä auttoi kuitenkin merkittävästi. Testien pilkkominen useampaan osaan voisi edesauttaa testien luettavuutta. Toinen vaihtoehto on, että hyödyntäisit setUp metodia testeissä, niin ei välttämättä tarvitse alustaa testauskohteita testirungon sisällä. Jos luot JUnit-testit automaagisesti netbeansissa, niin tulee luokan mukana aika paljon metodeja joita voi käyttää testin kanssa.
Kloonamani versio ei sisältänyt linkitetynlistan ja listasolmun yksikkötestijä.
Lopuksi
Projekti vaikutti hurjan mielenkiintoiselta ja pisteet kaikkien tietorakenteiden suorittamisesta. Ei ole vaikea nähdä, että työn eteen on nähty vaivaa ja panostus on suuri. Kommenttini koskivat lähinnä designia, mutta toteutustavallahan ei sinänsä ole merkitystä kunhan homma pelaa. Suunnittelulla ei varmaan ole niin suurta painoa arvioinnin kannalta. Ajattelin nyt kuitenkin tarjota pienen pähkinän purtavaksi, jos siitä vaikka olisi jotain hyötyä. Tsemppiä demoon!