Difference between revisions of "Talk:Miisiiks"

From ICO wiki
(Created page with "Klientrakendust ja veebiteenust retsenseerib meeskond MOT")
 
Line 1: Line 1:
 
Klientrakendust ja veebiteenust retsenseerib meeskond MOT
 
Klientrakendust ja veebiteenust retsenseerib meeskond MOT
 +
 +
 +
 +
 +
 +
=Veebiteenuse retsensioon meeskonnalt RaamatuRiiul=
 +
 +
Meeskond Miisiiks on teinud projekti juhutööde pakkumise ja otsimise jaoks. Inimesed saavad vaadata ja lisada juhutöö otsimise ning pakkumise kuulutusi.
 +
 +
Esimese asjana panime tähele, et puudub README fail, kust saaks lugeda tutvustust projekti kohta ja seda, kuidas projekti tööle panna ning mida projekti tööle panemiseks vaja on. Antud aine kontekstis on küllaltki selge, kuidas midagi kasutada, aga laiemas plaanis vaadates oleks oluline see kirja panna.
 +
 +
Domeenimudelis on piisav arv olemeid, et täita kodutööks ettenähtud tingimused. Domeeni klassid on selged, hea ülesehitusega, väga põhjalikult kommenteeritud (millegi pärast on küll jäänud JobCategory kommenteerimata). Mudelite puhul on kasutatud korrektselt annotatsioone - enamik väljadele määratud korrektselt pikkused, kuid on ka mõned, millele on pikkus määramata jäänud, näiteks ContactType puhul string ContactTypeName on ilma pikkuse määranguta. Paika on pandud ka kohustuslikud väljad ja välisvõtmed. Meeldib, et osa domeeni klasside puhul on jagatud klass regioonide abil mitmeks osaks. Domeenimudelites on selgelt näha olemite vahelised seosed. Mudelites ühtegi sisulist viga ei leidnud.
 +
 +
Projekt on hästi struktureeritud, arhitektuuriliselt on kasutatud kihte. Kood on jaotatud eraldi BL, DAL, Domain ja WebAppi vahel. Kogu projektis on läbivalt klassidel ühtne kirjutamisstiil ja kaustade jaotus on loogiline ja kood on lihtsasti hoomatav.
 +
 +
DAL on jagatud neljaks erinevaks osaks ja need on tehtud väga põhjalikult. DAL’is on kasutatud repositooriume ja Unit Of Worki. Repositooriumite puhul on hea, et on tehtud universaalne repositoorium, mida teised kasutavad ja sellega lihtsustatakse oluliselt koodi. BL all asuvad DTO’d, Factorie’d, Interface’d, Service’d. Service’te puhul on kasutatud Unit Of Worki ja Factory’eid.
 +
 +
Veebiteenust käima pannes ja toimimist katsetades märkasime, et niisama ei saa ligi kõikidele api kontrolleritele. Uurisime api kontrollerite koodi lähemalt ja nägime, et osa neist on kaitstud kasutaja autentimisega. Kuna README fail on puudu, siis ei leidnud ka infot, mismoodi neid kasutada üldse saaks. Võtsime ühendust projekti autoritega ja saime teada, et tuleb kasutajaga sisse logida ja siis saab nendele apidele ka ligi.
 +
 +
API puhul leidsime mitmeid asju, mis ei tööta ootuspäraselt. Post on ainult asünkroonne, Get ja GetById on mingil põhjusel mitte asünkroonsed. Hetkel saab mitmeid asju lisada suvaliselt, näiteks kui reklaami lisada, siis saab suvalist kasutajanime panna, kui just ei ole sisse logitud mõne teisega. Muutmise puhul on jällegi ilusti kontrollitud, kas on ikka õige kasutaja. Sama probleem on ka AdvertisementPicture puhul – saab lisada suvalise kasutaja reklaamile pilte. Järgmiseks avastasime, et AdvertisementDTO sees on UserName ja seda saab täiesti avalikult GetAll’ida, mis ei tohiks aga nii olla. Segaseks jäi ka see, et miks on reklaamide saamine ApplicationUser kontrolleris.
 +
Täitsa hästi on tehtud Contacts kontroller, eriti GetAllContacts. Seal tagastab automaatselt ainult need kontaktid, mis kuuluvad hetkel autoriseeritud kasutajale ja see on väga hea. Id järgi ei kontrollita aga, et kontakt, mida küsitakse, kuuluks kasutajale. Samuti probleemne koht on see, et lisada saab kontakti suvalisele kasutajale.
 +
 +
Projekti visioon on kergelt segane, ei tule hästi välja. Vaatasime, et JobCategory vajalikkust me ei mõista, seda ei kasutata justkui kuskil. Sõnumite kohta võib positiivsest küljest öelda, et saadetud ja kätte saadud sõnumid on ilusti turvaliseks tehtud, aga halb on jälle see, et Id järgi turvalisust tehtud ei ole. Sõnumeid saab millegi pärast lisada suvaliste inimeste vahele. Kui sõnumeid kustutada, siis sõnum kustub ära nii sõnumi saatjalt kui saajalt, võimalik, et see ongi tahetud nii teha, aga tasuks võib-olla üle mõelda. Lisaks vaatasime, et IDE ütleb, et Message Delete ei kontrolli tegelikult kasutaja identiteeti. Konto loojal on ebapiisav tagasiside, vähemalt parooli keerukuse kohapealt.
 +
 +
Meie meelest oleks võinud Security kontrolleri sisu Service’i all olla, aga see pigem maitse küsimus. Projektile on lisatud Swagger. Muidu kõik töötab ilusti, aga Swagger on täielikult kommenteerimata.
 +
Paremaks testimiseks oleks meeldinud, et programmi esmasel käivitusel ka mõned andmed andmebaasi juba lisataks. See pole aga otseselt vajalik, igaüks saab ka ise lisada ja siis testida. Põhilised ContactType’d oleks võinud juba näiteks lisatud olla.
 +
 +
Kokkuvõtvalt jäi meile tööst üsna hea mulje, vaeva on nähtud, kuid tundub, et tööde jaotusega on osa meetodid poolikuks jäänud. Paljud asjad on aga väga hästi ja korralikult tehtud.
 +
 +
 +
Retsenseeris meeskond: [https://wiki.itcollege.ee/index.php/RaamatuRiiul RaamatuRiiul]

Revision as of 22:43, 3 June 2018

Klientrakendust ja veebiteenust retsenseerib meeskond MOT



Veebiteenuse retsensioon meeskonnalt RaamatuRiiul

Meeskond Miisiiks on teinud projekti juhutööde pakkumise ja otsimise jaoks. Inimesed saavad vaadata ja lisada juhutöö otsimise ning pakkumise kuulutusi.

Esimese asjana panime tähele, et puudub README fail, kust saaks lugeda tutvustust projekti kohta ja seda, kuidas projekti tööle panna ning mida projekti tööle panemiseks vaja on. Antud aine kontekstis on küllaltki selge, kuidas midagi kasutada, aga laiemas plaanis vaadates oleks oluline see kirja panna.

Domeenimudelis on piisav arv olemeid, et täita kodutööks ettenähtud tingimused. Domeeni klassid on selged, hea ülesehitusega, väga põhjalikult kommenteeritud (millegi pärast on küll jäänud JobCategory kommenteerimata). Mudelite puhul on kasutatud korrektselt annotatsioone - enamik väljadele määratud korrektselt pikkused, kuid on ka mõned, millele on pikkus määramata jäänud, näiteks ContactType puhul string ContactTypeName on ilma pikkuse määranguta. Paika on pandud ka kohustuslikud väljad ja välisvõtmed. Meeldib, et osa domeeni klasside puhul on jagatud klass regioonide abil mitmeks osaks. Domeenimudelites on selgelt näha olemite vahelised seosed. Mudelites ühtegi sisulist viga ei leidnud.

Projekt on hästi struktureeritud, arhitektuuriliselt on kasutatud kihte. Kood on jaotatud eraldi BL, DAL, Domain ja WebAppi vahel. Kogu projektis on läbivalt klassidel ühtne kirjutamisstiil ja kaustade jaotus on loogiline ja kood on lihtsasti hoomatav.

DAL on jagatud neljaks erinevaks osaks ja need on tehtud väga põhjalikult. DAL’is on kasutatud repositooriume ja Unit Of Worki. Repositooriumite puhul on hea, et on tehtud universaalne repositoorium, mida teised kasutavad ja sellega lihtsustatakse oluliselt koodi. BL all asuvad DTO’d, Factorie’d, Interface’d, Service’d. Service’te puhul on kasutatud Unit Of Worki ja Factory’eid.

Veebiteenust käima pannes ja toimimist katsetades märkasime, et niisama ei saa ligi kõikidele api kontrolleritele. Uurisime api kontrollerite koodi lähemalt ja nägime, et osa neist on kaitstud kasutaja autentimisega. Kuna README fail on puudu, siis ei leidnud ka infot, mismoodi neid kasutada üldse saaks. Võtsime ühendust projekti autoritega ja saime teada, et tuleb kasutajaga sisse logida ja siis saab nendele apidele ka ligi.

API puhul leidsime mitmeid asju, mis ei tööta ootuspäraselt. Post on ainult asünkroonne, Get ja GetById on mingil põhjusel mitte asünkroonsed. Hetkel saab mitmeid asju lisada suvaliselt, näiteks kui reklaami lisada, siis saab suvalist kasutajanime panna, kui just ei ole sisse logitud mõne teisega. Muutmise puhul on jällegi ilusti kontrollitud, kas on ikka õige kasutaja. Sama probleem on ka AdvertisementPicture puhul – saab lisada suvalise kasutaja reklaamile pilte. Järgmiseks avastasime, et AdvertisementDTO sees on UserName ja seda saab täiesti avalikult GetAll’ida, mis ei tohiks aga nii olla. Segaseks jäi ka see, et miks on reklaamide saamine ApplicationUser kontrolleris. Täitsa hästi on tehtud Contacts kontroller, eriti GetAllContacts. Seal tagastab automaatselt ainult need kontaktid, mis kuuluvad hetkel autoriseeritud kasutajale ja see on väga hea. Id järgi ei kontrollita aga, et kontakt, mida küsitakse, kuuluks kasutajale. Samuti probleemne koht on see, et lisada saab kontakti suvalisele kasutajale.

Projekti visioon on kergelt segane, ei tule hästi välja. Vaatasime, et JobCategory vajalikkust me ei mõista, seda ei kasutata justkui kuskil. Sõnumite kohta võib positiivsest küljest öelda, et saadetud ja kätte saadud sõnumid on ilusti turvaliseks tehtud, aga halb on jälle see, et Id järgi turvalisust tehtud ei ole. Sõnumeid saab millegi pärast lisada suvaliste inimeste vahele. Kui sõnumeid kustutada, siis sõnum kustub ära nii sõnumi saatjalt kui saajalt, võimalik, et see ongi tahetud nii teha, aga tasuks võib-olla üle mõelda. Lisaks vaatasime, et IDE ütleb, et Message Delete ei kontrolli tegelikult kasutaja identiteeti. Konto loojal on ebapiisav tagasiside, vähemalt parooli keerukuse kohapealt.

Meie meelest oleks võinud Security kontrolleri sisu Service’i all olla, aga see pigem maitse küsimus. Projektile on lisatud Swagger. Muidu kõik töötab ilusti, aga Swagger on täielikult kommenteerimata. Paremaks testimiseks oleks meeldinud, et programmi esmasel käivitusel ka mõned andmed andmebaasi juba lisataks. See pole aga otseselt vajalik, igaüks saab ka ise lisada ja siis testida. Põhilised ContactType’d oleks võinud juba näiteks lisatud olla.

Kokkuvõtvalt jäi meile tööst üsna hea mulje, vaeva on nähtud, kuid tundub, et tööde jaotusega on osa meetodid poolikuks jäänud. Paljud asjad on aga väga hästi ja korralikult tehtud.


Retsenseeris meeskond: RaamatuRiiul