Talk:DevHelpVR

Retsensioon projektile DevHelpVR

Sissejuhatus

Retsensiooni eesmärgiks oli võrrelda püstitatud ülesannet lõpptulemusega ning analüüsida esmalt veebiteenuse poolt, kasutatud andmemudeleid, mustreid ning koodi jälgitavust ehk visuaalset poolt. Teiseks tuli analüüsida ka kliendirakendust, mis eesmärgipäraselt peaks suhtlema loodud veebiteenusega. Retsensiooni käigus hindasime veebiteenuse ja klientrakenduse osas vastavalt järgmiseid nüansse:

1. Andmebaasi olemite arv

2. Kastutatav tehnoloogia (WCF või ASP.NET MVC Web API)

3. Veebiteenuse olemasolu

4. Mitmekasutaja funktsionaalsuse olemasolu

5. Kasutajate tuvastamist ja haldamist

6. Kasutusstatistika üle arve pidamist

7. Piirangute olemasolu pöördumiste arvu osas ning nende haldust

8. Kasutusjuhendi olemasolu

9. Klientrakenduse tehnoloogia, ülesehitus ja kasutusmugavus

Andmemudel, olemid

Projekti eesmärgiks oli luua rakendus, mis aitaks arendajal oma töid paremini planeerida ja omada ülevaadet käimasolevatest ning järgmisena algavatest ülesannetest. Projekti andmemudel on ilusti üles ehitatud, kuid võrreldes esialgu planeerituga esineb erinevus olemite koguarvus, samas on põhifunktsionaalsus kenasti olemas. Andmebaasi olemite arv, ilma Identity olemiteta, on 10 (esialgses analüüsidokumendis saime neid kokku 16). Analüüsi käigus ei suutnud tuvastada ühtegi suurt viga, küll aga saaksime teha mõned soovitused. Nimelt enamik olemeid, milles esineb nn algus ja lõppaeg, võiks lõppaja väli olla pigem valikuline, kuna alati ei pruugi projektil, meeskonnal või muul olemil olla teada lõppaeg selle objekti sisestamisel - ehk et see võib selguda alles peale mõningast analüüsi. Lisaks, tõenäoliselt tähelepanuta jäänud, on UserStory olemi Storypoints attribuudil annotatsioon [Required]. Seda aga tegelikult vaja pole, kuna int on väärtustüüpi muutuja ja nõuab vaikimisi väärtust. Kolmanda soovitusena võiks mainida ka seda, et tegelikult saaks edukalt ära kasutada ka Identity-ga kaasa tulevaid olemeid näiteks rollide ja kasutajate kirjeldamiseks.

Välja võib tuua seda, et kõik olemid ja seosed on hästi läbimõeldud, kasutatud on piisavalt annotatsioone ja kõik viitetüüpi olemi atribuudid on sobivalt piiratud (eelkõige string muutujad).

Kasutatav tehnoloogia ja veebiteenuse olemasolu

Projekt on ülesehitatud kasutades ASP.NET MVC Web API tehnoloogiat nii, nagu kirjas ka õppejõu poolt antud projekti nõuetes. Rakenduse ülesehitus on hajutatud, mis tähendab, et andmekihid on üksteisest eraldatud ja kogu andmevoog on hästi jälgitav ning lihtsasti muudetav. Eraldi asuvad mudelid, äriloogika kiht, teenused ning kontrollerid ja klientrakendus. Kontrollerite ülesehitus on loogiline - iga ärilise funktsionaalsuse kohta on oma kontroller - eriti jääb silma ja peab siin ära märkima kommentaarid, mis aitavad selgemalt aru saada kontrolleri taustast. Andmevoog liigub nagu raamatus :), kontrollerist teenusesse ja sealt edasi kasutatakse Unit of Work ja Repository mustreid, mis aitab kindlasti jõudlusele kaasa. Kokkuvõtvalt on veebiteenus hästi ülesehitatud, kuid silma jäi ja välja võiks tuua ehk selle, et mitte kõik kontrollerid ei tagasta vea korral 404 veateadet.

Kasutajate tuvastamine, haldus, mitmekasutaja funktsionaalsus, statistika

Teenus on ülesehtitatud kasutades Asp.Net enda Identity moodulit, mistõttu toetab see mitmekasutaja funktsionaalsust ja kasutajate hallatavust. Võib näha, et esialgne andmemudel oli planeeritud kasutama iseseisvat kasutajate andmemudelit ja nii on see ka teostatud. Küll aga on lisandunud seos AspNetUsers tabelile, kui kasutaja registreeritakse ja hilisemate mõningate teenuste puhul. Parendusettepanekuna, nagu eelpool mainitud, võiks selle tulevikus viia ühtse mudeli peale, oleks kokkuvõttes lihtsam koodi hallata. Kontrolleris kasutatakse teenusetarbijate autentimist, mistõttu on raskendatud juurdepääsu mitteomavate kasutajate süsteemi sisenemine. Lisaks on rakendatud ka autoriseerimist, mis omakorda piirab juurdepääsu omavatel süsteemi kasutajatel üksteise sessioonide kuulamise ja andmelekke tekkimist. Iga päringu tegemiseks kasutatakse sisselogimisel saadud tokenit, mis võimaldab eelpool toodut rakendada. Nõuetekohaselt salvestatakse statistikat kasutaja tegevuste kohta, mis kokkuvõttes on kindlasti hea nii kasutajale endale oma protsesside optimeerimiseks kui ka eelkõige rakenduse arendusmeeskonnale erinevate tegevuste optimiseerimiseks. Küll aga leidsime ühe vea, kus kõigil kasutajatel on võimalik näha kõiki sisestatud projekte, see aga ei oleks ka ettevõttesiseselt ehk alati otstarbekas, ja tasuks kindlasti üle vaadata ning muuta kui soovitakse rakendust ka SaaS mudeli alusel müüja.

Klientrakenduse tehnoloogia, ülesehitus ja kasutusmugavus

Pealkiri 13

Lõpptoote retsensioon meeskonnalt PC KartKicker

Veebiteenus

Domeenimudelid

Veebiteenuse domeenimudelid on kirjeldatud üsna põhjalikult ja meeldib, et mõistlikes kohtades on kasutatud annotatsioone – näiteks piiratud stringi pikkused ja lisatud required väljad kuhu vaja. Mudeleid on kokku kümne ringis, mis viitab sellele, et projekt tundub nõudeid arvestades paraja suurusega. Lisaks on leidub eraldi kaust, kus on realiseeritud Enum’itena erinevad fikseeritud skaalaga väljad. Veel torkab silma, et kasutatakse Lazy Loading’ut, mis antud rakenduse suuruse juures pole võib-olla kõige vajalikum. Samuti võib see tulevikus raskendada rakenduse üle viimist ASP.NET Core’i peale, mis seda ei toeta. Natukene häirivad mõned mitu-mitmele seoste tulemusel tekkivate olemite nimetused – näiteks User_DevTeam või User_Project. Võib-olla oleks silmale veidi ilusam neid ilma alakriipsuta kirjutada, kuid see on paljuski isiklik eelistus. Kokkuvõtvalt aga peab mainima, et mudelid tunduvad hästi läbi mõeldud ning siinkohal on etteheiteid teha raske.

Andmebaas ja repositooriumid

Arhitektuuri osas on kasutatud Repository pattern’it db-contexti vastu, samuti Unit of Work pattern’it, mis koondab enda alla repositooriumid. Kiita saab seda, et Helpers kataloogis on DbInitializer, mis teeb konkreetset koodi mittetundvale inimesele rakenduse järgiproovimise lihtsaks (ei pea ise dummy data’t genereerima, vaid saab kohemaid sisusse süveneda). Repositooriumite osas torkab silma, et need on enamjaolt tühjad (peale UserRepository), kuid UOW-s registreeritakse need custom repositooriumitena. Loomulikult võib need tuleviku arendusi silmas pidades valmis ära teha, kuid siis pole suurt mõtet neid veel eraldi Dictionary-sse registreerida vaid kasutada UOW-s standardsetena. Iga repositooriumi vastu on kirjutatud eraldi Interface, nii repositooriumid, kui Interface’id kasutavad baasmudelit (vastavalt EFRepository ja IRepository), millest nad pärinevad.

Äriloogika

Kontrollerid suhtlevad antud juhul service layer’iga ja kasutatakse DTO-sid koos factory pattern’iga. DTO-d tunduvad kõik domeenimudelitega identsed ja on seega ilmselt valmis tehtud just tulevikku silmas pidades. Kontrollerites on realiseeritud enamjaolt CRUD meetodid, mis kasutavad DTO-sid, kuid väga palju spetsiifilisi lahendusi realiseeritud ei ole. Kontrolleritele võiks vaid nii palju ette heita, et ei kasutata asünkroonset lähenemist, mis teeks rakenduse tulevikus veelgi skaleeritavamaks. Samas, nii repositooriumid kui kontrollerid on õiges kohas ja õigesti üles ehitatud ning kõik tundub ilusasti töötavat. Kasutajate haldus kasutab Entity Framework-i enda ApplicationUser’it, seega aine baas-repositooriumis välja pakutud custom Identity lahendust ei ole siinkohal realiseeritud (mis ei olnud ka ise-enesest eraldi nõue).

Kokkuvõte

Teenuse juures torkab silma, et meeskond tunneb hästi arhitektuurilisi võtteid, kuidas veebirakendusi loogiliselt üles ehitada. Kuigi rakendus praeguses mahus kõiki neid kihte veel ei vaja, annab see võimaluse tulevikus teenust lihtsasti skaleerida, kuna kihid on juba algusest saati ilusasti paigas. Sellest annab ka tunnistust see, et näiteks DTO-de ja domeenimudelite väljad hetkel kattuvad, kuid tulevikus on lihtsasti võimalik teha andmebaasis muudatusi ja täiendusi ilma neid kliendile kohe välja näitamata. Kood on enam-vähem korralikult kommenteeritud, kuid mõndades kohtades jäi silma pikk doctype kommentaaride rida, mis oli kirjutatud Eesti keeles. Kuna Visual Studio genereerib uut rakendust tehes ka palju ingliskeelseid kommentaare, võiks kaaluda ühtse stiili kasutamist ning vältida eestikeelset teksti koodi vahel. Kokkuvõtvalt tuleb meeskonda kiita tubli töö eest. Teenus on väga korralikult üles ehitatud ning järgib paljusid mustreid, mis on täna tõsiseltvõetavate rakenduste tunnuseks. Kuigi sellise mahuga rakenduse võiks kirjutada vabalt ka ilma UOW vahekihita, näitab selle kasutamine teatavat vilumust ning teeb teenuse juures tulevikus muudatuste tegemise lihtsamaks. Arvestades, et meeskonnas oli vaid kaks liiget, väärib see projekt kindlalt maksimumpunkte!

Klientrakendus

Arhitektuur

Klientrakendus on realiseeritud Windows Application’ina ning asub samas solution’is. Klientrakendus kasutab samu domeenimudeleid ning samuti on olemas Enum’ite kaust fikseeritud skaalaga väljade jaoks. Nii nagu teenuse osas, häirivad veidi silma alakriipsuga deklareeritud väljad (nt. User_UserStoryStart), kuid see on jällegi puhtalt stiili küsimus. Domeenimudelid suhtlevad API-ga tokenite abil, mis initsialiseeritakse konstruktoris. Samuti on olemas vaatemudelid, mis pärinevad baas vaatemudelist BaseVM, mis on põhimõtteliselt event handler. Vaated näevad välja nagu nad out of the box on - eristuvat disaini ei ole siinkohal märgata. Samas on see arusaadav, kuna projekti maht oli niigi suur ja põhifookus lasus funktsionaalsuse realiseerimisel. Eraldi on olemas service layer, mille ülesandeks on andmete edastamine API vastu. Iga domeenimudeli jaoks on eraldi service, mis pärineb baas service’ist. Mõne viewmodel’i puhul jäi silma, et see kasutab väga palju service klasse (näiteks DevTeamVM kasutab viite service’it). Siinkohal oleks võinud kaaluda teha lisaabstraktsioon, mis koondaks enda alla service-id. Idee poolest võiks see olla nagu UOW (Unit of Work), mida saaks süstida vaatemudelitesse, et need võiksid kasutada kõiki vajaminevaid service klasse. Teisalt ei ole projekti maht niivõrd suur ja see võib vabalt jääda ka tulevikuks.

Funktsionaalsus

Rakendust avades kuvatakse kõigepealt sisselogimise aken, kust on konto puudumisel võimalik kohe ka uus kasutaja registreerida. Peale registreerimist võiks kuvada lisaakna, millega kinnitada kasutajale, et registreerimine tõepoolest õnnestus. Praegu suunatakse lihtsalt tagasi sisselogimise aknasse. Peale sisselogimist avaneb “põhiaken”, kus saab kasutada juba põhifunktsionaalsust - siduda kasutajat projektide ja arendusmeeskondadega, projektidele lisada iteratsiooni ning iteratsioonidele kasutajalugusid. Nii projekte, kasutajalugusid kui iteratsioone saab sealjuures eraldiseisvalt kustutada ning ülemkategooria kustutamisel kaovad ka alamüksused (cascade delete). Siin tuleb selgelt välja, et domeenimudelid on läbimõeldud ning lisatud vajalikud väljad. Samas ei ole “surnud” välju, mida kuskil ei kasutata ja mis niisama objekti küljes on. Lisaks on võimalik vaadata statistikat ning muuhulgas jälgitakse ka kasutajate sisselogimiste arvu (teatavasti oli sisselogimiste arvu piiramine ka üks projekti nõuetest).

Kokkuvõte

Klientrakendus on korralikult kirjutatud ning arvestades tervet projektimahtu ei ole sellele palju ette heita. Disaini osas oleks võinud mõelda klienti realiseerida siiski veebirakendusena, kasutades näiteks AngularJS-i veebiraamistikuna. Samas võib omast kogemusest öelda, et kindlasti ei ole see ajasäästlikum tee, kui tehnoloogiad hästi ei valda (arvestades, et aine raames Angularist väga mida rääkida ei jõutud). Selle tulemusena oleks saanud disaini ka veidi parema teha, kuid kõige tähtsam on siiski funktsionaalsuse realiseerimine, mis õnnestus väga hästi ja mille eest tuleb meeskonda kiita. Ükski lahendus ei tundu poolik, ning kõik on suures plaanis läbi mõeldud. Siit jääb kuvama ka tõsiasi, et see projekt on tegelikult edasiarendus C# aines kirjutatud projektile ning võib arvata, et seetõttu oli ka andmebaasi struktuuri ülesehitamine selle võrra lihtsam. Mõte ise on samuti hea. Kui meeskonnal tekiks tahtmine asja päriselt realiseerida, oleks nüüd lihtne võtta teenus ning teha sellele lisaks otsa korralik veebirakendus, mis näeb ilus välja.