Работи на моята машина: какво е, защо се случва и как да предотвратим

Ce înseamnă „Funcționează pe mașina mea”

„Funcționează pe mașina mea” — fraza pe care o spune un dezvoltator atunci când un coleg sau tester raportează o eroare, iar pe mașina dezvoltatorului această eroare nu se reproduce. La exterior pare o negare a problemei, dar tehnic situația este reală: codul poate funcționa într-un mediu și pica în altul. Diferența de un bit de configurație — și comportamentul aplicației se schimbă radical.

Fraza a devenit un meme în comunitatea IT pentru că este simultan adevărată și inutilă. Din perspectiva dezvoltatorului — codul chiar funcționează pe mașina lui. Din perspectiva echipei — problema există și trebuie rezolvată, nu justificată. Umorul situației este că dezvoltatorul spune adevărul, dar acest adevăr nu ajută la remedierea erorii. Meme-ul este atât de popular încât i s-au dedicat mii de postări pe Reddit, XKCD și conferințe DevOps.

Din perspectiva proceselor, fraza „funcționează pe mașina mea” este un indicator al problemelor de reproductibilitate a mediului. Dacă doi dezvoltatori nu pot obține același rezultat pe același cod — înseamnă că procesul de configurare a mediului nu este standardizat. Practica DevOps afirmă: mediul trebuie să fie reproductibil printr-o singură comandă din repository, fără acțiuni manuale.

De ce mediul local diferă de producție

Mediul local al dezvoltatorului aproape întotdeauna diferă de producție. Dezvoltatorul folosește macOS sau Windows, în timp ce serverul rulează pe Linux. Diferite sisteme de operare au diferite sisteme de fișiere, codificări, timing-uri de thread-uri și apeluri de sistem. Chiar dacă ambele medii sunt Linux — versiunea kernelului, glibc, OpenSSL pot diferi.

A doua cauză — setul de software instalat. Pe mașina dezvoltatorului poate fi instalată o versiune globală Node.js 20, iar în configurația CI/CD este specificată versiunea 18. Sau dezvoltatorul folosește PostgreSQL 16 local, iar în producție — PostgreSQL 14. Diferențele în versiunile minore adesea nu sunt vizibile, dar actualizările majore pot schimba comportamentul interogărilor SQL. Conform npm Inc., 67% dintre erorile legate de dependențe sunt cauzate de diferența în versiunile patch.

A treia cauză — condițiile de rețea. Pe mașina locală nu există întârzieri, limite de lățime de bandă și probleme DNS. În producție, orice cerere către un API extern poate dura 500 ms în loc de 5 ms. Timeout-uri, logica de retry, race conditions — toate aceste probleme se manifestă doar sub sarcină reală și în condiții reale de rețea. Emularea rețelei prin instrumente precum Toxiproxy ajută la identificarea acestor probleme înainte de deploy.

Cauze tipice ale nereproducerii erorii local

Prima cauză — lipsa datelor. Dezvoltatorul lucrează cu fixture-uri de test, iar în producție sunt milioane de înregistrări cu valori neașteptate. NULL într-un câmp pe care dezvoltatorul îl considera obligatoriu, un caracter Unicode într-un nume, un șir prea lung — toate acestea pot cauza erori nereproducibile pe baza de date locală cu date sintetice.

A doua cauză — diferite flaguri de compilare și build. Build-ul de release (Release/Distribution) poate diferi de cel de debug (Debug). Optimizările compilatorului, eliminarea logurilor de debug, inline-ul funcțiilor — toate acestea pot ascunde sau, dimpotrivă, manifesta erori. Exemplu tipic: în build-ul de debug funcționează un assert care pică în build-ul de release din cauza altei ordini de inițializare a variabilelor.

A treia cauză — cache-ul local și fișierele temporare. Dezvoltatorul poate să nu observe eroarea deoarece în browser sunt stocate în cache scripturi vechi, în Redis sunt salvate date învechite, iar în sistemul de fișiere atârnă fișiere temporare de la rulări anterioare. O pornire curată (mod incognito, ștergerea cache-ului, fresh install) reproduce adesea eroarea care nu se manifesta „de la sine”.

A patra cauză — conflicte între dependențele globale și locale. Instrumente precum Ruby gems, Python pip, Node.js npm pot avea pachete instalate global care „ajută” codul să funcționeze local, dar lipsesc în producție. Utilizarea mediilor virtuale (virtualenv, venv, nvm) izolează proiectul de instalațiile globale și face mediul reproductibil.

Impactul asupra muncii în echipă și încrederii

Fraza „funcționează pe mașina mea” distruge încrederea în echipă. Dacă un dezvoltator nu poate reproduce în mod regulat erorile, colegii încep să se îndoiască de competența sau minuțiozitatea testării sale. În timp, aceasta duce la micromanagement: fiecare modificare necesită verificare de către un al doilea dezvoltator, ceea ce încetinește dezvoltarea. Conform Google Project Aristotle, siguranța psihologică în echipă influențează direct productivitatea, iar disputele constante despre mediu sunt unul dintre factorii reducerii acesteia.

A doua problemă — încetinirea code review. Dacă un dezvoltator nu poate reproduce eroarea local, poate respinge pull request-ul colegului cu cuvintele „la mine funcționează — deci problema e la tine”. Aceasta provoacă conflicte și întârzie livrarea funcționalităților. Standardizarea mediului elimină acest conflict: dacă ambii dezvoltatori lucrează în același container Docker, întrebarea „la cine funcționează” își pierde sensul.

A treia problemă — pierderea erorilor în tracker. Erorile care „nu se reproduc la dezvoltator” sunt adesea închise cu mențiunea „nu se reproduce” (Cannot Reproduce). După o lună, eroarea apare în producție, iar remedierea ei costă de 10 ori mai mult. Regula: dacă o eroare se reproduce cel puțin la o persoană — ea există, indiferent dacă funcționează sau nu la dezvoltator.

Cum să standardizezi mediul dezvoltatorului

Prima și cea mai eficientă metodă — Docker. Întregul proiect trebuie să pornească prin docker-compose up fără acțiuni suplimentare. Baza de date, cache-ul, coada de mesaje, serverul web — totul se ridică în containere. Dezvoltatorul instalează doar Docker și Git. Restul — în interiorul containerelor. Aceasta garantează că toți membrii echipei au același mediu, indiferent de SO.

A doua metodă — manageri de versiuni. Dacă Docker nu este posibil (restricții de licență, infrastructură legacy), folosiți nvm (Node.js), rbenv (Ruby), pyenv (Python), sdkman (Java). Managerii de versiuni permit comutarea versiunilor de limbaje și instrumente în cadrul proiectului. Fișierele .nvmrc, .ruby-version, .python-version trebuie să fie în repository și verificate de CI/CD.

A treia metodă — Vagrant pentru mașini virtuale. Vagrant ridică o mașină virtuală cu un SO și configurație specificate pe deasupra VirtualBox sau VMware. În interiorul VM se instalează toate dependențele prin scripturi de provisioning (shell, Ansible, Puppet). Vagrant este mai greu decât Docker, dar oferă izolare completă la nivel de SO — util pentru proiecte care depind de o versiune specifică a kernelului Linux.

A patra — makefile și scripturi bootstrap. Chiar și un simplu Makefile cu ținte install, test, build, clean poate standardiza acțiunile de rutină. Comanda make install trebuie să instaleze toate dependențele, să configureze baza de date și să creeze date de test. Un singur punct de intrare pentru toți dezvoltatorii exclude erorile manuale la configurarea mediului.

Instrumente pentru prevenirea divergențelor de mediu

Instrumentul principal — lock-fișierele de dependențe. package-lock.json (npm), yarn.lock (Yarn), Podfile.lock (CocoaPods), pubspec.lock (Flutter) fixează versiunile exacte ale fiecărui pachet. Fără un lock-fișier, doi dezvoltatori care instalează dependențe în momente diferite pot obține versiuni minore diferite. Lock-fișierul trebuie să fie în repository și să nu fie editat manual.

Al doilea instrument — .env.example în repository. Un fișier-șablon al variabilelor de mediu cu comentarii. Dezvoltatorul îl copiază în .env și completează propriile valori. Pipeline-ul CI/CD verifică că toate variabilele obligatorii sunt setate. Conform GitLab 2023, echipele care folosesc .env.example reduc numărul de incidente legate de variabilele de mediu cu 40%.

Al treilea instrument — hook-uri pre-commit. Verificare automată care se rulează înainte de fiecare commit: linter, formatter, verificare de tipuri, teste. Dacă hook-urile sunt configurate la fel la toți dezvoltatorii, erorile de formatare sau tipuri care „au trecut pe mașina locală” nu vor ajunge în producție. Husky pentru JavaScript și pre-commit pentru Python sunt soluții populare.

Al patrulea — pipeline CI/CD care rulează testele într-un mediu curat. Dacă testele trec în CI, dar nu local — problema este în configurarea mediului local. Dacă testele nu trec în CI — pull request-ul nu este merge-uit. Această regulă strictă exclude pătrunderea erorilor care „funcționează local” în ramura principală.