Talk:Meeskond: LIB: Difference between revisions

From ICO wiki
Jump to navigationJump to search
Tpetrovi (talk | contribs)
Tpetrovi (talk | contribs)
 
(One intermediate revision by the same user not shown)
Line 18: Line 18:
Kokkuvõtteks. Antud analüüsis olid rakenduse funktsioonid kenasti läbi mõeldud. Soovitus on rohkem struktureeritust ja skeeme.
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&uuml;&uuml;bile</h1>
<p>&nbsp;</p>
<p>Kood kompileerub ja WPF rakenduse visuaalset poolt on v&otilde;imalik juba peaaegu tervenisti n&auml;ha.</p>
<h2>Visuaalne pool ja xaml kood</h2>
<p>Rakendusest on hetkel puudu v&auml;ljad kuhu kasutaja saaks sisestada laenutaja aadressi ning isikukoodi.</p>
<p>V&auml;lja v&otilde;iks j&auml;tta praeguse versiooni,&nbsp; kus žanri valik ja uue žanri lisamine teostatakse samal lehel kahe erineva elemendiga. Uue žanri lisamiseks tuleks <em>dropdown</em> men&uuml;&uuml;sse, t&auml;psemalt viimasele reale kirjeldada &ldquo;uus žanr&ldquo;, millest v&otilde;iks avaneda uus aken žanride t&ouml;&ouml;tlemiseks. Kas rakenduses on v&otilde;imalik žanre kustutada?</p>
<p>Xamli koodis on paigast &auml;ra Grid-<em>background marginid</em>. Ilmselt praegu on tehtud rakenduse visuaalne pool <em>drag-and-drop</em> meetodil ja seal on m&otilde;eldud veel vaeva n&auml;ha<em>. ListView</em>-le oleks v&otilde;inud anda parema nime kui seda on &bdquo;listView_Copy1&ldquo;, teised elemendid on arusaadavalt nimetatud. Rakenduse k&auml;ivitamisel v&otilde;iks see olla positsioneeritud ekraani keskele ning samuti tuleks m&auml;&auml;rata maksimum- ja miinimumsuurus. Elementide nimetused j&auml;rgivad &uuml;htset ja korrektsed stiili.</p>
<p>Visuaalselt oleks parem, kui raamatute ja laenutajate akende list ja k&otilde;ik v&auml;ljad oleksid akna suhtes &uuml;ks-&uuml;hele positsioneeritud.</p>
<h2>Funktsionaalne pool</h2>
<p>Funktsionaalne pool veel ei t&ouml;&ouml;ta, kuid v&auml;ike osa sellest on juba olemas. Mitte midagi pole tehtud l&auml;bi BO-de.</p>
<h2>Struktuur</h2>
<p>T&ouml;&ouml;s proovitakse l&auml;htuda MVVM p&otilde;him&otilde;tetest. Vaadet juhtima hakkavas ViewModelis veel sisu ei ole, aga vastav klass on olemas. T&auml;helepanu &auml;ratas fakt, et vaade ja vaatemudel pole sarnase nimega. Suuremate t&ouml;&ouml;de puhul oleks sarnaste nimede panemine essentsiaalne koodi haldamise seisukohalt (nt MainWindow vs MainWindowVM), aga antud t&ouml;&ouml; puhul on vaid &uuml;ks vaatemudel ja &uuml;ks vaade, mist&otilde;ttu see erilist t&auml;htsust ilmselt ei oma.</p>
<p>T&ouml;&ouml; on kenasti jaotatud andmete ligip&auml;&auml;sukihiks (DAL), &auml;riloogika- (BLL) ja rakenduskihiks. Aga konkreetses koodis pole proovitud elimineerida otsest s&otilde;ltuvust andmebaasist, mis tegelikult on nende BO-de (business objects) &uuml;ks p&otilde;him&otilde;te. BO on selleks, et oleks olemas andmed sellisel kujul nagu neid reaalselt vaja l&auml;heb ning kui andmebaasis midagi muutub (tabeli nimi vms), siis oma koodis peaks selle t&otilde;ttu muutma vaid BLL kihti ja mitte mingil juhul n&auml;iteks Bindinguid.</p>
<p>Raamatud.DAL ja Raamatud.BLL projektid on k&auml;esolevas t&ouml;&ouml;s m&otilde;lemad (v&otilde;ib-olla taotluslikult) konsoolirakendustena. Aga nad v&otilde;iks l&otilde;puks siiski &uuml;mber muuta ClassLibrary&rsquo;ks, millel ei ole visuaalset v&auml;ljundit.</p>
<p>Ettepanek oleks BLL koodi jagada tabelite kaupa (mis kood millise tabeli juurde kuulub). Sealt on mugav hakata arutama.</p>
<p>&nbsp;</p>
<h2>ERD diagrammist</h2>
<p>P&otilde;him&otilde;tteliselt &uuml;hel autoril v&otilde;ib olla ka mitu raamatut, andmebaasis pole seda hetkel realiseeritud. Kui on soov ka mitme raamatu sisestamiseks &uuml;he autori kohta, siis ilmselt tuleks andmebaasi kohendada. N&auml;iteks aitab sellise tabeli lisamine, mis &uuml;hendab raamatuid ja autoreid ning mis sisaldab vaid vastavaid ID v&auml;&auml;rtusi.</p>
<p>Igasse andmebaasitabelisse on kirjutatud &bdquo;aktiivne&ldquo;.&nbsp; T&otilde;en&auml;oliselt enamikes tabelites seda pole vaja.</p>
<p>Kontaktandmete tabeli sisu (v&auml;ljad &bdquo;telefon&ldquo; ja &bdquo;email&ldquo; jne) v&otilde;iksid ilmselt olla Laenutaja tabelis ja kaotada tabel Kontaktandmed &uuml;ldse &auml;ra.</p>
<h2>Kokkuv&otilde;tteks</h2>
<p>Kood kompileerub ja n&auml;iteks kliendil on juba praegu v&otilde;imalik h&auml;sti ette kujutada, milline tema programm v&auml;lja n&auml;eb ja kuidas ta sellega v&otilde;iks t&ouml;&ouml;tada. J&auml;rgmised sammud antud t&ouml;&ouml;s v&otilde;iksid hinnanguliselt olla andmebaasi korrigeerimine ja t&ouml;&ouml; struktuuri p&otilde;hjalik v&auml;ljam&otilde;tlemine. Kui soovitakse programm kirjutada korralikult l&auml;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