Talk:Liisa ja Poisid: Difference between revisions

From ICO wiki
Jump to navigationJump to search
Line 40: Line 40:
* Ma eeldan, et vanuse peaks automaatselt arvutama, kuid seda ta ei tee,  
* Ma eeldan, et vanuse peaks automaatselt arvutama, kuid seda ta ei tee,  
tagastab arvu 0.  
tagastab arvu 0.  
* Sulgemisnupp ei teeks paha.
* Rakenduse sulgemisfunktsiooni puudumine.
 


Kokkuvõtteks võib öelda, et projekt on viisakas, kuid jääb tunne, et on jäetud päeva pealt pooleli ning jäetud pisiasjad lisamata/parandamata(detailidesse pole süübitud).
Kokkuvõtteks võib öelda, et projekt on viisakas, kuid jääb tunne, et on jäetud päeva pealt pooleli ning jäetud pisiasjad lisamata/parandamata(detailidesse pole süübitud).

Revision as of 20:30, 15 June 2015

Retsensioon meeskonnalt Lupardid

Struktuur

XML vastab nõuetele: sügavust on üle miinimumi ning atribuudid on olemas. Nii XML, XSD eraldi kui ka XML XSD põhjal valideeruvad. CDATA kasutust on üleliigselt, eriti kohtades kus XSD määrab ära selle, et elemendi väärtus on arvu kujul. Miks on aasta, kuu ja päev eraldi elemendid mitte atribuudina? Arvutid pole nii aeglased, et teatud kuu kanded kõikidest kannetest üles otsida. Lisaks pole "aasta" nimeline element semantiline (nimi ei kirjelda sisu). Antud lähenemine pole vale aga pole ka mõistlik. Kuna minimaalne sügavus jääb siiski täidetuks tunduks mõistlikum kui oleks järgnevalt:

 <practices>
   <practice startDate="2015-03-14T17:09" endDate="2015-03-14T18:55" weight="85">
       <type><![CDATA[Zumba]]></type>
       <lostCalories>1980</lostCalories>
   </practice>
 </practices>

Skeemifailis on defineeritud täisarvu ja kuupäeva tüübid ning märgitud ka esinemiste arv kommentaari elemendil, see on hea.

Transformatsioonid

HTML'i genereerimine töötab, andmed näidatakse välja. Küll aga on HTML'i enda struktuur väga kehv ning ei valideeru, see polnud vist küll ülesandes vajalik aga et te teaksite. Listide sisse ei panda päiseid ega suuri hulki tekste, lisaks ilma põhjuseta ei pea kõiki elemente ümbritsema teiste elementidega (antud juhul paragrahvi elementidega). XML transformatsioon on võib-olla liiga lihtne aga kuna selle kohta mingeid nõudeid ei olnud siis ütleks, et nutikas lähenemine. Kõik muu on hästi.

Klientrakenduse retsensioon meeskonnalt Lupardid

Olemeid on 6. Olemite väljadel atribuudid kirjeldatud(stringi pikkused, kuvatavad nimed), täpselt nagu nõutud oli.

Pole kasutatud UOWd(on olemas, ninjectis sõltuvused süstitud, kuid pole kuskil kasutatud). Tundub siiski üpris puhtalt ja loogiliselt üles ehitatud projekt. Arvatavasti ei hakatud UOWd kasutama, kuna ei osatud seda korrektselt rakendada ning jäeti see osa lihtsalt implementeerimata.

DTO’d on olemas, viisakad. Iga DTO jaoks loodud ka DTO factory. Service’sid sisaldavad custom meetodeid. Igal service’l olemas interface.


Puudujäägid:

  • Registreerides ei tulnud veateateid - tekitas palju frustratsiooni ja segadust, sest ei saanud aru, kas kasutaja sai loodud või mitte.
  • Treeningut sisestades ei saanud treeningu kestvust valida(combobox tühi) ning

salvestades jookseb kogu rakendus kotti. Comboboxi asemel oleks võinud kasutada lihtsat textboxi, mis tundub palju loogilisem ja mugavam kasutajale.

  • Üks viewmodel kõige jaoks - veidi halb, võiks olla organiseeritum.
  • Ma eeldan, et vanuse peaks automaatselt arvutama, kuid seda ta ei tee,

tagastab arvu 0.

  • Rakenduse sulgemisfunktsiooni puudumine.


Kokkuvõtteks võib öelda, et projekt on viisakas, kuid jääb tunne, et on jäetud päeva pealt pooleli ning jäetud pisiasjad lisamata/parandamata(detailidesse pole süübitud).