Ning ongi aeg praktikaperiood kokku võtta... Eelmise postituse lõpus mainisin:

Üleeile (reedel) sain uue ülesande, andmaks raamatupidajatele võimaluse valida, missuguse ettevõtte (Icefire-i alla kuulub mitu ettevõtet) palgal töötaja on ning missugune on tema töölepingu vorm. Vastavalt töötaja firmale ning töölepingu vormile peaks muutuma ka muu funktsionaalsus, näiteks lähetusele saatmine ja puhkused. Ma ei ole veel jõudnud ülesandesse põhjalikult süveneda, kuid tegemist peaks olema minu seni kõige mahukama ülesandega (latt ei ole kõrgel).

Antud ülesanne oli tõepoolest minu seni mahukaim, praeguseks on see aga juba üle trumbatud. On isegi natuke kurb, et just minu praktikaperioodi lõpus hakkasid tekkima ülesanded, millest reaalselt midagi rääkida oleks ja ülejäänud kolm kuud olid pigem kivist vee välja pigistamine.

Aga ülesandest lähemalt: Töötajatel saab paralleelselt olla mitu töölepingut, mistõttu hoiustatakse töölepinguid eraldi andmebaasitabelis. Iga lepingu kohta on tabelis teave, missuguse firmaga on leping sõlmitud ning milline on lepingu vorm. Firmasid hoitakse teises andmebaasitabelis, töölepingu vorme backendis enum-ina, kuigi tagantjärele olen hakanud mõtlema, et ehk oleks parem ka neid andmebaasis hoida.

Et firma olemasolevat administratiivrakendust, mille arendaja on tihtipeale hõivatud, mitte ära lõhkuda, ei tohtinud sellega seotud andmestruktuure muuta, mistõttu tuli luua igahommikune cron job, mis kopeeriks "vanad" töölepingud uude süsteemi ümber. Mitte just ideaalne lahendus, kuid siseveebi projektijuht haub plaani mind ka adminstratiivrakenduse muutmiseks "välja koolitada", mistõttu võib ka see tulevikus muutuda.

Seejärel pidin muutma mõningaid olemasolevaid süsteeme, et need kasutaksid uut andmestruktuuri ning ei eeldaks automaatselt, et kõik inimesed töötavad "emafirmas". Selle käigus selgus vajadus ühe PDFi genereerimise kood täielikult ümber kirjutada: Siseveebis on kaks kohta, kus genereeritakse mingisugune PDF, kumbki kasutas genereerimiseks erinevat meetodit, ning üks nendest, mis oli juhtumisi võetud vanast siseveebist ja kasutas nö. legacy meetodit, lihtsalt ei töötanud, mistõttu oli see hea moment selle ümber kirjutamiseks uuele meetodile. Lisaks sellele nõudsid need muudatused ka mitmete SQL päringute ümber kirjutamist ja puhkuste halduse frontend loogika muutmist.

Lõpetuseks pidin looma koha, kust töötajate lepinguid üldse hallata saaks - selle lõin töötaja profiili alla. Backendi osa polnud minu jaoks suurt midagi erilist muljet avaldavat - tavalised CRUD (create, read, update, delete) tegevused, kuid frontendis sain lõpuks ometi omal moel Reacti kirjutada. Selle tabeli loomise käigus suutsin enda jaoks välja kujundada "mustri", millest olen kinni pidanud ka järgmisi süsteeme luues: Reacti hookide kasutus, ainult functional componentid, täpselt paras hulk Reduxi kasutust jms.

Kokkuvõtva postituse, kui seda vaja on, jätan järgmiseks korraks, enne sooviks saada mõningast tagasisidet ning ehk ka mõningaid küsimusi/teemasid, millele seal pühenduda.