Talk:DevHelpVR2

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

Retsensioon veebiteenusele

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.

Retsensioon klientrakendusele

Klientrakendus on ehitatud WPF tehnoloogial ja töötab samas solution's. Käivitamiseks tuleb mõlemad - nii veebiteenus kui klientrakendus korraga käivitada. Kuna ka ise ehitasime oma projekti sama loogika järgi, oli teada, kuidas mõlemat teenust korraga käivitada. Seda ehk võiks juhendisse ka märkida. Klientrakendus kasutab äriloogika kihi DTO mudeleid, mis näitab, et kihid on üksteisest ilusti eraldatud ja . Eraldi on olemas vaatemudelid, mis suhtlevad teenusekihi klassidega ja see omakorda veebiteenusega. Klientrakendus on

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).