Skip to content
This repository was archived by the owner on May 4, 2025. It is now read-only.
This repository was archived by the owner on May 4, 2025. It is now read-only.

Vertaisarviointi #1

@psangi-hy

Description

@psangi-hy

Latasin projektin lauantaina 16.2 kello 13.45.

Ota palautetta lukiessasi huomioon, että React on minulle vain pintapuolin tuttu, enkä väitä neuvoni sen suhteen olevan välttämättä kovinkaan hyödyllisiä.

Koodisi on pääosin yksinkertaista ja selkeää, ja olet myös React-komponenteissa varsin menestyksekkäästi onnistunut välttämään sellaista sisennyshelvettiä, jota olen itse tottunut näkemään React-koodia lukiessani. Muutama React-komponentti on sellainen, joka sisältää pääasiassa vain yhden toisen React-komponentin, joka on omassa, erillisessä tiedostossaan. Tällaisia toisiinsa liittyviä, yksinkertaisia komponentteja voisi mielestäni ehkä osittain koota samoihin tiedostoihin, koska tiedostojen välillä hyppeleminen ei auta kokonaisuuden hahmottamisessa. Jos jokin komponentti ilmenee vain jonkin tietyn komponentin sisällä, kannattaisi ne mielestäni yhdistää yhdeksi komponentiksi, ja erotella vasta siinä vaiheessa, kun siihen on konkreettinen syy. Joissakin tilanteissa tämä saattaa tietysti johtaa sisennyshelvettiin, eli tämä ei ehkä ole ihan näin suoraviivaista.

Koodisi on varsin kattavasti kommentoitua. Tietyissä kohdissa sanoisin, että siinä on liikaakin kommentteja. Kommenteissa ei kannata kovin tarkkaan selostaa, mitä koodi tekee, koska tällöin on riskinä, että kommentit eivät pysy ajantasaisina koodin muuttuessa. Kommentin puute on yleensä parempi kuin kommentti, joka antaa väärää tietoa. Kannattaa keskittyä kommentoimaan sitä, miksi jokin päätös ollaan tehty, silloin kun tämä ei käy ilmi koodista itsestään. Lisäksi kannattaa tietenkin kommentoida esimerkiksi, millaisia oletuksia jokin funktio tekee argumenttiensa suhteen. Koodissasi esimerkiksi generateAdjacencyList on mielestäni sopivalla tasolla kommentoitu, kun taas dijkstra-funktiota voisi mielestäni kommentoida vähemmän.

Seuraava kommenttini liittyy erityisesti PriorityQueue-luokkaan, joka on ilmeisesti varsin keskeinen osa algoritmejasi. Koska sen metodi enqueue on käsittääkseni varsin aktiivisessa käytössä, kannattaisi se mielestäni toteuttaa tehokkaammin. Yleisen järjestysalgoritmin aikavaativuus on muistaakseni parhaimmillaan $O(n \log n)$, kun taas uuden alkion lisääminen suoraan oikeaan kohtaan jonoa joko lineaarisella haulla tai binäärihaulla ja käyttämällä vaikkapa Javascript-taulukon splice-metodia on (tai ainakin pitäisi olla) aikavaativuudeltaan $O(n)$. Kannattaa harkita myös koko luokan toteuttamista kekona, jolloin enqueue- ja dequeue-metodien yhteiseksi aikavaativuudeksi voidaan muistaakseni saada vielä parempi $O(\log n)$. Tietenkin aikavaativuudet ovat vain suuntaa-antavia, joten ero näiden suorituskyvyissä täytyy mitata konkreettisesti, jos siitä oikeasti välittää.

Lopuksi haluan sanoa, että kirjoittamasi käyttöohjeet yms. ovat hyviä ja hyödyllisiä. Kiitos niistä.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions