Modulārie praktiskie uzdevumi: Vibecoding un MI lietotņu izveide

Tu esi digitālo darba procesu un mazu lietotņu risinājumu arhitekts.

Es piedalos praktiskā Vibecoding nodarbībā. Mans mērķis ir izveidot pirmo funkcionējošo tīmekļa lietotnes prototipu, kas atrisina vienu konkrētu manas ikdienas darba procesa problēmu.

Mana procesa diagnostika:
[IEKOPĒ SAVAS 6 ATBILDES]

Piedāvā TIEŠI 3 dažādas, vienkāršas un praktiski uzbūvējamas lietotnes idejas, kas tieši risina manu 4. punktā aprakstīto problēmu.

ŠODIENAS PROTOTIPA ROBEŽAS:
- viena galvenā darba zona;
- pēc iespējas vienkārša lietotāja plūsma;
- sākotnējā versijā nav nepieciešama lietotāju autentifikācija;
- sākotnējā versijā nav nepieciešama kopīga datubāze;
- var izmantot pārlūka lokālu datu glabāšanu;
- prioritāte ir funkcionējošs prototips, nevis pilna produkcijas sistēma.

Katrai idejai norādi:
1. Nosaukumu.
2. Kādu problēmu tā atrisina.
3. Kāds ir galvenais lietotāja darbības cikls.
4. Kādi ir 3–5 galvenie ievades dati.
5. Kāds ir rezultāts.
6. Kāpēc šo ideju varētu izveidot kā pirmo prototipu vienas nodarbības laikā.

Neizdomā sarežģītu portālu vai pilna mēroga biznesa sistēmu.

Tu esi pieredzējis biznesa procesu analītiķis un lietotņu arhitekts.

Mana izvēlētā lietotne:
[IEVIETO IDEJAS NOSAUKUMU UN APRAKSTU]

Mana procesa diagnostika:
[IEVIETO SAVU DIAGNOSTIKU]

Pirms raksti specifikāciju, uzdod man ne vairāk kā 4 īsus jautājumus, kas nepieciešami, lai precīzi saprastu:
1. lietotāja galveno darbību secību;
2. svarīgākos datus un noteikumus;
3. iespējamos kļūdu vai robežgadījumus;
4. kādu rezultātu lietotājam jāsaņem.

Pēc manām atbildēm izveido īsu, praktisku lietotnes MINI-SPECIFIKĀCIJU ar šādu struktūru:

# 1. Problēma (Ko lietotne risina?)
# 2. Lietotājs (Kas to izmantos?)
# 3. Galvenā lietotāja plūsma (Soli pa solim)
# 4. Ievaddati (Kādi dati jāievada vai jāizvēlas?)
# 5. Procesa loģika (Aprēķini, pārbaudes, filtrēšana)
# 6. Rezultāts (Ko lietotājs redz, nokopē vai saglabā?)
# 7. Šīs versijas robežas (Ko apzināti NETAISĀM šodien?)
# 8. Acceptance Criteria (5–8 konkrēti pārbaudes kritēriji formā: „Lietotājs var...” vai „Ja..., tad...”)

Balstoties uz manu mini-specifikāciju, izveido vienas galvenās lietotnes ekrāna struktūru.

Norādi:
1. Galvenes saturu.
2. Galveno ievades zonu.
3. Galveno darbības pogu.
4. Rezultātu zonu.
5. Filtrus vai meklēšanu, ja nepieciešams.
6. Kopsavilkuma/KPI elementus, ja tie dod vērtību.

Prioritāte ir vienkāršība un skaidra lietotāja plūsma. Neizdomā elementus tikai dekorācijai.

Izveido šīs lietotnes galvenā ekrāna dizainu:

[IEKOPĒ MINI-SPECIFIKĀCIJU]

Prioritātes:
- vienkārša lietotāja plūsma;
- skaidra galvenā darbība;
- minimāls vizuālais troksnis;
- desktop-first izkārtojums;
- skaidri atšķirama ievade un rezultāts.

Izveido pirmo variantu. Pēc tam es došu konkrētus labojumus.

Izveido funkcionējošu tīmekļa lietotnes PROTOTIPU, balstoties uz zemāk esošo mini-specifikāciju.

[IEKOPĒ MINI-SPECIFIKĀCIJU]

DIZAINS:
[IEKOPĒ UI APRAKSTU VAI STITCH REZULTĀTU]

IZSTRĀDES PRINCIPI:
- vispirms nodrošini galveno lietotāja plūsmu;
- saglabā risinājumu pēc iespējas vienkāršu;
- izmanto modulāru projekta struktūru (skaidri sadalītas komponentes un faili);
- nedublē loģiku;
- saglabā projekta kontekstu un esošo funkcionējošo uzvedību;
- izmanto lokālu datu glabāšanu (localStorage), ja ārēja datubāze nav nepieciešama;
- neievies lieku autentifikāciju, ja tā nav nepieciešama šī prototipa Acceptance Criteria izpildei.

Pirms būvēšanas īsi norādi:
1. ko tu plāno izveidot;
2. kādi ir galvenie lietotāja darbības soļi;
3. kā tu pārbaudīsi Acceptance Criteria.

Pēc tam izveido pirmo funkcionējošo versiju.

Es testēju savu lietotni un atradu problēmu.

MANA DARBĪBA: [Ko es izdarīju]
SAGAIDĀMAIS REZULTĀTS: [Kas bija jānotiek]
FAKTISKAIS REZULTĀTS: [Kas faktiski notika]
PROBLĒMA: [Apraksti problēmu vai iekopē kļūdu no konsoles]

Vispirms analizē iespējamo problēmas cēloni.

Pirms izmaiņu veikšanas īsi norādi:
1. kur atrodas iespējamais cēlonis;
2. kāpēc problēma rodas;
3. kuras projekta daļas būtu jāmaina.

Pēc tam veic TIKAI minimālās nepieciešamās izmaiņas.

Prasības:
- nesabojā jau funkcionējošās funkcijas;
- nemaini arhitektūru bez vajadzības;
- neveido nevajadzīgu workaround;
- saglabā iepriekšējos Acceptance Criteria.

Pēc izmaiņām pārbaudi, vai problēma ir novērsta.

Mana lietotne pašlaik darbojas.

Vēlos pievienot TIKAI VIENU jaunu funkciju:
[APRAKSTI VIENU FUNKCIJU, piem., Poga «Eksportēt uz CSV»]

Vēlamā uzvedība:
[KO LIETOTĀJS DARA]

Sagaidāmais rezultāts:
[KO LIETOTĀJS REDZ]

Acceptance Criteria šai funkcijai:
1. [...]
2. [...]
3. [...]

Pirms izmaiņu veikšanas:
- nosaki, kurā projekta daļā funkcija jāievieš;
- saglabā visu pašreizējo funkcionējošo uzvedību;
- neveido citas jaunas funkcijas.

Pēc izmaiņu veikšanas pārbaudi jauno funkciju un norādi, kā es to varu manuāli notestēt.