Lisätty tehtävän 4 arvosteluperusteet ja malliratkaisu

koe2023.md

@@ -169,6 +169,54 @@ Näin pitkälle tulevaisuuteen määritelty story saa olla laaja epiikin tasoine
 
 _Tehtävän arvioi Valtteri Kantanen. Omasta arvioinnista voi tarvittaessa kysyä etunimi.sukunimi@helsinki.fi tai Discordissa_
 
+#### Arvosteluperusteet
+
+Tehtävässä sai pisteitä seuraavien asioiden mainitsemisesta:
+
+- a-kohta (1,5 p.):
+    - Yksi perusteltu syy copypasten välttämiselle (0,5 p.)
+    - Toinen perusteltu syy copypasten välttämiselle (0,5 p.)
+    - Yksi tilanne, jossa copypaste saman ohjelman sisällä voi olla perusteltua (0,5 p.)
+
+- b-kohta (1,5 p.):
+    - Feature branchien perusperiaate (0,25 p.)
+    - Vähintään yksi perusteltu hyvä puoli feature branchien käytössä (0,25 p.)
+    - Vähintään yksi perusteltu huono puoli feature branchien käytössä (0,25 p.)
+    - Trunk based developmentin perusperiaate (0,25 p.)
+    - Vähintään yksi perusteltu hyvä puoli trunk based developmentin käytössä (0,25 p.)
+    - Vähintään yksi perusteltu huono puoli trunk based developmentin käytössä (0,25 p.)
+
+- c-kohta (1,5 p.):
+    - Kerrottu testitietokannan käyttämisestä (0,25 p.)
+    - Kerrottu vähintään yksi perusteltu syy testitietokannan käyttämiselle (0,25 p.)
+    - Kerrottu stubien ja/tai mock-olioiden toimintaperiaate (0,25 p.)
+        - Jos on mainittu stubien ja/tai mock-olioiden käyttämisestä, mutta ei kerrottu toimintaperiaatteesta, niin 0,125 p.
+    - Yksi etu stubien ja/tai mock-olioiden käyttämisessä (0,25 p.)
+    - Toinen etu stubien ja/tai mock-olioiden käyttämisessä (0,25 p.)
+    - Mainittu eroista yksikkötestauksen ja integraatio- ja järjestelmätestauksen välillä tietokannan ja rajapintojen suhteen (0,25 p.)
+
+Perustelujen laatu vaikuttaa pisteisiin. Kukin alakohta on erillinen, joten yhden alakohdan erinomaisella vastauksella ei voi kompensoida esimerkiksi toisen alakohdan vastauksen puuttumista.
+
+Lähes kaikissa kohdissa hyväksyttiin hyvin monenlaisia vastauksia, kunhan ne olivat perusteltuja. Alla näkyvä malliratkaisu on yksi täydet pisteet tuova tapa vastata tehtävään.
+
+#### Malliratkaisu
+
+**(a)** Moneen paikkaan kopioidun koodin käyttö voi olla ongelmallista, jos kopioidun koodin toimintaa joudutaan muuttamaan. Tällöin muutokset pitää muistaa tehdä jokaiseen kohtaan erikseen, mikä hankaloittaa sovelluksen ylläpitoa ja on virhealtista. Jos toiminnallisuus olisi eristetty esimerkiksi omaan funktioonsa, niin riittäisi, että muutos tehdään vain yhteen paikkaan.
+
+Toinen peruste copypasten välttämiselle on se, että runsas copypasten käyttö saattaa kertoa matalasta koheesion asteesta. Tällä tarkoitetaan sitä, että kunkin metodin, luokan tai komponentin tulisi keskittyä tietyn yksittäisen toiminnallisuuden toteuttamiseen. Lähes vastaava periaate on single responsibility -periaate.
+
+Tietyissä tilanteissa copypasten käyttäminen voi kuitenkin olla perusteltua. Esimerkiksi rakennettaessa MVP-versiota (*minimum viable product*) voidaan copypastea käyttämällä nopeuttaa kehitystä. Tällöin otetaan niin sanottua teknistä velkaa. Jos koodi tulee pysyvään käyttöön, tulisi koodi refaktoroida myöhemmin. Vastaavasti jos koodi ei koskaan päädy tuotantoon, kehittäjät eivät ole joutuneet käyttämään aikaa refaktorointiin.
+
+**(b)** Feature branchit ovat versionhallinnan menetelmä, jossa muutokset toteutetaan omiin versionhallinnan haaroihinsa (*branch*). Yksittäinen kehittäjä tai kehittäjätiimi tekee esimerkiksi yhteen user storyyn liittyvät muutokset yhteen haaraan, ja toiminnallisuuden valmistuessa kyseinen haara yhdistetään päähaaraan. Feature branchien hyvä puoli on se, että muutokset pysyvät aina omassa haarassaan ennen yhdistämistä, jolloin päähaara ei voi rikkoutua kehitysvaiheessa feature branchin muutosten vaikutuksesta. Yksi varjopuoli on se, että haarojen yhdistäminen aiheuttaa usein konflikteja. Tämä korostuu erityisesti silloin, kun haarat ovat pitkäikäisiä ja niitä on useita. Konfliktien ratkominen voi olla työlästä ja aikaa vievää: pahimmassa tapauksessa seurauksena voi olla pieni integraatiohelvetti eli merge hell.
+
+Sen sijaan trunk based developmentissa pitkäikäisiä feature brancheja ei käytetä, vaan muutokset tehdään suoraan pääkehityshaaraan (*trunk*). Julkaistuista versioista saatetaan tehdä oma release branch. Hyvänä puolena on se, että menetelmä pakottaa kehittäjät tekemään pieniä muutoksia, jotka on helppo yhdistää päähaaraan. Näin ollen feature branchien integroimiseen liittyviä ongelmia ei pääse syntymään. Haasteena on kuitenkin se, että kehittäjien tulee olla hyvin kurinalaisia ja systemaattisia, jotta päähaara pysyy jatkuvasti toimivana ja huonoa koodia ei päädy muille kehittäjille.
+
+**(c)** Ohjelmiston yksikkötestauksessa voidaan hyödyntää tynkäkomponentteja, jotka voivat olla joko stubeja tai mock-olioita. Stubeihin on mahdollista kovakoodata esimerkiksi metodikutsujen paluuarvoja. Mock-olioiden avulla on mahdollista tarkkailla esimerkiksi sitä, kuinka monta kertaa ja millä arvoilla niiden määrittelemiä metodeja on kutsuttu.
+
+Hyvä puoli stubien ja mock-olioiden käyttämisessä on se, että niiden avulla voidaan testata ohjelmiston toimintaa ilman, että testit ovat riippuvaisia ulkoisista tekijöistä (esimerkiksi tietoliikenneyhteyksien toimivuudesta). Tällöin testit ovat helposti toistettavissa ja niiden suorittaminen on nopeampaa. Lisäksi Ilmatieteen laitoksen rajapinnan jatkuvasti muuttuvat säätiedot on helppoa korvata kovakoodatuilla tiedoilla, jolloin voidaan testata laajasti erilaisia tilanteita ja testien tulokset ovat helposti ennustettavissa (toisin kuin jatkuvasti muuttuvat säätiedot).
+
+Integraatio- ja järjestelmätestauksen tarkoituksena on testata yksittäisiä funktioita tai luokkia laajempia kokonaisuuksia. Tällöin testeissä, jotka tarvitsevat tietokantaa, on tärkeää käyttää erillään tuotantotietokannasta olevaa testitietokantaa. Tuotantotietokannan käyttäminen testauksessa voi johtaa esimerkiksi siihen, että testit muokkaavat tai poistavat oikeaa dataa. Samoin testitietokantaa käyttämällä testaaminen helpottuu huomattavasti, koska tietokannan tilaa on helpompi kontrolloida. Testitietokannan tulisi sisältää kattavasti realistista dataa, jotta erilaisia tilanteita voidaan testata mahdollisimman laajasti.
+
 ### Tehtävä 5
 
 Palataan ajassa hieman taaksepäin. Linkin https://gist.github.com/mluukkai/9093b1b3715b556ce85af32b571fb6de takana on koodia Kurpan kehityksen alkuajoilta. Kehitystiimin velositeetti oli projektin alussa huipputasoa, mutta Kurppamestari on huomannut vauhdin hiljenneen edellisten sprinttien aikana. Syyksi hidastumiseen diagnosoidaan koodiin pesiytynyt tekninen velka.