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

Käesolev retsensioon on koostatud DevHelpVR2 meeskonna võrgurakendused II projektitööle.

Tänane rakendus vastab kenasti etteantud nõuetele, on olemas kasutajate lisamine, projektide ja iteratsioonide haldamine ning kasutajalugude genereerimine.

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.

Klientrakenduse funktsionaalsus on piisav seatud eesmärgi täitmiseks - on olemas rollid, see toetab mitme kasuutaja olemasolu ning saab hallata projekte, iteratsioone ning seotud ressursse. Tuleb aga möönda, et kasutajasõbralikkuse osas on veel pikk tee minna, kuid MVP lahenduse jaoks on see enam kui piisav. Kuigi esialgsetes nõuetes oli soovituslik märge teha klientrakendus Angular raamistikku kasutades, siis arvame, et WPF tehnoloogia on mahult tunduvalt suurem ja saame veelkord vaid kaheliikmelist meeskonda kiita. Ehkki tarkvara esmasel käivitusel lisatakse andmebaasidesse ka nn testandmed, võiks edaspidi kaaluda näiteks testandmete sidumist uute kasutajatega.

Päringute tegemisel antakse meetodisse kõik propertid ükshaaval, selle asemel oleks võinud teha uue objeti ja anda see meetodile sisse. Nii oleks antud terve objekt kaasas koos kõigi parameetritega, mitte ükshaaval ning projekti loetavus ühtlasem.

Kokkuvõte

Projekt on hästi tehtud. Tugev eeltöö on varasemalt tehtud ja seetõttu tagab põhjalik andmebaasistruktuur projekti töökindluse ja paindlikkuse. Soovituste osas võiks tulevikus klientrakendus olla ligipääsetav veebist, mõelda rohkem läbi visuaalne ja kasutajasõbralik pool ning roll administraator võiks jääda süsteemiadministraatorile paljude õigustega ja senise asemele luua uus roll - näiteks tootejuht, meeskonnajuht.

Retsenseeris meeskond Talupood

Liikmed:

• Taavi Tilk
• Mihkel Matson

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 oleks nimekiri pikk, kuid välaj tooksime hästi läbimõeldud funktsionaalsuse ja andmemudelid, kasutatud on edukalt erinevaid arendusmustreid, koodi stiil on hästi loetav ning kommenteeritud. Ja arvestades, et klientrakendus 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).