Talk:FoodBytes

Retsensioon meeskond FoodBytes projektile

Koostanud:Meeskond: Elekter (Sigrid Aasma, Kristo Oidermaa ja Tiit Post)

Analüüsi retsensioon

FoodBytes rakenduse idee on hästi selgitatud ning retseptiraamatu funktsionaalsus on piisavalt arusaadav välisele lugejale. Positiivne on ka see, et andmebaasi struktuuri peale on mõeldud, mille põhjal saab juba rakendada funktsionaalsusi, mis on projekti “Must have” nimekirjas. Erinevate tabelite seosed on läbimõeldud ning võimaldab siduda retsepte kategooriate ja koostisosadega.

Küll aga on tabelite nimetused natuke segased. Loogiline tunduks tabel, mis jätaks välja sõna “toiduaine”, kuna koostisosa ning toiduaine on üks ja sama asi. Pakuks allolevat struktuuri Retseptide, Toiduaine ning Koostise tabelite asemele, mille puhul on RetseptiKoostisosad vaid siduva tabeli rollis ja ei ole vaja juurde tuua uut terminit.

• Retseptid (RetseptID, retseptinimi, kirjeldus, juhend, kuupäev, kasutaja_id, kategooria_id, (pilt_id))
• Koostisosad (KoostisosaID, koostisosa)
• RetseptiKoostisosad (RetseptID, KoostisosaID, kogus, yhik_id)

Rakenduse ägedamaks muutmiseks võiks olla võimalus ka retsepti lisamise juures lisada tehtud toidu pilt nagu netiblogides või kokaraamatutes. Inimesed söövad ju eelkõige silmadega. Võiks lisada selle võimaluse “nice to have” funktsionaalsuse juurde.

Tekkis mõttekoht seoses kasutajate lisamise ja kontode loomisega. Kuna rakendus on mõeldud koduseks kasutamiseks arvutis, siis näib paroolide loomine kontodele liialdusena. Piisaks ju lihtsalt kui rakenduse kasutaja saab valida või muuta, kes ta täpsemalt on. Samuti kui vaadata ainult “must have” funktsionaalsust, siis ei läheks kasutajate registreerimist ja paroolide haldust jne vaja. Piisab lihtsalt kui retseptiautoriks märkida kellegi nimi.

Teine idee oleks eraldada toitumispäeviku/ajaloo jälgimine retseptide küljest ja vast siduda see otseselt kasutajaga. Ehk siis andmebaasis “tehtud” tabel paikneks kasutaja küljes ja seal oleks lisaks ka kasutajaId, mis võimaldaks üpriski kiiresti otsida hiljem, et mis retsepte kasutaja on teinud ja nii toitumispäevikut kuvada.

Lõpp-produkti retsensioon

Koostanud:Meeskond: Elekter (Sigrid Aasma, Kristo Oidermaa ja Tiit Post)

Retsensiooni üldmulje on see, et paljude plaanitud funktsionaalsustega ei jõudnud meeskond valmis, kuna analüüsi põhjal tundus, et plaanid olid palju suuremad. Rakendus on lihtne ja väikese korrigeerimise järel saab seda ka edukalt kasutada retseptide loomiseks, vaatamiseks ja kustutamiseks (mõningate ebamugavustega). Kahju, et funktsionaalsusi, mida me lootsime näha ei ole tehtud (piltide lisamine ja paroolide ära jätmine), kuid eks need olid ka soovituslikud ettepanekud.

Toome allpool välja mõned põhilised punktid, mida tähele panime.

Plussid

• Kood kompileerub.
• Lihtne disain, less is more
• Error check on implementeeritud, retsepte saab avada iga inimene, kuid neid võib kustutada vaid originaalne looja. Ilma sisse logimata ei saa retsepte lisada.
• Kasutatud on MVVM arhitektuuri, kus on eraldatud objektid, päringud, äriloogika ja esitlus (viimase kahe sisu on veidikene segamini).
• Retseptide lisamine ja kustutamine toimib.
• Andmebaas tundub mõistliku struktuuriga (antud funktsionaalsuste juures).

Miinused

• Ei saa lisada uut kasutajat (üritab NULL väärtust salvestada kasutaja tabelis).
• Ei saa vaadata looduid retsepte ilma otsimata
• Saab otsida vaid nime järgi (mitte kategooria järgi nagu eesmärkides)
• Retsepti lisamisel lisatakse “yhik”, “kategooria” tabelitesse uued väljad ka mitteunikaalsete väärtuste puhul, mis ei anna eraldi tabelitele eraldi otstarbekust
• Loodud retsepti ei saa avada (vea tekitab vigane ühiku kuvamine retseptis, töötab ilma ühiku kuvamiseta), lohiseva koodi tõttu on raske kindlaks teha, mida üldse üritatakse võrdsustada Textblcokiga txtblck2, mis antud juhul ka retsepti avamist takistab (ära tuleb kaotada +1 variablist findyhik).
• Retsepte ei saa muuta, peab uuesti looma.
• Välja logides jätab nii kasutajanime kui ka paroolivälja täidetuks
• Kakskeelsus ja segased nimetused koodis (eesti ja inglise keel)

Soovitused

• Kas koostisosade puhul on vajalik, et kasutaja ise lisab teksti? Kui tabelisse lisataks unikaalsed väärtused, oleks efektiivsem anda rippmenüüst kasutajatele ette valik, mida lisada
• Sisse logituna võiks ära kaotada nupu nagu “registreeri uus kasutaja”
• Loetavuse mõttes kasutada paremini namespace'i näiteks Service klassides (using FoodBytes.BusinessObjects)
• Disain on selge, kuid võiks olla viimistletum. Disainielemente on väga vähe, mis informatsiooni paremini esile tooksid.

Kokkuvõte

Kuigi põhifunksionaalsused on saavutatud, projekt on struktureeritud MVVM arhitektuuriga, andmebaas on selgete omadustega ja programmi üldpildist on kerge aru saada, jääb projekt natukene lahjaks. Programmi seadistamiseks on vaja luua kohalik andmebaas etteantud scriptiga ning enamus funktsionaalsusi pole üldse võimalik kasutada, sest hetkeseisuga ei õnnestu programmil edukalt uut kasutajat andmebaasi lisada. Seda tuleb teha käsitsi. Samuti üks suurimaid programmi omadusi peaks olema see, et kasutajad saavad lihtsa vaevaga vaadata kasutajate loodud retsepte. Hetkel saab neid vaadata ainult siis, kui retsepti nimi on meeles ja seda Otsinguribalt otsida. Retsepte pole võimalik avada, kui just ei kommenteeri välja ühikute kuvamist või ei paranda koodis viga.

Vaatamata projekti struktuurist ja paljudest meetoditest, tekib segadust ViewModeli ja View külje peal. Meetodid on lohisevad ning liiga palju koodi pesitseb just WPF poole peal, mitte ViewModel poole peal.

Programmil on palju potentsiaali, kuna idee on hea ja retsepti lisamine andmebaasi töötab. Samuti on ka projekti struktuur paigas, mis vajab korrigeerimist View ja ViewModeli poole pealt. Korda tuleks teha ka vead, mis takistavad programmil töötamast nagu uue kasutaja lisamine ning retsepti avamine (ühiku kuvamine).