Talk:Givela

XML retsensioon Double Trouble meeskonna poolt

Kõigepealt mainiks ära selle, et meeskonna Givela idee on väga huvitav ja kindlasti koguks populaarsust. On näha, et meeskond on teinud põhjaliku eeltöö selleks et projekti hea funktsionaalsus oleks tagatud. On loodud andembaasi tabel ja välja kirjutatud vaated, mis saavad projekti töös olema. XML on väga konkreetne ning sisaldab nõuetele vastavalt vähemalt neli dimensiooni. Iga elemendi juures on kasutatud on ka CDATAt, mis on samuti väga hea. Nõuetes oli ka kirjas, et kasutusel peavad olema attribuudid, mis on rohkem kui id, kuid neid ma kahjuks siin failis ei näe. Lisaks olemasolevale lisaksime enda poolt ka mingisugune algelise hinna, mille kasutaja saab sisestada ja ostja või siis nö annetaja otsustab ise, kas ta tahab seda annetussummat suurendada või mitte. XSD tundub korras olevat. XSLT faili on meeskonnal vaid üks, kuid kriteeriumiks oli vähemalt kaks transformatsiooni. Positiivne on, et kasutatud on rohkem tingimuslauseid kui oli nõutud ning et kasutatud on ka CSSi.

Retsenseeris meeskond DoubleTrouble.

Retsensioon veebiteenusele (Travo 2.0)

Givela serveri ülesseadmine on ülimalt lihtne, kui taustsüsteem on juba vastavalt konfigureeritud (töötav Microsoft SQL server, kompileerimiseks vajalikud .NET teegid olemas). Andmebaasi täitmisel näidisandmetega tekkis logisse küll üks välisvõtme konflikt, kuid see ei takistanud edukat demoks piisavate näidisandmete loomist.

Veebiteenuse süsteem on jaotatud nelja kihti: BLL, DAL, Domain ja Web-API. Käin läbi iga kihi eraldi.

Web-API kiht

Siin kihis peaksid asuma kontrollerid ja üldine API (veebiteenuse) konfiguratsioon. Koheselt torkab silma, et lisaks eeltoodule on siia pandud ka veebipõhine (AngularJS baasil) klientrakendus. Kiht on ka põimitud ASP.NET MVC tehnoloogiaga. Lühidalt tähendab see seda, et Web API kiht on segu kolmest tehnoloogiast: API teenusest, veebipõhisest klientrakendusest ja ASP.NET Web MVC-st (mille ainus reaalne ülesanne antud juhul on CSS ja JavaScript failide nimistute automaatne loomine (MVC enda tehnoloogiaid ei kasutata ja tegemist on puhtalt Angularil põhineva SPA-ga)). Siinkohal mainin, et samasse ämbrisse astusin eelmine aasta Meeskond: Travo projektiga.

Web API puhul leiavad reaalset kasutust neli kontrollerit: Bid-, Charity-, Product- ja AccountController. Edukalt on tööle saadud küpsistel põhinev autentimine ja sessioonihaldus (tokeni eluea pikkuses). Autoriseeritavad endpointid töötavad vastata annotatsiooniga. See on ilmselt kõige keerukam projekti osa ning on antud projektis edukalt funktsioneerima saadud.

Domain kiht

Siin asuvad mudelid on hästi kirjeldatud ning on tõrkeid takistavate annotatsioonidega.

BLL kiht

BLL kihis on jälgitud eeskujukalt Servicite loomise ja DTO-de tagastamise loogikat. DTO-d luuakse läbi tavapärase Factory klassi kasutuse. Kihi ülesehitus on eeskujulik; ainus norimiskoht oleks see, et Factoryd võiksilt vabalt olla static klassid.

DAL kiht

DAL kihis asetseb ootuspäraselt EntityFrameworkile vastav DbContext klass ja migratsioonid. Kasutatud on ka repository patternit. Repository pattern on realiseeritud korrektselt, luues igale repositoryle vastavat interfacei, mis võimaldab suuremat koodi eraldatust ning tõstab testitavust. Küll aga on näha, et üleminek pole veel lõpule viidud, kuna repositorydes asuvad vaid meetodid kõikide olemite tagastamiseks. See peegeldub ka vastavates service klassides.

Kokkuvõte

Kokkuvõtvalt öeldes on veebiteenuse struktuur hea ning lausa eeskujulik. Tööle on saadud peamised funktsionaalsused: kasutajate haldus ja kasutajatele mõeldud sisu haldus. Selle kõige realiseerimiseks on kasutatud nelja kihti, kuhu on olnud plaan implementeerida service ja repository mustritega andmete lugemine ja jäädvustamine. Töö on veel poolik, nagu on kinnitanud ka projektijuht, kuid seni tehtud töö on suures mahus siiski äärmiselt pädev ning ollakse kindlasti õigel teel.

Kõike suuremaks murekohaks on Web API kiht, kuhu on kokku keedetud supp kolmest erinevast tehnoloogiast: ASP.NET Web API-st, ASP.NET MVC-st ja AngularJS klientrakendusest. Siin tuleks teha kerge puhastus, mille käigus oleks mõistlik eemaldada ASP.NET MVC täielikult ning tõsta AngularJS klientrakendus eraldi projekti (kausta). Kui viia projektis pooleliolevad üleminekud (näiteks repositoride ja service klasside korrektne rakendus) lõpuni ning teha suurpuhastus Web API kihis, siis oleks veebiteenuse osa maksimumpunktide vääriline.

Retsenseeris Meeskond: Travo 2.0.

Retsensioon klientrakendusele (Travo 2.0)

Givela klientrakendus on kirjutatud AngularJS baasil. See ei nõudnud ülesseadmiseks midagi erilist, kuna on integreeritud Web API projekti solutionisse (mis minu arvates oleks suuremate projektide puhul negatiivseks küljeks).

Analüüsin koodi erinevate aspektide põhjal, mida pean oluliseks.

Kasutajaliides (UI & UX)

Kuna antud projekti eesmärgiks ei olnud vägeva kasutajaliidese ja -kogemuse loomine, siis siinkohal ma pikalt ei peatu. Kasutajaliides on lihtne ning on näha, et tegemist on prototüübiga. Vajav funktsionaalsus töötab ja on ilma kriitiliste vigadeta kasutatav. Samas leiab ka kiiresti mitmeid kohti, kus parandusi võiks teha.

Siinkohal tuleks välja tuua aga ka suure plussi: veebileht on täielikult responsive ning mitmekeelne. Mad props for that.

Koodi struktuur ja edasiarenduse võimaldatavus

Antud AngularJS projekti struktuur on eeskujulik. Kaustade struktuur on lihtsasti loetav ning isegi esmakordsele vaatajale arusaadav: kõik funktsionaalsused on koondatud vastava nimedega kaustadesse. Näiteks 'common' kaustast võib leida ühised singletonid ja/või static klassid nagu 'identity' või 'notifier', mille eesmärkides on vastavalt autentimise haldamine ja kasutajaliideses teavituste kuvamine. Samamoodi on koondatud eri vaated vastavatesse kaustadesse (näiteks 'login' või 'bid' vaated). Vaadete kasutadest leiab MVC-le vastavalt vaate enda ning ka sellega seonduva kontrolleri (vajadusel ka vastav RESTful resource factory). Klientrakenduse liigutamine ja muutmine on lihtne, kõige üldisemad seaded (näiteks tõlked ja routing) on koondatud peafaili 'app.js'. Kui norida, siis tõlked võiks olla eraldi failis, kuid sellise väikesemahulise projekti puhul ei ole see probleemiks.

Koodi puhtus

Kood on pigem lihtsasti loetav ning eeskujulikult trepitud. Kui tegemist oleks production koodiga, siis ma oleks pisarates, kuna sisse on jäetud palju väljakommenteeritud kooditükke. Õnneks on tegemist arendusjärgus oleva rakendusega, mis on pigem mõeldud API töövalmiduse demomiseks kui turule minemiseks. Kui mõttesilmas kustutada väljakommenteeritud koodijupid ära, siis jääb alles puhas kood, kus moodulite ja funktsioonide nimed on arusaadavad ja koodi võib ilma pikema konsulteerimiseta ka kolmas osapool edasi arendada.

Kokkuvõte

Kokkuvõtvalt võib öelda, et klientrakenduse ülesehitus on eeskujulik ning kood on loetav ja hallatav. Kasutajaliides on lihtne ning vastab prototüübi staatusele, lisapunkte annavad kindlasti lehekülje mitmekeelsus ja responsiveness. Demova klientrakenduse jaoks on see pädev ning kuna kood on niivõrd puhas, siis on seda lihtne ka produktsioonikõlbulikuks lahenduseks refaktoreerida. Ainus negatiivne asi on jällegi see, et kood asub Web API layeris (aga see on minu arvamus). Max punktid, läheb!

Retsenseeris Meeskond: Travo 2.0.