Talk:Meeskond: LIB: Difference between revisions
Created page with "=Analüüsi retsensioon= Meeskond LIB analüüsi on kerge lugeda ning hallata. Sisu oli küll pisut lühike, aga sellegi poolest selgete mõtetega. Eriti kiidame Must have ja..." |
|||
| (3 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
= | =Retsensioon meeskond LIB koduse raamatukogu rakenduse analüüsile= | ||
Analüüs on ladus, kergesti loetav ning arusaadav. Must have ja nice to have funktsionaalsused on analüüsis väga hästi välja toodud: kõigi kriitiliste (koduse) raamatukogu funktsioonide peale on mõeldud. Viimane on oluline, kuna ühe väikese kirjutamata rea taga analüüsis võib olla tegelikult suur hulk tööd. | |||
Rakenduses ei eristata administraatoreid ja tavakasutajaid, mis on arvestades sihtotstarvet mõistlik. | |||
Soovitused: | |||
1. Analüüs võiks olla isegi rohkem struktureeritud, et arendaja leiaks hoobilt talle vajamineva informatsiooni. | |||
2. Enne rakenduse kirjutamist võiks valmis teha ka andmebaasimudeli, et kõigil arendajatel oleks võimalik sellest lähtuda. | |||
3. Võiks lisada ühe suure skeemi kasutajale kuvatavatest vaadetest koos erinevate seostega kergesti hoomataval ja selgel kujul. See aitab programmi piltlikustada ja üheselt mõistetavaks teha. Viimastega on võimalik tuleviku tarbeks sellekohase lisakommunikatsiooni arvelt aega kokku hoida. | |||
Ka näitlikustavad tabelid kirjetest aitavad programmi paremini hoomata. | |||
4. Analüüsis oli kirjas, et koduses raamatukogus pannakse andmebaasi kirja veel raamatute ilmumisaastad jne. Soe soovitus oleks kindlasti funktsioonide ja andmete osas läbi mõelda, kas need on kasutaja jaoks tähtsad ja kas proportsionaalselt saadud kasu lisafunktsioonide näol või isikliku arengu osas kaalub üles tehtud töö antud rakendusega. | |||
Kokkuvõtteks. Antud analüüsis olid rakenduse funktsioonid kenasti läbi mõeldud. Soovitus on rohkem struktureeritust ja skeeme. | |||
Originaalne esitamise aeg oli 6. november. | |||
Retsenseeris: Meeskond Premium | |||
<h1>Retsensioon LIB esmasele prototüübile</h1> | |||
<p> </p> | |||
<p>Kood kompileerub ja WPF rakenduse visuaalset poolt on võimalik juba peaaegu tervenisti näha.</p> | |||
<h2>Visuaalne pool ja xaml kood</h2> | |||
<p>Rakendusest on hetkel puudu väljad kuhu kasutaja saaks sisestada laenutaja aadressi ning isikukoodi.</p> | |||
<p>Välja võiks jätta praeguse versiooni, kus žanri valik ja uue žanri lisamine teostatakse samal lehel kahe erineva elemendiga. Uue žanri lisamiseks tuleks <em>dropdown</em> menüüsse, täpsemalt viimasele reale kirjeldada “uus žanr“, millest võiks avaneda uus aken žanride töötlemiseks. Kas rakenduses on võimalik žanre kustutada?</p> | |||
<p>Xamli koodis on paigast ära Grid-<em>background marginid</em>. Ilmselt praegu on tehtud rakenduse visuaalne pool <em>drag-and-drop</em> meetodil ja seal on mõeldud veel vaeva näha<em>. ListView</em>-le oleks võinud anda parema nime kui seda on „listView_Copy1“, teised elemendid on arusaadavalt nimetatud. Rakenduse käivitamisel võiks see olla positsioneeritud ekraani keskele ning samuti tuleks määrata maksimum- ja miinimumsuurus. Elementide nimetused järgivad ühtset ja korrektsed stiili.</p> | |||
<p>Visuaalselt oleks parem, kui raamatute ja laenutajate akende list ja kõik väljad oleksid akna suhtes üks-ühele positsioneeritud.</p> | |||
<h2>Funktsionaalne pool</h2> | |||
<p>Funktsionaalne pool veel ei tööta, kuid väike osa sellest on juba olemas. Mitte midagi pole tehtud läbi BO-de.</p> | |||
<h2>Struktuur</h2> | |||
<p>Töös proovitakse lähtuda MVVM põhimõtetest. Vaadet juhtima hakkavas ViewModelis veel sisu ei ole, aga vastav klass on olemas. Tähelepanu äratas fakt, et vaade ja vaatemudel pole sarnase nimega. Suuremate tööde puhul oleks sarnaste nimede panemine essentsiaalne koodi haldamise seisukohalt (nt MainWindow vs MainWindowVM), aga antud töö puhul on vaid üks vaatemudel ja üks vaade, mistõttu see erilist tähtsust ilmselt ei oma.</p> | |||
<p>Töö on kenasti jaotatud andmete ligipääsukihiks (DAL), äriloogika- (BLL) ja rakenduskihiks. Aga konkreetses koodis pole proovitud elimineerida otsest sõltuvust andmebaasist, mis tegelikult on nende BO-de (business objects) üks põhimõte. BO on selleks, et oleks olemas andmed sellisel kujul nagu neid reaalselt vaja läheb ning kui andmebaasis midagi muutub (tabeli nimi vms), siis oma koodis peaks selle tõttu muutma vaid BLL kihti ja mitte mingil juhul näiteks Bindinguid.</p> | |||
<p>Raamatud.DAL ja Raamatud.BLL projektid on käesolevas töös mõlemad (võib-olla taotluslikult) konsoolirakendustena. Aga nad võiks lõpuks siiski ümber muuta ClassLibrary’ks, millel ei ole visuaalset väljundit.</p> | |||
<p>Ettepanek oleks BLL koodi jagada tabelite kaupa (mis kood millise tabeli juurde kuulub). Sealt on mugav hakata arutama.</p> | |||
<p> </p> | |||
<h2>ERD diagrammist</h2> | |||
<p>Põhimõtteliselt ühel autoril võib olla ka mitu raamatut, andmebaasis pole seda hetkel realiseeritud. Kui on soov ka mitme raamatu sisestamiseks ühe autori kohta, siis ilmselt tuleks andmebaasi kohendada. Näiteks aitab sellise tabeli lisamine, mis ühendab raamatuid ja autoreid ning mis sisaldab vaid vastavaid ID väärtusi.</p> | |||
<p>Igasse andmebaasitabelisse on kirjutatud „aktiivne“. Tõenäoliselt enamikes tabelites seda pole vaja.</p> | |||
<p>Kontaktandmete tabeli sisu (väljad „telefon“ ja „email“ jne) võiksid ilmselt olla Laenutaja tabelis ja kaotada tabel Kontaktandmed üldse ära.</p> | |||
<h2>Kokkuvõtteks</h2> | |||
<p>Kood kompileerub ja näiteks kliendil on juba praegu võimalik hästi ette kujutada, milline tema programm välja näeb ja kuidas ta sellega võiks töötada. Järgmised sammud antud töös võiksid hinnanguliselt olla andmebaasi korrigeerimine ja töö struktuuri põhjalik väljamõtlemine. Kui soovitakse programm kirjutada korralikult läbi BO-de, siis praeguses koodis ilmselt peab juba ka parandusi tegema.</p> | |||
Originaalne esitamise aeg oli 20. detsember. | |||
Retsenseeris: Meeskond Premium | Retsenseeris: Meeskond Premium | ||
Latest revision as of 22:10, 20 December 2015
Retsensioon meeskond LIB koduse raamatukogu rakenduse analüüsile
Analüüs on ladus, kergesti loetav ning arusaadav. Must have ja nice to have funktsionaalsused on analüüsis väga hästi välja toodud: kõigi kriitiliste (koduse) raamatukogu funktsioonide peale on mõeldud. Viimane on oluline, kuna ühe väikese kirjutamata rea taga analüüsis võib olla tegelikult suur hulk tööd.
Rakenduses ei eristata administraatoreid ja tavakasutajaid, mis on arvestades sihtotstarvet mõistlik. Soovitused:
1. Analüüs võiks olla isegi rohkem struktureeritud, et arendaja leiaks hoobilt talle vajamineva informatsiooni.
2. Enne rakenduse kirjutamist võiks valmis teha ka andmebaasimudeli, et kõigil arendajatel oleks võimalik sellest lähtuda.
3. Võiks lisada ühe suure skeemi kasutajale kuvatavatest vaadetest koos erinevate seostega kergesti hoomataval ja selgel kujul. See aitab programmi piltlikustada ja üheselt mõistetavaks teha. Viimastega on võimalik tuleviku tarbeks sellekohase lisakommunikatsiooni arvelt aega kokku hoida.
Ka näitlikustavad tabelid kirjetest aitavad programmi paremini hoomata.
4. Analüüsis oli kirjas, et koduses raamatukogus pannakse andmebaasi kirja veel raamatute ilmumisaastad jne. Soe soovitus oleks kindlasti funktsioonide ja andmete osas läbi mõelda, kas need on kasutaja jaoks tähtsad ja kas proportsionaalselt saadud kasu lisafunktsioonide näol või isikliku arengu osas kaalub üles tehtud töö antud rakendusega.
Kokkuvõtteks. Antud analüüsis olid rakenduse funktsioonid kenasti läbi mõeldud. Soovitus on rohkem struktureeritust ja skeeme.
Originaalne esitamise aeg oli 6. november.
Retsenseeris: Meeskond Premium
Retsensioon LIB esmasele prototüübile
Kood kompileerub ja WPF rakenduse visuaalset poolt on võimalik juba peaaegu tervenisti näha.
Visuaalne pool ja xaml kood
Rakendusest on hetkel puudu väljad kuhu kasutaja saaks sisestada laenutaja aadressi ning isikukoodi.
Välja võiks jätta praeguse versiooni, kus žanri valik ja uue žanri lisamine teostatakse samal lehel kahe erineva elemendiga. Uue žanri lisamiseks tuleks dropdown menüüsse, täpsemalt viimasele reale kirjeldada “uus žanr“, millest võiks avaneda uus aken žanride töötlemiseks. Kas rakenduses on võimalik žanre kustutada?
Xamli koodis on paigast ära Grid-background marginid. Ilmselt praegu on tehtud rakenduse visuaalne pool drag-and-drop meetodil ja seal on mõeldud veel vaeva näha. ListView-le oleks võinud anda parema nime kui seda on „listView_Copy1“, teised elemendid on arusaadavalt nimetatud. Rakenduse käivitamisel võiks see olla positsioneeritud ekraani keskele ning samuti tuleks määrata maksimum- ja miinimumsuurus. Elementide nimetused järgivad ühtset ja korrektsed stiili.
Visuaalselt oleks parem, kui raamatute ja laenutajate akende list ja kõik väljad oleksid akna suhtes üks-ühele positsioneeritud.
Funktsionaalne pool
Funktsionaalne pool veel ei tööta, kuid väike osa sellest on juba olemas. Mitte midagi pole tehtud läbi BO-de.
Struktuur
Töös proovitakse lähtuda MVVM põhimõtetest. Vaadet juhtima hakkavas ViewModelis veel sisu ei ole, aga vastav klass on olemas. Tähelepanu äratas fakt, et vaade ja vaatemudel pole sarnase nimega. Suuremate tööde puhul oleks sarnaste nimede panemine essentsiaalne koodi haldamise seisukohalt (nt MainWindow vs MainWindowVM), aga antud töö puhul on vaid üks vaatemudel ja üks vaade, mistõttu see erilist tähtsust ilmselt ei oma.
Töö on kenasti jaotatud andmete ligipääsukihiks (DAL), äriloogika- (BLL) ja rakenduskihiks. Aga konkreetses koodis pole proovitud elimineerida otsest sõltuvust andmebaasist, mis tegelikult on nende BO-de (business objects) üks põhimõte. BO on selleks, et oleks olemas andmed sellisel kujul nagu neid reaalselt vaja läheb ning kui andmebaasis midagi muutub (tabeli nimi vms), siis oma koodis peaks selle tõttu muutma vaid BLL kihti ja mitte mingil juhul näiteks Bindinguid.
Raamatud.DAL ja Raamatud.BLL projektid on käesolevas töös mõlemad (võib-olla taotluslikult) konsoolirakendustena. Aga nad võiks lõpuks siiski ümber muuta ClassLibrary’ks, millel ei ole visuaalset väljundit.
Ettepanek oleks BLL koodi jagada tabelite kaupa (mis kood millise tabeli juurde kuulub). Sealt on mugav hakata arutama.
ERD diagrammist
Põhimõtteliselt ühel autoril võib olla ka mitu raamatut, andmebaasis pole seda hetkel realiseeritud. Kui on soov ka mitme raamatu sisestamiseks ühe autori kohta, siis ilmselt tuleks andmebaasi kohendada. Näiteks aitab sellise tabeli lisamine, mis ühendab raamatuid ja autoreid ning mis sisaldab vaid vastavaid ID väärtusi.
Igasse andmebaasitabelisse on kirjutatud „aktiivne“. Tõenäoliselt enamikes tabelites seda pole vaja.
Kontaktandmete tabeli sisu (väljad „telefon“ ja „email“ jne) võiksid ilmselt olla Laenutaja tabelis ja kaotada tabel Kontaktandmed üldse ära.
Kokkuvõtteks
Kood kompileerub ja näiteks kliendil on juba praegu võimalik hästi ette kujutada, milline tema programm välja näeb ja kuidas ta sellega võiks töötada. Järgmised sammud antud töös võiksid hinnanguliselt olla andmebaasi korrigeerimine ja töö struktuuri põhjalik väljamõtlemine. Kui soovitakse programm kirjutada korralikult läbi BO-de, siis praeguses koodis ilmselt peab juba ka parandusi tegema.
Originaalne esitamise aeg oli 20. detsember.
Retsenseeris: Meeskond Premium
