Salut, sunt Ilinca. Am terminat recent lucrarea de licență cu o aplicație software și mă întreb ce a mers și ce nu în procesul ăla. Eu am plecat de la o idee clară, am scris multă documentație, dar am pierdut mult timp în debugging și în integrarea UI‑ului cu cerințele teoretice. Coord. mi-a lăsat multă libertate, dar nu am avut un plan de testare clar și am ajuns să refac secțiuni întregi la ultima clipă.
Voi ce greșeli ați făcut și ce trucuri v-au salvat? Cum ați reușit să echilibrați partea de cod cu cea de scriere? Orice sfat e binevenit!
Carina:
Hei Ilinca, și eu am trecut printr‑o „aventură” similară cu a ta la finalul licenței, așa că îți înțeleg perfect frustrarea. Iată câteva lucruri care m‑au ajutat să ies din impas și să nu pierd total controlul asupra proiectului:
- Împărțirea pe „mini‑milestones” – În loc să te gândești la „scrierea întregii documentații” sau „finalizarea UI‑ului”, am creat task‑uri de 2‑3 zile (ex: „implementare login”, „scrierea capitolului de metodologie”). La fiecare milestone am făcut o mică revizuire și am marcat progresul. Asta mi‑a dat un sentiment de progres constant și m‑a împiedicat să am parte de „refaceri la ultima clipă”.
- Test‑driven development (TDD) la mică scară – Nu am avut timp să scriu teste exhaustive, dar am scris câteva teste unitare pentru funcțiile critice (de ex. validarea datelor, algoritmi de procesare). Chiar și 5‑10 teste m‑au salvat de bug‑uri care altfel ar fi rămas ascunse până la integrarea finală.
- Documentație incrementală – În loc să aștepți să termini tot codul și apoi să scrii totul, am adăugat note pe măsură ce implementam fiecare modul. Am folosit Markdown în repo‑ul Git, așa că documentația era mereu sincronizată cu codul. La final, a rămas doar să rafinez stilul și să adaug referințe.
- Feedback rapid de la coordonator – Am programat scurte întâlniri săptămânale (15‑20 min) în care îi arătam ce am terminat și ce blocaje am. Astfel, nu am ajuns să „descopăr” la final că ceva nu se potrivește cu așteptările lui. Dacă nu poți avea întâlniri regulate, poți trimite un email de status cu capturi de ecran și întrebări specifice.
- Version control și branch‑uri tematice – Folosirea branch‑urilor pentru fiecare funcționalitate a făcut refactorizările mult mai sigure. Dacă ceva nu merge, poți da back‑track cu un simplu
git checkoutfără să strici tot codul.
- „Pomodoro” pentru debugging – În loc să stai ore întregi în fața consolei, am setat intervale de 25 de minute de debugging intens, urmate de 5 minute de pauză. Asta a redus oboseala mentală și m‑a ajutat să privesc erorile cu ochi proaspeți.
- Plan de testare simplu, dar clar – Am scris un checklist de scenarii de test (funcționale, UI, performanță) și am alocat 10‑15% din timpul total proiectului pentru a le parcurge. Nu a fost perfect, dar a redus surprizele la livrare.
În plus, un mic truc pe care l‑am descoperit în ultima fază: folosirea unui „style guide” pentru UI (ex: Material Design). În loc să te chinui să găsești fiecare nuanță de culoare sau spațiere, am adoptat un set de componente predefinite, iar asta a scurtat mult timpul de integrare și a adus consistență vizuală.
Sper că aceste idei îți vin în ajutor. Dacă vrei să detaliez vreun punct (de ex. cum am setat testele unitare în Python/Java), spune-mi și îți trimit și niște snippet‑uri.
Succes cu finalizarea licenței și nu uita să te bucuri de rezultatul muncii tale – merită! 🚀