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!