AmateurBB
Meeskond AmateurBB
Liikmed: Taavi Kivimaa
Loodav rakendus
Rakenduse idee on luua andmebaas, mis hoiab endast korvpallimängude tulemusi ja teeb nende põhjal liiga-tabeli.
Rakenduse funktsionaalsus
- Rakenduses saab luua mänge ja tulemusi
- Rakendus võimaldab mängudele lisada ka kohta, kohtuniku
- Erinevad rollid, millega saab mängude tulemusi kinnitada
- Siduda meeskondi mängijatega
- Vaadata teiste meeskondade kohta infot
- Luuakse automaatne liigatabel mängu tüübi põhjal
- Näeb teiste meeskondade inimesi ja kontakte, et mängu luua
Skoobist hetkel väljas:
Mängijate statistika (punktid, korvid jne).
Kasutajarollid:
- Liiga-Admin(Saab lisada teistele kõrgemaid rolle, luua liigatabel).
- Treener(saab lisada meeskonda mängijaid ja kinnitada mänge ja tulemusi)
- Kohtunik(Saab mängude tulemusi kinnitada)
- Tavakasutaja (ei oma erilisi õiguseid, saab välja paista meeskonna nimekirjas).
Andmemudel:
XML
XML: Lae XSD: Lae XSLT relations: Lae XSLT rich/poor Lae
Retsensioon
Retsensioon veebiteenusele tiimile BeerPressure (TäisKõht api)
Retsensioon Tiimile TäisKõht Kõige pealt alustasin DTO’de vaatamist. DTO objektid olid üldiselt kenasti üles ehitatud - meeldis ka see, et teisendused DTO ja domeeniobjektide vahel olid lisatud statilise meetodina otse DTO klassidesse, et ei tehtud lisa klasse selle jaoks. Kenasti olid olemas ka MaxLength atribuudid, küll aga olid nii DTOs kui domeeniobjektides puudu required annotatsioonid, mis teevad nad baasis nullable ja ka sisse võib tulla täiesti tühi objekt, mis on kergemini erroritele vastuvõtlik ja peab null-safeks tegema servicites, selle asemel, et Kohe controllerites viga visata päringu peale. Klappisid ka DTO ja domeeniobjektides andmete max lengthid. Oli ära kasutatud ka ühe domeeniobjekti vastu erinevaid DTOsid (näiteks RestaurantDTO), et sai vajadusel saata välja ka erinevat sisu. Kui asja vähekene paremaks teha, oleks võinud panna baas-restaurant DTO ja siis seda extendida erinevate väljadega, mis nende DTO klasside vahel erinesid. Küll aga oli sama loogika olemas ka näiteks Restaurant factorys, mis samamoodi buildis DTOst domeeniobjekti ja vastupidi. Lisaks sellele oli nii interface kui ka implementatsioon ühes failis - ma ei oska nüüd hinnata, kas see on hea või mitte, aga üldiselt peaks minu teada olema parem tava neid eraldi failides hoida. Siis oli veel factory põhimõttel tehtud Helper kaust kus oli üks helper klass, mis tegi ratinguid. Selle oleks võinud ka iseenesest panna factorysse, kuna teeb sisuliselt sama asja ära. Aga see idee/mõte oli väga hea. Serviced olid see-eest interfaced ja implementatsioon eraldi klassides, mis täidab paremini ära interfacede mõtte. Serviced olid üldjoontes hästi üles ehitatud ja üsna puhtad. Vahepeal on märgata natuke liigset keerukust, näiteks üks for loop teise for loopi sees. Selleks oleks võinud luua mõned private meetodid, mis teevad teatud loogikat ära. Kohati võiks parema loetavuse huvides olla rohkem vahesid ridade vahel loogilistes kohtades. Aga muus osas on küllaltki hästi loetav. Ning koodi ühtlus on ka natuke erinev - aga see on ilmselt lihtsalt eri arendajate poolt tehtud. (näiteks ühes kohas on Arrays.ForEach(list, item => …) ja teises kohas list.ForEach(item => … ). Koodis meeldis üldiselt meetodite nimetamine, üsna selged ja arusaadavad ja teevad seda, mis meetodi sisus toimub. Mõnes csproj. Failis on dependencid paigast ära (relatiivne asukoht). Repositoryd paistavad, et on suuremalt jaolt tehtud nii nagu loengutes ja praktikumides õpetati, et seal on kasutus nii nagu peaks olema ja ma usun et väga korralikult tehti. Muus rakenduse osas paistab et on ka üsna sarnaselt tehtud nagu loengutes ja praktikumides räägitud on, kenasti on olemas security context ja JWT koostamine, Swagger on olemas ja swaggerile on oma konfiguratsioon pandud, JWT kohta käivat infot loetakse ka properties failist sisse ning üldiselt rakenduse püstipanekuga paistab kõik kenasti. Mõnes kohas on kasutusel nii vanad kui uued dependencied korraga (nt AspNetCore.Identity ja AspNet.Identity), selle asemel võiks kasutada ainult AspNetCore dependenceid, kuna need tekitavad ka pikemaid objekti klasse. Controllerites paistab et on kah kõik kenasti ära kommenteeritud swaggeri jaoks ja tagastatakse vastavalt olukorrale ka õiged http status koodid. Üldiselt ma hindaks seda tööd väga heaks, kõik vajalikud asjad on olemas, koodi arhitektuur on selge ja arusaadav, kommenteeritud on parajalt (mulle ei meeldi liigselt kommenteeritud kood), meetodite nimetused klapivad sisuga, koodi on hästi loetav ja on korralikult formatitud failid. Siit-sealt annaks natukene loetavust ja koodi kvaliteeti parandada, aga ma arvan et kuna siin keegi projekti jaoks pull-requeste üle ei vaadanud, siis meeskonnana ühtlaselt on töö väga hea.
