(Acest articol a fost publicat pentru prima dată pe Rsarcinași cu amabilitate a contribuit la R-bloggeri). (Puteți raporta problema legată de conținutul acestei pagini aici)
Doriți să vă distribuiți conținutul pe R-bloggeri? dați clic aici dacă aveți un blog, sau aici dacă nu aveți.
Puteți citi postarea originală în formatul său original pe site-ul web Rtask de ThinkR aici: Am ales React pentru a o învăța. AI a scris-o pentru noi.
Jurnalul unei rescrieri, episodul 1 din 4.
În februarie 2026 am ales React pentru a reconstrui un instrument intern, știind foarte bine că va fi nevoie de două ori mai lung decât să o faci în R. A fost o tranzacție deliberată: nu cumpărăm o aplicație, ne cumpăram abilități.
În iunie, la jumătatea drumului, cu două etape deja livrate, am oprit totul și ne-am întors la R.
Iată cele trei motive. Doar unul dintre ele este „ne-am înșelat”. Cel care a rezolvat-o este mai incomod decât atât: învățarea pentru care plătim o primă pur și simplu nu se întâmplase niciodatăpentru că codul ajungea mai repede decât am putut să-l citim.
StaffPuzzle este instrumentul nostru intern de personal: cine lucrează în ce, care jumătate de zi. Versiunea 1 este o aplicație Shiny numai în citire, cu 1.200 de linii, care rulează de ani de zile.
Versiunea 2 a fost menită să adauge scriere în Google Calendar, un mod de simulare și indicatori istorici. Am luat decizia stivei de două ori, la o distanță de patru luni, iar a doua a anulat-o pe prima. Ambele sunt notate, cu criteriile lor. Acesta este ceea ce face povestea povestibilă și, după cum vom vedea, este și ceea ce a făcut-o posibilă.
Acest serial acoperă cele patru luni care au urmat, în patru episoade. Se termină cu numerele reale: cât costă rescrierea, cât costă găzduirea și cât valorează licența pe care am evitat-o.
19 februarie: alegerea React
Trei opțiuni pe masă: toate JavaScript (React, Supabase), toate R (HTMX brut pe instalator brut2) sau un hibrid. Tabelul cu criterii a fost explicit și merită citit exact așa cum a fost scris:
| Criteriu | Opțiunea A: Reacționează | Opțiunea B: R | Patru luni mai târziu |
|---|---|---|---|
| Învățarea frontend-ului modern | Puternic | Slab | nu sa întâmplat niciodată |
| Timp de piață | ~19-24 jumatati de zile | ~12 jumatati de zile | ținută |
| Reutilizarea R-ului existent | Nici unul | Total | ținută |
| Transferabilitate la alte proiecte web | Ridicat | Scăzut | criteriu greșit |
| Interactivitate bogată | Natural | Dificil | fals de fapt |
Uită-te la al doilea rând. Știam că React va costa de două ori mai mult și am ales-o oricum. Aceasta nu este naivitate, este un comerț deliberat. Echipa este de șase persoane, cunoaște R și nu are aproape nicio expunere la stivele web moderne; versiunea 1 funcționează, nu există urgență. Arhitectura Decizie Record (ADR) spune atât de clar: confortul echipei cu React este „junior”, și aceasta este „o investiție deliberată, nu un activ pe care îl deținem deja”.
Cu alte cuvinte, decizia din februarie nu a fost cumpărarea unei aplicații. Era să cumpere abilități și să accepte să plătească pentru ele în întârziere.
Înregistrarea deciziei de arhitectură: un document care înregistrează o alegere semnificativă a arhitecturii software și raționamentul din spatele acesteia.
Opțiunea care nu era în tabel
Poate ați observat: „stay on Shiny” nu există. Cele trei opțiuni examinate au fost all-JavaScript, all-R pe HTMX și un hibrid. Niciunul dintre ei nu a însemnat să păstreze instrumentul așa cum era și să adauge ceea ce îi lipsea.
Aceasta nu a fost o neglijare. Întrebarea fusese soluționată în amonte, în brief-ul de proiect scris cu o lună mai devreme, la rubrica „Constrângeri tehnice”:
Stivă țintă: ieșire din Shiny, arhitectură REST, site web clasic.
Scris acolo, la același nivel cu cotele Google API și gestionarea token-ului OAuth. Dar cotele Google sunt o constrângere: ne sunt impuse. „Exit Shiny” este o decizie. Depunerea unei decizii sub constrângeri o scoate din dezbatere. Nu te certa cu o constrângere, ci o rezolvi.
Nimic nu ne-a obligat să părăsim Shiny. Scrierea într-un calendar, simularea, istoricizarea indicatorilor: Shiny poate face toate acestea. Așa că ADR din februarie a comparat cu sârguință trei opțiuni în interiorul unui perimetru pe care nimeni nu l-a justificat. Iar în iunie, când am redeschis dosarul, am revenit pe rând peste fiecare criteriu fără să punem la îndoială vreodată perimetrul.
Ce contează pentru ceea ce urmează. O decizie justificată de învățare este valabilă numai dacă învățarea are loc. Aceasta este o ipoteză, nu un atu și poate fi verificată.
3 iunie: întoarcere
Patru luni mai târziu, două etape livrate în React, echipa redeschide dosarul. Din aceasta iese o a doua decizie care o anulează pe prima. Trei lucruri s-au mutat și nu sunt de aceeași natură.
Unu: varianta pe care o refuzasem nu mai exista
În februarie, opțiunea R de pe masă a fost HTMX brut pe instalator brut2. Scrierea HTML manual, setarea manuală a atributelor. A fost o critică justă și a cântărit.
Între timp, două pachete R au fost lansate, {htmxr} şi {alpiner}care dau acelei abordări abstracțiile R de nivel înalt care îi lipseau. Opțiunea B a lunii iunie nu este opțiunea B a lunii februarie. Nu este același lucru cu a fi greșit: lumea se schimbase, iar decizia nu avea niciun mecanism pentru a observa asta de la sine.
Doi: două dintre argumente au fost pur și simplu false
Tabelul din februarie a evaluat interactivitatea bogată ca fiind „dificilă” pe partea HTMX, cu drag and drop ca exemplu. În iunie, cineva a mers și a citit codul React care fusese de fapt scris: nu există drag and drop. Este o selecție lasso, care este exact ceea ce {alpiner} face nativ. Argumentul era apărarea unei greutăți care nu exista.
Al doilea are nevoie de mai multă îngrijire. Criteriul spunea: abilitățile de reacție sunt „foarte transferabile către alte proiecte web”, abilitățile R și mai puțin. Este adevărat și este un criteriu greșit. Măsoară ceea ce un dezvoltator duce pe CV, nu ceea ce acumulează o companie. Pentru o firmă a cărei afacere este R, aprofundarea în R nu este transferabilitate scăzută: este principalul activ din ce în ce mai gros. Menținerea pachetelor îndreptate către CRAN ne face mai vizibili și mai capabili decât ar fi avut vreodată o cunoaștere de suprafață a React.
Trei: învățarea nu se întâmplase
Acesta este cel care doare, și este cel care a stabilit decizia. ADR-ul lui June o pune într-o singură propoziție:
Learning React, motivația centrală a deciziei din februarie, nu se întâmplă în practică: dezvoltatorul nu are timp să citească codul generat de AI, astfel încât obiectivul de competențe nu este îndeplinit.
ADR-003, 3 iunie 2026
Merită să cântăriți ce spune asta. Singura justificare pentru patru luni de cost suplimentar a fost competențele. Codul fusese scris, aplicația funcționa, reperele au fost livrate. Iar beneficiul care a plătit pentru costul suplimentar nu se materializase.
Cu ajutorul unei AI, o decizie de stivă justificată de învățare se poate sabota. Codul ajunge mai repede decât înțelegi, livrarea merge înainte, iar iluzia rămâne până când cineva întreabă să vadă ce s-a învățat. Subiectul depășește cu mult acest articol și vom reveni asupra lui; aici este suficient de remarcat că a schimbat o decizie tehnică la jumătatea unui proiect.
Cât a costat: prețul întoarcerii în U
O inversare nu este gratuită, iar ADR-ul din iunie își listează propriile dezavantaje înainte de a încheia.
Primul nu este tehnic:
- Refacerea comunicării cu utilizatorii noștri interni. Schimbarea direcției tehnice la mijlocul proiectului, în fața oamenilor care așteaptă un instrument, necesită o explicație pe care preferați să nu fiți nevoită să o oferiți.
- Stabilizarea pachetelor încă experimentale pentru a le pune în producție.
- Factorul autobuz: ecosistemul ales de noi are un singur întreținător principal și este aceeași persoană cu dezvoltatorul proiectului.
- Salvarea valorii documentare a codului React înainte de a-l șterge: tipurile și testele descriau un model de date care era încă valabil.
Aritmetica, însă, a fost favorabilă: șase până la opt jumătate de zile pentru a reface totul, față de opt până la zece pentru a termina în React. O dovadă a conceptului scrisă imediat după aceea, 280 de linii de R reproducând ecranul principal la 70 de milisecunde per solicitare, a transformat acea estimare într-un angajament.
Cifrele sunt cele care ne-au convins. Nu ei sunt cei care au decis.
Trei luni mai târziu: unde suntem
Aplicația rulează în producție, scrie în calendare și își istoricizează indicatorii. Raportul teste-cod a trecut de la 0,26 până la 0,77: 544 de teste, fără browser, o singură limbă din calendar până la ecran.
Acesta este câștigul pe care nu l-am anticipat. Interfața a devenit o funcție pură de la date la HTML, este testată ca și restul codului, fără browser și fără capturi de ecran. Am justificat revenirea prin consistența limbajului; ceea ce am primit cel mai valoros este testabilitatea.
Și un beneficiu care nu se afla deloc în tabel: aplicația a devenit primul caz real de producție pentru propriile noastre pachete, cele din hyperverse, pe care niciun exemplu demo nu ni l-ar fi oferit vreodată.
Ceea ce luăm
Scrierea deciziilor este ceea ce vă permite să le anulați. Aceasta este lecția principală și sună banal până când ai nevoie de ea. În iunie, nimeni nu a trebuit să reconstituie din memorie de ce a fost ales React: criteriile au fost scrise, datate, ponderate. A fost de ajuns să treci peste ele unul câte unul și să vezi care nu mai ține. Fără acel document, discuția ar fi fost despre oameni, despre cine a avut dreptate, nu despre criterii.
Separați „lumea s-a schimbat” de „ne-am înșelat”. Dintre cele trei motive, doar unul este o eroare de judecată: argumentul drag-and-drop, pe care citirea codului l-ar fi infirmat încă din februarie. Celelalte două sunt de alt fel: a apărut un instrument, iar o ipoteză despre noi înșine s-a dovedit a fi falsă. Confuzia celor trei produce fie vinovăție inutilă, fie incapacitatea de a se întoarce.
O decizie justificată de un beneficiu non-tehnic trebuie să-și programeze propria verificare. Februarie a cumpărat învățarea. Nimeni nu plănuise să verifice dacă sosește. Am aflat întâmplător, patru luni mai târziu, redeschiderea dosarului din alt motiv. Acesta este singurul lucru pe care l-am face diferit: dacă un criteriu decide, are nevoie de o dată de revizuire.
Am face-o din nou. Probabil că vom alege din nou React, în februarie 2026, cu ceea ce știam atunci. Asta face povestea interesantă: întoarcerea nu este corectarea unei gafe, ci modul în care se comportă o decizie atunci când ți-ai dat osteneala să o notezi.
Aplicația dvs. Shiny a depășit de la sine și vă întrebați ce să faceți cu ea? Îl citim și vă dăm înapoi o notă care spune acest lucru, inclusiv atunci când răspunsul este „lasă-l în pace”. Scrieți-ne pe două rânduri: dimensiunea aplicației dvs. și cât timp rulează.
Jurnalul unei rescrieripatru episoade:
- Am ales React pentru a-l învăța. AI a scris-o pentru noi. (Eşti aici)
- Prima mea încercare de a porta o aplicație Shiny a eșuat și nu dintr-un motiv tehnic (29 septembrie 2026)
- Am părăsit platforma gestionată. Iată factura reală. (6 octombrie 2026)
- Cinci semne că aplicația ta Shiny a depășit Shiny (13 octombrie 2026)
Cele două decizii citate sunt Arhitecture Decision Records din depozitul StaffPuzzle, din 19 februarie și 3 iunie 2026. Cifrele sunt măsurate pe ramurile depozitului, neestimate. Dezvăluirea interesului: htmxr și alpiner sunt scrise de Arthur Bréant, care a condus acest proiect și întreține acele pachete.
Această postare este mai bine prezentată pe site-ul său original ThinkR aici: Am ales React pentru a o învăța. AI a scris-o pentru noi.
