Talk:KK without K

From EIK wiki
Revision as of 12:14, 3 June 2013 by Vevainu (talk | contribs) (Created page with '=Meeskond „V“ retsensioon meeskond „KK without K“ teenuse kohta – 3.06.2013= Meeskond KK_without_K on võtnud eesmärgiks luua teenus LanParty haldamiseks, kahjuks …')
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Meeskond „V“ retsensioon meeskond „KK without K“ teenuse kohta – 3.06.2013

Meeskond KK_without_K on võtnud eesmärgiks luua teenus LanParty haldamiseks, kahjuks on teenuse pakkumise eesmärgid wikis väga lühidalt kirjeldatud ning rohkem ei täpsustata. Esmalt tekib kohe küsimus, mis on teenuse skoop, kas vaid kohapeal kohtunike jaoks või ka kasutajate registreerimiseks. Wikis on siiski kirjeldatud kõik teenuse meetodid, millest kahjuks samuti ei loe välja täpsemat skoopi. Teenuse meetodite dokumentatsioonist loeb välja, et teenus võimaldab kasutajate tuvastamist, haldamist, rollihaldust ning samuti mängude, võistluste ja meeskondade haldamist. Dokumentatsioon on hästi struktureeritud.

Teenuse lähtekoodi uurima asudes ilmneb, et teenuse loomisel on kasutatud Entity Framework kood enne lähenemist ning seega on teenuse ja andmekiht selgelt eraldatud. Andmemudeleid uurides jääb silma, et enamus string väljadel on maksimaalne pikkus määratud, kuid mudelite kood võinuks olla paremini struktureeritud, näiteks klassi atribuudid ning viited eraldada. Lisaks on mudelitel enamjaolt puudu niinimetatud navigeerimisväljad, mis on mingil põhjusel välja kommenteeritud. Samuti ei ole kasutatud laiska väärtustamist ning puudub ka võimalus niiöelda virtuaalseks kustutamiseks, sest puudub kustutamise kuupäeva väli. Andmekihi projektis on kasutusel repositooriumite muster ning iga andmemudeli jaoks on loodud oma repositoorium, mis põhineb baas-repositooriumil. Repositoorimite puhul kasutatakse ka korralikult liideseid. Web API teenuses on kasutatud niinimetatud sõltuvuse süstimise mustrit, täpsemalt siis Ninject nimelist lisa.

Controllerites riivab pisut silma repode rohkus ning nende mitte-konstantne nimetamine. Samuti jääb silma „ContestControlleris“ üksiku Contest objekti pärimisel selle alamobjektide täitmine otse kontrolleris, minu arvamusel oleks selleks olnud õige koht repositoorium, kus oleks saanud asja palju elegantsemalt lahendada. Märkata võib ka, et kontrollerid on peamiselt Visual Studio poolt automaatselt genereeritud ning „DbContext“ asendatud repositooriumitega. Viimane teguviis näitab, et tuntakse Visual Studiot ning keskenduti vajalikule, kuid samas on ka siit tulenevaid kummalisi koodiosi. Näiteks Contest objekti pärimisel päritakse see esmalt repositoorimist ja seejärel täidetakse selle alamobjektid (Games, Teams jms), selles täitmisest edasi on aga kontroll „if(contest == null)“.

„LoginController“´is on samuti näha, et parooli hashimine, et võrrelda seda andmebaasis oleva hashitud parooliga, on samuti otse kontrolleris ja oleks võinud olla paigutatud repositooriumi. Hea külg asjal on, et paroole üldse hashitakse, seega on nende hoidmise turvalisusele mõeldud. Küll aga tekib küsimus miks ei kasutata .net raamistiku poolt pakutavaid autentimise vahendeid täielikult ära. Kasutatud on küll rollide haldamist, kuid rolle lisada ei ole võimalik ning rollidesse lisamine toimub hetkel kasutajanime alusel : „if (user.UserName != "Karhu") Roles.AddUserToRole(user.UserName, "User"); else Roles.AddUserToRole(user.UserName, "Admin");“. Samuti ei ole teenuse poolel kuskil näha teenuse piiramist vastavalt rollile. Kasutatud on osaliselt ka sisseehitatud kasutajahaldust, kuid samas on kasutajate info dubleeritud ka teenuse autorite poolt genereeritud andmebaasi ja klassidesse.

Teenuse poolelt on puudu ka turvaline ühendus (sertifikaatidega) ja kasutajate päringute/tegevuste logimine ning sellele vastavalt teenuse kasutamise piiramine. Seetõttu jääb selle osa retsenseerimine puudu. Samuti jääb mitmes kohas silma väljakommenteeritud koodi ning üldine ülesehitus on kohati häiriv. Samas on võimalik Wiki logist välja lugeda, et teenus on välja töötatud enamjaolt 7 päeva jooksul. Mis iganes põhjused autoritel sellele porjektile suhteliselt vähese aja pühendamiseks olid,siis lühikese aja kohta hindaksin ise saavutatut siiski päris heaks, kuid kulunud aega mitte arvestades oleks autoritel veel tükk tööd, et jõuda asjaliku teenuse pakkumiseni.

Meeskond "V"

Meeskond „V“ retsensioon meeskond „KK without K“ klientrakenduse kohta – 3.06.2013

Meeskond on loonud WPF rakenduse, mis kasutab nende endi loodud Web API teenust. WPF rakenduses on hea tava kasutada MVVM (Model-View-ViewModel) mustrit, millest on C# programmeerimise aines korduvalt räägitud. Antud WPF rakenduses aga MVVM mustrit järgitud pole, mis on suureks miinuseks.

Rakenduse kihtideks jaotamisest tundub olevat tehtud niipalju, et vaated ja kollektsioonid on pandud eraldi kausta. Esmapilgul jääb arusaamatuks miks kollektsioonide jaoks on tehtud eraldi klassid, kuid lähemal uurimisel selgub, et igale kollektsioonile, antud kaustas, on lisatud üks meetod „CopyFrom“, mis võtab sisendiks „IEnumerable<T>“ tüüpi listi ja tõstab sellest ükshaaval T objektid „ObservableCollection<T>“ tüüpi listi ümber, siinkohal T on kindel tüüp ning iga rakenduses oleva tüübi kohta tundub olevat eraldi kollektsioon. Siinkohal oleks kindlasti võinud kasutada üld-klassi ehk niinimetatud „Generic“ tüüpi. Tagasi põhjuse juurde, miks rakenduse autorid on teinud, siis jääb mulje, et põhjuseks ongi „IEnumerable" tüüpi listi sisu kopeerimine „ObservableCollection“ sisse, millele ei ole vist muud lahendust leitud. Lahenduseks oleks olnud ka märksa lihtsam kood: „ObservableCollection<T> list = new ObservableCollection<T>(Siia IEnumerable tüüpi list);“, mille võib leida kiirelt google abiga.

Leidnud, et kollektsioonid on tegelikult antud rakenduses üleliigsed siis teine eraldamine ehk vaadete eraldi kausta panemine on igati hea otsus. Vaateid lähemalt uurides selgub, et nende visuaalne pool on üles ehitatud väga korrapäratult, jääb mulje, et elemendid on enamjaolt lihtsalt paika lohistatud ja suurus samuti hiirega paika tõmmatud. Leidub mõni üksik näide StackPanel´i kasutamisest, kuid oleks WPF rakenduse vaate disainimisel oodanud Grid´i kasutamist. Antud juhul on sellise XAML koodi tulemusel disaini muutmine tulevikus kohmakas ning aeganõudev. Positiivse poole pealt, vaadetes on kasutatud sidumist ehk „Binding“. Lisaks vaadete kaustas olevatele vaadetele on veel põhivaated. Põhivaates on näha taas sidumise kasutamist, kuid jällegi on XAML elementidest alakasutatud Grid võimekust ning selle asemel pistetud elemendid StackPaneli sisse. Autorid on kasutanud erinevate vaadete jaoks TabControl elementi mille tulemusel on kõikide vaadete kood ühes XAML failis. Koodi parema loetavuse mõttes oleks võinud iga vaate koodi tõsta siiski eraldi faili ja TabControl elemendis neile viidata. Põhivaated on samuti dubleeritud, eraldi vaatefail tavakasutaja ja administraatori jaoks. Siinkohal oleks võinud kindlasti mõelda koodi taaskasutuse peale, kuid mingil põhjusel on autorid läinud teist teed.

Vaadates teenusega suhtlemist, siis positiivne on, et on kasutatud baasaadressi lisamist ning koodis kutsutakse välja vaid kindel kontroller, mitte ei trükita igalpool täispikka aadressi. Ebamugav on aga vaadata vaadetes korduva struktuuriga proovi-püüa ehk „Try-Catch“ lauset, mille oleks võinud kindlasti viia eraldi meetodite klassi ning ehk isegi kasutada „Generic“ tüüpi, et koodi taaskasutada.

Rakendust käivitades ja natuke testides ilmneb, et mõnes kohas on tehtud ka kontrollid, et rakendus kokku ei jookseks. Näiteks antakse veateadet, kui üritatakse ühtki mängu valimata mängu redigeerima hakata. Kuid kahjuks ei ole veahaldusega ning veateadetega eriti kaugele jõutud. Rakendust natuke uurides tekib probleeme mängu lisamisega, sest mängu lisamiseks on tarvis valida ka mängu žanr, kuid viimast ei ole võimalik rakenduses endas lisada või vähemalt minul ei õnnestunud antud kohta leida. Žanri taha jääb kinni mängu lisamine, viimase puudumisel takerdub ka võistluse loomine ning nende kahe puudumisel ei ole ka meeskondadel mingit mõtet.

Kokkuvõttes on tegemist kasutuskõlbmatu rakendusega, milles on küll võimalik autorite endi poolt loodud teenust kasutatud, kuid mitte täisväärtuslikult. Kood on rakenduses samuti halvasti loetav, sest puudub korralik struktuur. Oodates retsenseerimisest ka millegi uue õppimist, siis antud juhul pidin kahjuks pettuma.

Meeskond "V"