Talk:FoodCab: Difference between revisions
Created page with "Retsensioon meeskonna Autoparandaja poolt: TODO." |
No edit summary |
||
Line 1: | Line 1: | ||
Retsensioon meeskonna | == 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. |
Revision as of 21:55, 9 November 2016
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.