Home

PRKL - yleistä projektista

Ohjelmistoa on tehty kolmen ohjelmistotuotantoprojekti-kurssin ajan, aloitettu keväällä 2020 ja jatkettu syksyllä 2020, keväällä 2021 sekä keväällä 2022. Ohjelmisto on Helsingin yliopiston TOSKA-ryhmän tilaama, ja sitä on jo käytetty yliopiston kursseilla ryhmäjakoihin. Tämän wiki-sivuston on tarkoitus tehdä projektin mahdollisesta jatkokehityksestä seuraavalla Ohtuprojekti-kurssilla mahdollisimman jouhevaa ja kivutonta. Seuraavassa yleiskatsaus siitä, miten projektia on toteutettu. Tulevat ryhmät luonnollisesti toteuttavat projektia parhaaksi katsomillaan tavoilla, eivätkä ota näitä periaatteita annettuina.

Yhteiset käytännöt kevät 2022

Product backlog

Projektin tilaa ja backlogia ylläpidetään Backlog-boardilla.

• Kevät 2022-sarakkeesseen (ylimmäksi) lisätään uudet featuret. Nämä ovat pääasiassa user storyja, mutta voivat olla muitakin, esim. bugikorjauksia tai refaktorointeja tms. Uudet issuet voivat olla keskeneräisiä.
• Uudet issuet merkitään labelilla New, jotta product owner / asiakas huomaa sen.
• Kaikista user storyistä pitää tehdä Githubin issue.
• User storyt jaetaan pienempiin tehtäviin käyttämällä Markdownin tickboxeja.
• Backlog (DEEP) -sarake pidetään prioriteettijärjestyksessä. Prioriteetin päättää asiakas / product owner.
• Tiimi siirtää Backlog (DEEP) sarakkeesta ylimmän issuen työn alle eli sarakkeeseen In progress kiinnittäen huomiota, että työn alla ei ole liian monta issueta.
• Issuet voidaan tiimin jäsenten toimesta täsmentää tai jakaa myös ollessaan työn alla.
• Issuet assignataan tiimin jäsenille.

Storyjen seuranta.

• Google sheetiin kirjataan ylös seuraavat päivämäärät: siirto backlogiin, ottaminen työn alle, feature tuotannossa.
• Jos työn alla oleva issue jaeteen kahdeksi, uuden osa-issuen aloituspäiviksi kirjataan alkuperäisen issuen päivämäärät.

Product backlogin groomaus

• DEEP: Detailed Appropriately, Estimates, Emergent, Prioritized
• INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable
• Estimointi: Small, medium, epic.
• Userstorylle määritellään hyväksymiskriteerit.

Definition of done

• Feature toimii.
• Featurelle on testit ja kaikki testit menevät läpi.
• Koodi on katselmoitu pull requestin yhteydessä
• Product owner on hyväksynyt

Definition of Done mukainen feature esitellään Asiakkaalle, jonka jälkeen se viedään tuotantoon. Tuotantoonvientipäivä kirjataan Google Sheetiin.

Tiimin aikataulut

• Viikon tapaamiset pyritään sopimaan edellisellä viikolla. Tapaamisten vakioaika yleensä klo 12 (muutetaan tarpeen mukaan).
• Yhteinen Google Sheets kalenteri.

Tapaamiset

• Daily palaverit pidetään lyhyinä, tavoite alle 15 minuuttia.
• Dailyssä käydään läpi mitä ollaan tehty ja mitä ollaan tekemässä seuraavaksi.
• Muut tapaamiset pyritään myös pitämään kohtuullisen lyhyinä, tavoite enintään 60 minuuttia.
• Lyhyet 15 min tapaamiset pideteen Discordissa ja pidemmät Zoomissa.

Discord

• Yhteistyö - parikoodaus - teknistä apua - sovitaan discordissa.
• Mitä teen nyt -kanavalla ilmoitetaan jos on toteuttamassa muiden tekemisiin vaikuttavia muutoksia.

Tech Stack

• Node 12
• React 16
• Postgres 12
• GraphQL (TypeGraphQL)
• Apollo Client

Material UI

Projekti vaihtoi kolmannessa iteraatiossa UI frameworkin Semanticista Materialiin. Materialin komponenttien tyylitys on toteutettu pääosin erillisillä importatuilla tyylitiedostoilla kansiosta /client/styles. Jotkut tiedostot kuitenkin käyttävät omia sisäisiä useStyles-metodeitaan ilman erillisiä importattuja tyylitiedostojaan. Näiden kahden tyylittämistavan sekoittamisen kanssa ei esiintynyt ongelmia, mutta selkeyden vuoksi olisi mahdollista refaktoroida projekti käyttämään vain jompaa kumpaa. Jos Materialin dropdownien kanssa ilmenee päänvaivaa, suosittelee kolmas iteraatio tarkastelemaan tiedoston CourseList.js sisäistä Dropdown-muuttujaa.

Linkki Materialin dokumentaatioon

Apollo Client

Projektissa alettiin siirtää kaikkea frontendin tilaa (state) Apollo Clientillä hallittavaksi. Apollo Client soveltuu sellaisen tilan säilömiseen, jota tarvitaan useammassa komponentissa. Apollo Clientin käyttö on tapauskohtaista. Tilaa voi lukea ja muokata joko GraphQL-kyselyillä, tai kirjaston omilla muuttujatyypeillä. Komponentin sisäinen tila, jota ei tarvita missään muualla, kannattaa silti luultavasti toteuttaa Reactin useState-hookilla. Osaa tilasta säilytetään vielä react-hookstore:ssa, joka tulisi deprekoida. (#286)

Linkki Apollo Clientin dokumentaatioon

Viestintäkanavat

Ensimmäisessä iteraatiossa tiimi käytti Slackia. Slack-kanavalle pääsyä voi pyytää niin ikään ryhmän ohjaajalta tai asiakkaalta. Slackista voi löytää kevään ryhmän jäseniä ja keskusteluja, sekä muita TOSKA-ryhmän jäseniä.

Toinen iteraatio suoritettiin kokonaan etätyöskentelynä korona-rajoituksista johtuen. Tiimi käytti Discordia kaikkeen viestintään. Discord-kanavalle pääsyä voi pyytää ryhmän ohjaajalta tai asiakkaalta. Discord-kanavalta saattaa löytyä syksyn ryhmän jäseniä ja keskustelut yms. materiaalit.

Kolmas iteraatio jatkoi korona-rajoituksien vuoksi etätyöskentelyä. Viestintään käytettiin toisen ryhmän luomaa Discord-kanavaa, jonne kolmannelle iteraatiolle luotiin oma alikanavansa. Kevään 2022 ryhmä jatkoi saman Discord-kanavan käyttöä.

Projektin poistaminen ja uudelleen lisääminen omalle koneelle

• Pysäytä ensin projekti docker-compose down ja/tai varmista docker ps ettei mikään kontti ole käytössä.
• Poista projektikansio rm prkl -rf
• Dockerin tyhjennys docker system prune -a. Tämä poistaa myös välimuistin, joten kaikki tarpeellinen joudutaan lataamaan uudestaan.
• Repon kloonaaminen git clone [email protected]:UniversityOfHelsinkiCS/prkl.git.
• Siirry projektikansioon cd prkl.
• Mene trunk haaraan git checkout trunk. Devaaminen tehdään trunk haaraan.
• Käynnistä docker-compose up (voi kestää noin 8 minuuttia mutta seuraavat kerrat menee nopeasti)