Salut, sunt Ecaterina. Am terminat aplicația pentru lucrarea de licență și, sincer, am învățat chestii pe care nu le-aș fi ghicit la început: cum să îmi organizez codul ca să nu devină un haos, să nu subestimez importanța testelor unitare și, surprinzător, să îmi dau seama că și eu am nevoie de pauze regulate ca să nu mă blochez.
Voi ce ați descoperit pe parcurs când ați lucrat la proiecte mari? Ce v-a surprins și ce ați face diferit data viitoare? Aștept părerile și poveștile voastre!
Geanina:
Salut, Ecaterina! 🙋♀️ Felicitări pentru terminarea aplicației – știu cât de multă energie și răbdare se cere să duci un proiect de licență până la capăt.
Când am început eu să lucrez la un proiect de dimensiuni mari (un sistem de monitorizare a senzorilor pentru un laborator de robotică), am avut parte de câteva „aha‑momente” pe care le consider și eu utile de împărtășit:
- Modularitatea nu e doar un cuvânt la modă – la început am încercat să țin tot codul într-un singur repo și să-l împart doar prin comentarii. Apoi, când am vrut să adaug un nou tip de senzor, am constatat că totul se rupea în cele mai neașteptate locuri. Am învățat să separ funcționalitățile în module bine definite (ex:
sensor_manager,data_storage,ui). Acel pas a redus drastic timpul de debugging și a făcut ca noi membri din echipă să poată să se integreze rapid.
- Documentația în timp real – în loc să aștepți să termini totul și apoi să scrii un manual, am început să adaug doc‑stringuri și să actualizez README‑ul pe măsură ce adaug funcționalități noi. Astăzi, când revizuiesc codul, știu exact ce face fiecare clasă fără să mă uit în commit‑uri vechi. Cred că și tu vei găsi util să ai un „living document” pe parcurs.
- Testele de integrare = salvatorii de nopți – testele unitare erau de ajuns pentru logica simplă, dar când am început să combin mai multe componente (ex: citirea senzorului → procesare → trimitere către server), am dat peste bug‑uri subtile care nu apăreau în testele unitare. Am introdus un set mic de teste de integrare care rulează automat la fiecare push. În plus, am folosit
pytest‑covca să văd exact ce porțiuni de cod sunt acoperite.
- „Pomodoro” nu e doar un trend – la fel ca tine, am descoperit că pauzele regulate îmi mențin creativitatea. Am adoptat metoda 25/5 și, în plus, am început să fac „stretch breaks” la fiecare oră: 2‑3 minute de întindere, un pahar de apă și, dacă am timp, o scurtă plimbare pe coridor. Crede-mă, mintea își revine mult mai repede decât credeam.
- Feedback‑ul timpuriu de la utilizatori – am aruncat o versiune beta către colegii de la laborator și am încurajat feedback‑ul rapid. Am aflat că interfața era prea încărcată și că anumite grafice nu erau intuitive. Așa am reușit să fac ajustări înainte să fie prea târziu și să nu pierdem timp refactorizând totul la final.
Ce aș face diferit data viitoare?
- Aș planifica mai bine sprint‑urile și aș avea un backlog clar încă de la început, pentru a nu fi nevoită să „îmi improvizez” prioritățile în ultimele săptămâni.
- Aș investi mai mult timp în CI/CD de la start (pipeline‑uri de testare și build automat), astfel încât să nu mai am surprize la final.
Tu ce metodă de organizare a codului ți s-a părut cea mai eficientă? Ai folosit deja ceva tip git flow sau preferi un model mai simplu? Și, pe lângă pauzele, ai alte trucuri pentru a evita „burn‑out‑ul” în perioadele intense? Aștept cu nerăbdare să aflu și de la tine! 🚀