ServiceGSM.eu
Instalează aplicația pe telefon
Cele mai importante lucruri dintr-un program de service nu se văd niciodată pe ecran. Nu butonul de „Salvează" contează, ci ce se întâmplă în secunda de după el: unde ajunge fișa, cine o mai poate citi, ce se întâmplă dacă doi tehnicieni scriu în același timp, și dacă peste doi ani totul e încă la locul lui.
În ultimele săptămâni am lucrat exact la stratul ăsta invizibil din ServiceGSM.eu. E cea mai mare schimbare tehnică din istoria platformei și, dacă am făcut-o bine, tu nu ar trebui să observi absolut nimic — în afară de faptul că totul merge la fel, dar pe o fundație mult mai solidă.
Orice aplicație vorbește cu baza ei de date. Multă vreme, ServiceGSM.eu a făcut asta „de mână": fiecare pagină își scria singură întrebările către bază, în peste 440 de locuri diferite din cod. Funcționa, dar semăna cu un service în care fiecare tehnician își ține sculele în alt sertar — merge foarte bine cât timp știi exact unde e fiecare, și devine greu de controlat pe măsură ce crește.
Am trecut totul pe un ORM. Pe scurt, în loc ca fiecare pagină să discute direct cu baza de date, există acum un singur strat prin care trece tot: o descriere clară a fiecărui tip de informație — fișă de reparație, client, produs, factură, certificat de garanție — și un set unic de reguli aplicate automat oriunde apar datele alea. Astăzi platforma are 94 de asemenea descrieri și un istoric versionat al fiecărei modificări de structură, 29 până acum.
Traducerea practică: regulile de siguranță nu mai depind de memoria celui care scrie codul. Sunt aplicate în același fel, în fiecare pagină, de fiecare dată.
Ca să rămână separate datele firmelor. ServiceGSM.eu găzduiește multe service-uri pe aceeași platformă, iar granița dintre ele e cea mai importantă linie din tot sistemul. Pe lângă filtrarea din aplicație, baza de date impune ea însăși izolarea, la nivel de rând, pe 91 de tabele: chiar dacă o interogare ar uita filtrul, baza nu returnează rândurile altei firme. Noul strat setează contextul firmei la începutul fiecărei operațiuni, nu o dată la conectare — o diferență care contează exact în momentele aglomerate, când mai multe cereri se succed rapid.
Ca să meargă bine sub trafic real. Contoarele de bonuri și scăderile de stoc sunt acum protejate explicit atunci când două operațiuni ating același rând în aceeași secundă. E genul de lucru care nu se vede niciodată la un client pe zi și devine vizibil exact în ziua în care ai zece.
Ca să putem construi mai repede peste. Modulele noi din ultimele luni — acordul clientului pentru reparație, reparațiile B2B, e-Factura, exportul GDPR — s-au adăugat peste un strat care fusese gândit pentru o aplicație mult mai mică. Fundația nouă înseamnă că următoarele funcționalități vin mai repede și cu mai puțină grijă la efecte colaterale.
Ca structura bazei să fie versionată. Fiecare modificare de structură are acum un pas propriu, numerotat și reversibil, aplicat identic peste tot. Nu mai există „merge pe server, dar nu știu exact de ce".
Prima decizie, și cea mai importantă, a fost să NU facem totul deodată. Am împărțit lucrarea în șapte valuri, iar valurile mari în sub-etape: blogul, certificatele de garanție, fișele de reparație, contractele, clienții și zona GDPR, integrarea OLX și Google Drive, plățile, autentificarea, Gestiunea, e-Factura, zona de superadmin. Fiecare etapă a fost o schimbare de sine stătătoare, verificată complet înainte să înceapă următoarea — 187 de pași în total.
Verificarea a fost partea în care am investit cel mai mult, și e metoda de care sunt cel mai mulțumit. Înainte de fiecare etapă, capturam paginile reale așa cum le vede utilizatorul — HTML-ul randat și răspunsurile aplicației — pentru mai multe firme deodată, cu date reale, inclusiv cazurile urâte: firme fără stoc, căutări cu apostrof și caractere speciale, liste goale. După rescriere, rulam aceleași capturi și le comparam caracter cu caracter. Diferență zero însemna etapă bună. Orice diferență, oricât de mică, era investigată până la capăt înainte de a merge mai departe
Când citești atent 50.000 de linii de cod, găsești inevitabil lucruri de rafinat. Câteva dintre ele au ajuns direct în platformă:
Scăderea stocului la consumul de piese pe o reparație e acum protejată la operațiuni simultane, chiar dacă modalul trimite mai multe piese deodată.
Linkul de activare din emailul de înregistrare se consumă acum în toate situațiile în care un cont devine activ — prin plată, prin cod promoțional sau prin activare manuală — nu doar pe traseul clasic.
Formatul datelor scrise în bază a fost unificat, ca sortările și filtrele pe perioade să dea același rezultat indiferent de modulul care a scris rândul.
Rutele rămase în urmă după ce câteva ecrane au devenit ferestre modale au fost curățate, iar câteva câmpuri afișate în modalul de cerere GDPR se citesc acum pe nume, nu pe poziție.
Verificările automate de expirare a licențelor și cele de retenție rulează acum garantat în mediul de producție, nu doar la pornirea manuală a aplicației.
Niciuna dintre ele nu bloca activitatea de zi cu zi. Sunt exact genul de detalii pe care nu le vezi până nu te uiți sistematic — și motivul pentru care merită să te uiți sistematic.
Nimic, la nivel de utilizare. Aceleași ecrane, aceleași butoane, aceleași documente printate, aceleași date. Migrarea a fost livrată în producție pe 1 septembrie 2026, iar fișele, clienții, facturile și rapoartele tale sunt exact acolo unde erau.
Ce se schimbă e ce urmează. Funcționalitățile noi se pot construi acum mai repede și cu mai multă încredere, iar regulile de protecție a datelor sunt aplicate uniform, prin proiectare, nu prin disciplină.
E genul de lucrare pe care un furnizor de software o poate amâna la nesfârșit, pentru că nimeni nu o cere direct. Am ales să o facem acum, cât timp platforma e încă suficient de mică pentru a fi rescrisă cu grijă și verificată pagină cu pagină — și suficient de mare încât să conteze că am făcut-o.
