Instrucțiunea care a șters douăzeci și șase de limbi, dar pe cele greșite

I-am spus automatizării propriului site să reducă blogul la patru limbi. Două zile mai târziu am aflat că ștersese pe tăcute douăzeci și șase de limbi și de pe pagina principală, iar nici eu, nici vreun vizitator nu observase.

TL;DR

• O singură instrucțiune destinată secțiunii de blog s-a aplicat, în schimb, întregului site.
• 26 din cele 30 de limbi au dispărut de pe pagina principală, de pe pagina de CV și din toate textele de navigare.
• Nimic nu a picat, nimic nu a dat eroare 404, așa că nimeni nu și-a dat seama timp de două zile.
• Soluția a venit din istoricul git, nu din amintirea despre cum arăta site-ul înainte.
• Lecția reală: înainte ca o schimbare automatizată să ruleze, numește exact fișierele pe care le atinge, apoi citește lista aia înainte să se șteargă ceva.

De ce am vrut mai puține limbi, în primul rând

Site-ul meu ajunsese la treizeci de limbi în câteva luni: pagina principală, pagina de CV și un blog pe care îl actualizez aproape la câteva zile. Am mai scris despre cât de periculos poate fi asta: traducerea automată e suficient de fluentă cât să pară în regulă și suficient de greșită cât să te facă de râs, într-o limbă pe care tu personal n-o poți verifica. Pagina principală și CV-ul se schimbă rar, așa că puteam trăi cu riscul ăsta acolo. Blogul era altă poveste. Apar articole noi des și pur și simplu nu pot garanta calitatea traducerii unui articol proaspăt în estonă chiar în ziua publicării lui.

Așa că m-am decis să reduc setul de limbi în care se traduce blogul, la cele patru în care chiar am încredere să verific singur lucrurile: engleză, rusă, germană, cehă. Tot restul rămâne oprit pentru blog până găsesc un mod mai bun de verificare. Partea asta a planului era solidă. Ce a mers prost a fost cum am cerut-o.

O singură propoziție, domeniul greșit

Am dat o singură instrucțiune: păstrează blogul la patru limbi. Scurtă, precisă, sau așa credeam eu. Ce a rulat de fapt a atins trei lucruri diferite deodată. A redus corect folderele proprii de conținut ale blogului la cele patru limbi dorite. Dar a rescris și lista principală de limbi a site-ului, fișierul de configurare care spune ce limbi există în general, și a șters conținutul paginii principale și textele de navigare pentru celelalte douăzeci și șase.

Problema e că „blogul” și „lista de limbi a întregului site” trăiesc în același fișier de configurare. Nimic din fișierul ăla nu face distincția între limbile pe care le suportă blogul și limbile pe care le suportă site-ul. Scoți o limbă din listă și fiecare secțiune care citește de acolo, inclusiv pagina principală, o pierde dintr-o singură mișcare. Instrucțiunea mea a numit o secțiune. Schimbarea care a rulat de fapt a avut domeniul de aplicare al întregului site.

Iată partea care a făcut situația periculoasă, nu doar greșită: nimic nu a picat zgomotos. Nicio eroare, niciun 404, niciun build eșuat. Site-ul pur și simplu a încetat, pe tăcute, să mai genereze paginile principale și de CV pentru douăzeci și șase de limbi, iar comutatorul de limbă a încetat să le mai ofere. Un vizitator care obișnuia să citească site-ul în portugheză ajungea pur și simplu, în tăcere, pe versiunea în engleză. Ce lipsește pentru că a fost șters arată exact ca ceva care n-a existat niciodată, și niciuna dintre situații nu aruncă vreo eroare.

Au trecut două zile până am observat, și doar din întâmplare, în timp ce reparam cu totul altceva, când un link „Blog” din navigare ducea undeva ciudat pentru una dintre limbile pe care le credeam încă active. Linkul ăla singur, rămas în aer, a fost singurul fir vizibil către toată problema.

Ce a arătat de fapt diff-ul

Eșecul onest aici nu e greșeala de domeniu în sine. E faptul că n-am verificat niciodată lista fișierelor pe care schimbarea urma să le atingă de fapt, înainte s-o las să ruleze. Am citit o descriere de-o linie a ceea ce trebuia să facă și am presupus că descrie și ce a făcut. Nu a fost așa.

Repararea a început cu o singură întrebare: ce s-a schimbat și unde. Am făcut diff între site-ul live și ultimul commit dinainte de instrucțiunea „redu blogul”, iar răspunsul a fost imediat și fără echivoc: configurația principală a limbilor, folderul de conținut al paginii principale și douăzeci și șase de fișiere de texte pe limbă, niciunul dintre ele nici pe-aproape de directorul blogului. Git avea fiecare dintre fișierele astea exact cum fuseseră. Nimic nu se pierduse cu adevărat, doar fusese suprascris la deploy.

Am restaurat din istoric pagina principală, CV-ul și textele de navigare pentru toate cele treizeci de limbi și am lăsat folderul blogului exact atât de redus cât voiam: patru limbi, intenționat. A rămas un capăt liber. Link-ul de navigare „Blog”, pentru o limbă restaurată, ducea la o ediție de blog în limba aia care nu mai există. Nu merita să duplic patru articole în încă douăzeci și șase de limbi doar ca să umplu link-ul ăla, așa că am setat template-ul să redirecționeze către blogul în engleză, și l-am lăsat așa.

Ce aș verifica altfel data viitoare

Acum, înainte să las orice schimbare automatizată să atingă un site live, cu mai multe secțiuni, pun cu voce tare o întrebare în plus: numește exact fișierele pe care le va atinge asta, nu funcționalitatea pe care ar trebui s-o rezolve. Dacă răspunsul e vag, ăsta e semnalul să te oprești și să verifici, nu să rulezi și să vezi ce iese. Și înainte să se șteargă ceva, vreau lista reală de fișiere în fața mea, nu un rezumat de-o linie despre ce ar fi trebuit să însemne instrucțiunea. Un cuvânt de domeniu dintr-o instrucțiune, „blogul”, „echipa asta”, „doar frontend-ul”, nu e automat același lucru cu domeniul schimbării pe care o declanșează acea instrucțiune, iar cele două coincid doar dacă ceva a verificat chiar asta: exact întrebarea pe care ți-o întorc ție acum. Care e cea mai mică instrucțiune, cu domeniul cel mai clar definit, pe care ai dat-o de curând și care n-a fost niciodată verificată față de ce a atins de fapt?