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

Ülidne arvustus

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.

Piirangute olemasolu pöördumiste arvu osas ning nende haldust

Rakenduse kasutamise käigus ei suutnud ühtegi piirangut tuvastada. Kuigi see oli küll õppejõu poolt nõuetes välja toodud, arvame, et puhtalt funktsionaalsust ja mahtu arvestades oleks see osa koormuse päris suureks ajanud. Eriti arvestades asjaolu, et projektimeeskond oli vaid kaheliikmeline. Küll aga teeksime siinkohal soovituse edasise suhtes, kui rakendust soovitakse ärilistel eesmärkidel realiseerida, tuleks erinevad piirangud ehk hinnapakettidega siduda. Või teisalt, kui eesmärgiks on müüa antud rakendust SaaS pilveteenusena, tuleks ehk hinnapakettidesse sisse arvata ka skaleeritavus ja maksva kliendi teenust mitte häirida.

Kasutusjuhend

Väga tore oli lugeda asjalikku kasutusjuhendit, mis andis kindla arusaama näiteks rollidest ja võimalustest, mida rakendus teha võimaldab. Kuigi rakendus ise on ka esimesel kasutusel valdkonnaga tuttavale kasutajale arusaadav, siis näiteks kasutaja registreerimisel oli abiks juhendi märkus projekti lisamise ligipääsude osas. Nimelt vaikimisi registreerides uue kasutaja rollina "Arendaja", ei saa ühtegi tegevust teha ilma, et administraator oleks eelnevalt mõned projektid juba süsteemi lisanud ning arendaja(d) sellega sidunud. Siinkohal ka soovitus, et kasutaja informeerimiseks võiks presenteerida seda peale esimest sisselogimist. Kokkuvõtvalt tuleks mainida, et kuigi kasutusjuhendis olid visuaalidena välja toodud kõik vaated, siis täienduseks oleks tore täpsemalt ka osad kasutusjuhud lahti kirjutada, et harida kasutajat tööriista optimaalsemalt kasutama.

Tehnoloogilise osa arvustus

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, nagu eelpool mainitud, 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, sest ei anna üldjuhul efekti Uow ja Repository mustrite kasutuse tõttu. 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 mustrit db-context'i vastu, samuti Unit of Work mustrit, 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, mis näitab ka, et tuntakse hästi ka objekt-orienteerituse põhitõdesid.

Äriloogika

Kontrollerid suhtlevad antud juhul teenuse kihiga (service layer) ja kasutatakse DTO-sid koos Factory mustriga. 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, ja 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, kuid mis põhiline, lubaks rakendust paindlikumalt kasutada. Samas, nii repositooriumid kui kontrollerid on õiges kohas ja õigesti üles ehitatud ning kõik tundub ilusasti töötavat. Ainus, mida saaks ära märkida, on osade kontrollerite puhul vea korral 404 veateate mitte tagastamine. 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 kindlasti maksimumpunkte!

Klientrakendus

Arhitektuur

Klientrakendus on realiseeritud WPF 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. Klientrakenduse domeenimudelid suhtlevad veebiteenuse 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 teenuse kiht (service layer), mille ülesandeks on andmete edastamine API vastu. Iga domeenimudeli jaoks on eraldi teenusekihi funktsionaalsus, mis pärineb baas service’ist. Mõne vaatemudeli puhul jäi silma, et see kasutab väga palju teenusekihi 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 teenusekihi 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 kogu projektimahtu, ei ole sellele palju ette heita. Disaini osas oleks võinud mõelda klienti realiseerida siiski veebirakendusena, kasutades näiteks AngularJS-i veebiraamistikuna ja näiteks Bootstrap raamistiku elemente. Samas võib omast kogemusest öelda, et kindlasti ei ole see ajasäästlikum tee, kui tehnoloogiad hästi ei valda (arvestades, et aine raames Angular raamistikust väga midagi 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.

Lõppsõna

Kokkuvõtvalt võib väita, et tegemist on ühe igati eeskujuliku projektiga, arvestades funktsionaalsust, andmemudeleid ja seoseid, mustrite kasutust ja koodi stiili. Parenduste osas kindlasti rohkelt mõtteainet ka eelpool välja toodud, aga mõned asjad, mida edasiarenduse käigus kindlasti kaaluda tuleks on nn Lazy loading'u kasutus domeenimudelite juures, kontrollerite osas veahalduse lisamine ning klientrakenduse juures teenusekihi optimeerimist. Kuid need on pelgalt soovitused. Positiivse külje pealt saaks on nimekiri pikk, kuid hästi on läbimõeldud funktsionaalsus ja andmemudelid, kasutatud on edukalt erinevaid arendusmustreid, koodi stiil on hästi loetav ning kommenteeritud. Ja arvestades, et klient rakendus on küll vaikedisainiga, on see kasutajale juba esimesest kokkupuutest arusaadav. Meie hinnang projektimeeskonnale ja projektile on 100/100 (boonuspunkte võiks lisada ka varase valmimistähtaja eest).