Talk:FoodCab: Difference between revisions

From ICO wiki
Jump to navigationJump to search
Mviilvee (talk | contribs)
Created page with "Retsensioon meeskonna Autoparandaja poolt: TODO."
 
Mviilvee (talk | contribs)
 
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
Retsensioon meeskonna Autoparandaja poolt:
== Retsensioon projekti analüüsile ==
TODO.
 
Projekti analüüs on piisavalt sisukas, et anda üsna hea ülevaade rakenduse funktsionaalsusest. Lugedes tekkis väike soov, et oleks võinud olla natukene paremini liigendatud. Hetkel on jutt väga sisukas ja iga järgnev lause võib alustada juba täiesti teise rakenduse funktsionaalsuse kirjeldamist. On toodud eraldi välja nice to have alampunkt, kuid üks punkt, mis on analüüsi jutu sees seal alampunkti all välja ei tule. Analüüsile on lisatud ka andmemudel, kuid kahjuks on andmemudelist puudu väljade suurused.
 
Mille kallal natukene nuriseks on see, et hetkel ei saa olla kasutaja 2s rollis. Ehk siis UserType on kirjutatud otse kasutaja andmemudelisse. Samas hoiab see kokku jällegi arendus aega. Tekkis ka küsimus, et kes sisestab MenuItemCategory tabelisse kategooriaid. Kas admin? Kuna antud nimekiri pole kuidagi seotud võiks olla antud list näiteks enum. See hoiaks jällegi aega kokku (teeks ka haldamist lihtsamaks) ning sellest üle jääva aja saaks kasutada muu funktsionaalsuse arendamiseks. Hea tava tellimuste salvestamisel on see, et toote kriitiline info (nt nimi, hind) võiks olla duubeldatud tellimuse toote tabelisse. See väldiks ajalookadu. Ei ole kindel, et süsteemis hoida piirkonna ja addressi paare on hea mõte. Eriti hea plaan ei tundu hoida piirkondade ja aadresside paare andmebaasis. Selleks võiks kasutada välist teenusepakkujat (nt Google maps) (nice to have all kirjas) või siis pigem viia risk kliendile - kui ta tellib kaugemalt, siis läheb kauem aega.
 
Rakenduse sisu on ajaga kaasaskäiv, inimesed otsivad mugavusteenuseid ning innovatiivsust oleks sellistesse ettevõtmistesse vaja. Projekti suurus on sobiv sellele ainele ning meeskonna 4 liiget saavad kõik väga hea kogemuse. Vaadates meeskonna blogi soovitame alustada töödega niipea, kui võimalik, sest programmeerides on üllatusi kerge tulema.
 
Autor: Meeskond [[Autoparandaja]]
 
== Retsensioon projektile ==
 
Retsenseerime pigem koodi, kui UI'd. Projekt käivitus ning esialgsel ülevaatusel fataleid  ei leidnud.  Projekti maht on korralik ning vastab aine mahule.
Kood on struktureeritud ning solution jaotatud mitmeks alamprojektiks. Küll ei saa aru, milleks on alles jäetud FoodCabConsole projekt, tegemist tühja projektiga. Domeenimudelid oleks võinud olla ehk eraldi projektis. Vaatemudelid kenasti eraldatud (admin vs klient) ning nimetus ühtlane (lõppevad VM). Samas meetodite nimed on ebaühtse stiiliga - osad nimed algavad kohati suure, kohati väikse tähega. On ka olukordi, kus meetodite  Objekt orienteerituse koha pealt oleks võinud veel tükeldada. Näiteks OrderViewVM::380 hakkab selline koodiosa, mida oleks saanud kirjutada kindlasti efektiivsemalt. Kasutajate paroolid hashitakse, mis annab turvalisusele juurde. Kui koodile peale vaadata, on tunne nagu rakendus poleks kirjutatud Visual Studios, kuna väga palju naminguid ja koodi optimeerimisi, mis Visual Studio pakub on tegemata.
 
Järgnev on näide, mida oleks saanud paremini lahendada (esines korduvalt):
<code>if (String.IsNullOrEmpty(FirstName))</code> vs <code>if (FirstName == null || FirstName == String.Empty) </code>
 
Kokkuvõttes arvan, et autorid on näinud palju vaeva, et antud rakendus valmis ehitada. Kindlasti ollakse õigel teel, et omandada OOP.
 
Autor: Meeskond [[Autoparandaja]]

Latest revision as of 14:44, 31 January 2017

Retsensioon projekti analüüsile

Projekti analüüs on piisavalt sisukas, et anda üsna hea ülevaade rakenduse funktsionaalsusest. Lugedes tekkis väike soov, et oleks võinud olla natukene paremini liigendatud. Hetkel on jutt väga sisukas ja iga järgnev lause võib alustada juba täiesti teise rakenduse funktsionaalsuse kirjeldamist. On toodud eraldi välja nice to have alampunkt, kuid üks punkt, mis on analüüsi jutu sees seal alampunkti all välja ei tule. Analüüsile on lisatud ka andmemudel, kuid kahjuks on andmemudelist puudu väljade suurused.

Mille kallal natukene nuriseks on see, et hetkel ei saa olla kasutaja 2s rollis. Ehk siis UserType on kirjutatud otse kasutaja andmemudelisse. Samas hoiab see kokku jällegi arendus aega. Tekkis ka küsimus, et kes sisestab MenuItemCategory tabelisse kategooriaid. Kas admin? Kuna antud nimekiri pole kuidagi seotud võiks olla antud list näiteks enum. See hoiaks jällegi aega kokku (teeks ka haldamist lihtsamaks) ning sellest üle jääva aja saaks kasutada muu funktsionaalsuse arendamiseks. Hea tava tellimuste salvestamisel on see, et toote kriitiline info (nt nimi, hind) võiks olla duubeldatud tellimuse toote tabelisse. See väldiks ajalookadu. Ei ole kindel, et süsteemis hoida piirkonna ja addressi paare on hea mõte. Eriti hea plaan ei tundu hoida piirkondade ja aadresside paare andmebaasis. Selleks võiks kasutada välist teenusepakkujat (nt Google maps) (nice to have all kirjas) või siis pigem viia risk kliendile - kui ta tellib kaugemalt, siis läheb kauem aega.

Rakenduse sisu on ajaga kaasaskäiv, inimesed otsivad mugavusteenuseid ning innovatiivsust oleks sellistesse ettevõtmistesse vaja. Projekti suurus on sobiv sellele ainele ning meeskonna 4 liiget saavad kõik väga hea kogemuse. Vaadates meeskonna blogi soovitame alustada töödega niipea, kui võimalik, sest programmeerides on üllatusi kerge tulema.

Autor: Meeskond Autoparandaja

Retsensioon projektile

Retsenseerime pigem koodi, kui UI'd. Projekt käivitus ning esialgsel ülevaatusel fataleid ei leidnud. Projekti maht on korralik ning vastab aine mahule. Kood on struktureeritud ning solution jaotatud mitmeks alamprojektiks. Küll ei saa aru, milleks on alles jäetud FoodCabConsole projekt, tegemist tühja projektiga. Domeenimudelid oleks võinud olla ehk eraldi projektis. Vaatemudelid kenasti eraldatud (admin vs klient) ning nimetus ühtlane (lõppevad VM). Samas meetodite nimed on ebaühtse stiiliga - osad nimed algavad kohati suure, kohati väikse tähega. On ka olukordi, kus meetodite Objekt orienteerituse koha pealt oleks võinud veel tükeldada. Näiteks OrderViewVM::380 hakkab selline koodiosa, mida oleks saanud kirjutada kindlasti efektiivsemalt. Kasutajate paroolid hashitakse, mis annab turvalisusele juurde. Kui koodile peale vaadata, on tunne nagu rakendus poleks kirjutatud Visual Studios, kuna väga palju naminguid ja koodi optimeerimisi, mis Visual Studio pakub on tegemata.

Järgnev on näide, mida oleks saanud paremini lahendada (esines korduvalt): if (String.IsNullOrEmpty(FirstName)) vs if (FirstName == null || FirstName == String.Empty)

Kokkuvõttes arvan, et autorid on näinud palju vaeva, et antud rakendus valmis ehitada. Kindlasti ollakse õigel teel, et omandada OOP.

Autor: Meeskond Autoparandaja