Definiți rezultatele pe care trebuie să le păstreze o rescriere

Rescrierea unei componente critice cere un răspuns practic înainte să înceapă implementarea: ce trebuie să observe în continuare utilizatorii ei? Alegerea unui limbaj mai sigur stabilește direcția proiectului. Nu definește însă ce modificări ale rezultatelor sunt acceptabile. Echipa care înlocuiește o componentă consacrată ar trebui să stabilească separat compatibilitatea și obiectivul de siguranță, apoi să prezinte dovezile pentru fiecare afirmație.

Articolul Apple din 12 iunie 2026 despre rescrierea interpretorului TrueType oferă un exemplu util. Descrie înlocuirea implementării C cu una Swift, livrată odată cu versiunile din toamna lui 2025. Criteriul de compatibilitate era redarea identică la nivel de pixel față de interpretorul anterior. Articolul din iunie relatează o livrare anterioară; nu anunță o livrare în iunie. Distincția contează când folosiți relatarea pentru a pregăti altă migrare.

Alegeți ce rezultat observați

Pentru un interpretor de fonturi, păstrarea interfeței publice lasă fără răspuns o întrebare importantă: textul mai arată la fel? O interfață poate accepta aceleași tipuri de date și poate produce rezultate vizibil diferite. Criteriul de acceptare trebuie, așadar, să includă rezultatul de care depind efectiv utilizatorii. Pentru altă componentă, acesta ar putea fi un document exportat, o valoare calculată sau o regulă de ordonare.

Stabiliți această limită înainte să alegeți mecanismul de comparație. Precizați datele de intrare comparate, condițiile păstrate constante și rezultatul care decide dacă există concordanță. Dacă timpul contează, descrieți-l separat. Reunirea echivalenței vizuale și a vitezei de execuție sub eticheta unei migrări reușite îngreunează distincția dintre ceea ce demonstrează dovezile și ceea ce rămâne de decis.

Un oracol de testare este referința folosită pentru a judeca un rezultat. Implementarea veche poate îndeplini acest rol pentru compatibilitate fără să devină autoritatea finală asupra corectitudinii. Rolul este util și limitat: arată dacă s-a schimbat comportamentul față de o versiune de referință. Nu dovedește că vreuna dintre implementări respectă toate cerințele pe care le-ați formula astăzi.

Precizați ce demonstrează corpusul

Apple descrie compararea rezultatelor de redare și un corpus redus de documente care a păstrat acoperirea codului. Sunt metode relatate de autor, nu experimente reproduse aici. Susțin încrederea în compatibilitate pentru datele parcurse. Reducerea care păstrează acoperirea nu transformă un corpus finit într-o demonstrație pentru toate fonturile sau documentele posibile. Aceste limite își au locul lângă strategia de testare, nu doar după apariția unui rezultat contestat.

Pentru propria rescriere, un corpus redus poate face practice comparațiile repetate. Păstrați clar motivul includerii fiecărei categorii de date. Cazurile rare pot conta fiindcă parcurg o instrucțiune sau o combinație distinctă, chiar dacă apar puțin în traficul obișnuit. Frecvența și varietatea comportamentelor răspund unor întrebări diferite. Un set mic reprezentativ și o comparație mai amplă, făcută ocazional, pot avea scopuri diferite.

Când apare o diferență, păstrați suficient context pentru a o explica. Notați versiunea de referință și datele de intrare, apoi descrieți diferența observată în rezultat. O nepotrivire neexplicată ar trebui să rămână o nepotrivire. Dacă o reclasificați drept inofensivă fiindcă noul cod pare mai clar, înlocuiți criteriul convenit cu o preferință tocmai când aveți nevoie de acel criteriu.

Decideți explicit ce faceți cu erorile moștenite

Cea mai puternică obiecție față de folosirea sistemului vechi ca referință este simplă: comportamentul vechi poate fi greșit. Cerința concordanței exacte poate păstra un defect. Obiecția cere o politică pentru excepții. Nu face compatibilitatea irelevantă. Oamenii se pot baza pe un comportament nedorit în sine, iar schimbarea lui în timpul înlocuirii poate extinde migrarea dincolo de lucrările prevăzute.

O excepție ar trebui să precizeze comportamentul schimbat, motivul și persoana care răspunde de acceptarea efectelor asupra utilizatorilor. Separați corecția deliberată de diferența accidentală. Dacă acea corecție schimbă un contract extern, explicația versiunii ar trebui să o spună. O evidență clară îi permite unui viitor responsabil de mentenanță să deosebească o abatere aprobată de o regresie trecută neobservată.

Unele componente nu au nevoie de rezultate identice. Un produs poate permite deliberat o toleranță sau un format schimbat. În acest caz, definiți variația permisă în aceeași dimensiune ca rezultatul: de exemplu, o toleranță numerică pentru un rezultat numeric. Promisiunea nedefinită că înlocuitorul este suficient de apropiat oferă puține repere pentru a decide dacă o diferență este acceptabilă.

Păstrați separat cronologia codului de referință

Fișierul README original, fixat la o anumită revizie cere macOS 26 și Xcode 26. Cerințele descriu exemplul publicat în acea revizie. Nu stabilesc cerințele de livrare ale produsului din toamna lui 2025. Niciun README ulterior și niciun API de siguranță mai nou nu pot stabili ce instrumente a folosit livrarea inițială.

Separarea este utilă ori de câte ori o retrospectivă trimite la un cod care continuă să se schimbe. Notați ce material susține fiecare afirmație. Lansarea unui produs, publicarea unui exemplu și o modificare ulterioară a documentației pot avea date diferite. Cititorul ar trebui să poată urmări afirmația fără să înlocuiască tacit materialul istoric cu ultima stare a depozitului.

Aceeași grijă se aplică performanței. Orice cifre din relatarea Apple aparțin sarcinii și metodei de măsurare folosite de Apple. Nu reprezintă o prognoză pentru altă aplicație. O propunere de migrare poate folosi relatarea pentru a explica o metodă de testare, păstrând deschise propriile afirmații despre viteză până la măsurarea componentei și a sarcinii relevante.

Pentru un proiect de reparare sau modernizare, porniți de la rezultatele pe care se bazează oamenii și de la diferențele pe care le pot accepta. Includeți în lucrările agreate referința de compatibilitate, limitele ei și responsabilul pentru excepții. Rescrierea primește astfel o țintă care poate fi verificată, iar comportamentul moștenit poate fi corectat deliberat.