Talk:SimpleGeo

Retsensioon.

Retsenseerija Meeskond:RemindEm

Meeskonna SimpleGeo analüüs on üsna põhjalik. Välja on toodud rakenduse eesmärk, mis üldjoontes on põhjendatud, kuid kohati raskesti mõistetav. Millisele kasutajale on rakendus täpsemalt mõeldud? Kas näiteks eramaja omanik peaks põlengu puhkedes ise endale päästekomandot otsima või on see mõeldud näiteks päästekeskuse kõneoperaatori töövahendiks?

Rakendus kasutab suuresti kolmandate osapoolte poolt pakutavaid teenuseid, mis võivad mõjutata töökindlust ja kiirust. Kas seda kolmandaosapoole riski oleks võimalik mõne lahendusega maandada? Samuti tekib küsimus, kust saadakse info ja kuidas kajastatakse päästekomandode reageerimisaega. Siinkohal on vaja arvestada meeskonna suuruse, autode arvu jms, kuid ka sellega, et päästeautod võivad olla väljakutsel ning seetõttu pikeneb reageerimisaeg oluliselt.

Tööjaotus tundub meeskonnaliikmete vahel ühtlaselt jaotatud.

Plaanitav must have funktsionaalsus on hästi lahti kirjutatud. Ülesande keerukust arvestades võiks neid funktsionaalsusi vähendada või viia üle soovitud funktsionaalsuste nimekirja.

Rakendus oleks sobilik mobiilsele platvormile, kuid tundub, et see on pea täielikult planeeritud töölaua lahendusena. Näiteks on mobiilsetel seadmetel tihti olemas GPS seade, mis võimaldaks automaatselt asukohta tuvastada.

Kokkuvõttes võib öelda, et meeskond on analüüsi käigus oma idee läbi mõelnud ning arusaadavalt ja loogiliselt kirja pannud. Analüüsi põhjal tundub rakendus küllaltki keeruline ning selle teostamisel võib tekkida palju probleeme, kuid seda põnevam on näha lõpptulemust.

Retsensioon prototüüp Andres Mets; Meeskond CRM/WPF tehnoloogial

Kood on kenasti kihistatud, st. on olemas eraldi teenus-, andmepöördus- ja vaadete kiht. Kitsaskoht millele tahaks tähelepanu juhtida on Interface'ide puudumine teenuste kihis-> üldjoontes vaadates kasutajaliidesega süsteeme, teostame me alati ühesuguseid toiminguid ning hetke implementatsiooni mudeli juures on väga raske vahetada teenuste funktsionaalsust, juhuks näiteks kui soovitakse muuta rakenduse andmesalvestus näiteks failidesse serialiseerimise põhiseks- ei saa lihtsalt teenuste kihti vahetada, et instantsieerida näiteks failidesse serialiseerimist toetavate teenuste implementatsiooniga. See on samuti tehniline nüanss- saab vaielda, et kui soovitakse teistsugust teenusekihi käitumist, siis tehaksegi uus projekt ning kopeeritakse teenuste kiht ja kirjutatakse ümber, kuid üldiselt on kood mugavam hallata ning jälgida kui on olemas Interface'ide põhine teenuste kirjeldus. Teenuste juures sooviksin veel viidata tüüpimise vajadusele-> implementeerivad klassid peaksid töötama vaid etteantud tüüpi objektidega- muudab koodi väga ühesuguseks ning jälgitavaks, võimaldab üldistamist-> näiteks save meetod on kõigile objektidele samasugune ainult andmetabel ning relatsioonid on teised, seega saab savlestamise, kustutamise generaliseerida üldisesse teenusklassi, mida teised teenused saaksid laiendada- saavutades vajaliku ühetaolise funktsionaalsuse automaatselt. Vaate kihis on koodis kasutatud sõnesid vaadete tiitlites, väljade kirjelduses ilmutatud kujul- soovitaksin kasutada stringi ressursse, mida saab laadida võtme järgi ressursifailist. Eeliseks on lihtne nimetuste haldamine, üle süsteemi nimetatakse asju ühte moodi, kerge internatsionaliseerida, vahetada ressursi fail, saab ingilise keelse versiooni jne. Kasutaja parooli salvestamise juures soovitaksin kasutada SHA1 algoritmi, see genereerib alati vaid ühesuunalise krüpteeringu ning on tõhusam, kui antud projektis realiseeritu.(dll-i dekompileerides ei saa mingitele lähteandmetele ligi) Mõned minu poolt väljatoodud asjad on vailedavad kuid hea programmeerimise tava kohaselt väga soovituslikud, kuna muudavad projekti haldamise üle pika ajaperioodi lihtsamaks- saab lihtsama vaevaga kaasata uusi arendjaid.