Migrar una aplicació de PHP 5.3 a PHP 8.4 amb l’ajuda de la IA no consisteix a demanar-li que modernitzi el codi i esperar. Consisteix a fer-la servir per entendre el projecte, ordenar la feina i revisar millor el resultat, sense deixar anar el control del que acaba en producció. Aquest és el procés que vam seguir, on ens va ajudar de debò i on no.
Quan es parla de IA en desenvolupament, la conversa comença gairebé sempre pel mateix: quant codi pot escriure i en quant de temps.
És normal, perquè és la part que es veu.
Descrius el que necessites, esperes uns segons i apareix una cosa que fa més o menys el que demanaves. La IA no protesta, no discuteix l’arquitectura i gairebé sempre entrega alguna cosa que arrenca.
El problema és justament aquí, en aquest «arrenca».
Un fragment de codi pot funcionar perfectament i duplicar una cosa que ja existia. Pot resoldre el cas que li has descrit i ignorar els tres que no has esmentat. Pot seguir un patró correcte en abstracte i saltar-se les normes del projecte. Pot millorar un fitxer per separat i empitjorar el conjunt.
Cap d’aquests problemes es detecta comprovant si funciona.
Per això, incorporar IA en un procés de desenvolupament no és simplement demanar-li que escrigui millor codi.
El seu valor real apareix abans i després d’escriure’l: quan ajuda a entendre codi que ningú va documentar, a localitzar tot el que cal canviar, a anticipar efectes secundaris i a deixar per escrit per què es va decidir cada cosa.
A Èmfasi tenim un costum sa, o lleugerament temerari: abans de convertir una idea en recomanació per a un client, la provem en els nostres propis projectes. Ens interessa saber on falla el mètode, no només on llueix.
Fa poc ens en va tocar un que servia perfectament per a això: migrar una aplicació web de gestió d’activitats de PHP 5.3 a PHP 8.4.
Continguts
Què vol dir migrar de PHP 5 a PHP 8
PHP és el llenguatge sobre el qual funcionen la majoria de webs i aplicacions de gestió. Com qualsevol programa, té versions, i les antigues deixen de rebre actualitzacions de seguretat.
Quan una aplicació es va quedar escrita per a PHP 5, tard o d’hora arriba l’avís del hosting: aquesta versió ja no està suportada. A partir d’aquí hi ha dues opcions, actualitzar o quedar-se amb una aplicació cada cop més exposada i més difícil de mantenir.
El problema és que actualitzar no és canviar un desplegable al panell del servidor.
Entre PHP 5.3 i PHP 8.4 hi ha catorze anys. Canvien funcions que s’han eliminat, comportaments que abans eren d’una manera i ara són d’una altra, el sistema d’avisos i errors, i fins i tot la manera com el llenguatge compara dos valors.
En el nostre cas, a més, l’aplicació funcionava, la feia servir gent cada dia i no podia deixar de funcionar durant el procés.
Hauríem pogut obrir el projecte i demanar a la IA que el modernitzés sencer. Hauríem obtingut codi nou de pressa, però hauríem començat pel final.
Abans de tocar una línia calia resoldre coses més importants: fins on arribava el projecte, quines parts havien de quedar-se exactament igual, quins comportaments podien canviar sense que ningú ho notés i com sabríem, si alguna cosa fallava, d’on venia la fallada.
La IA va ser present durant tot el procés, però no per substituir aquestes decisions. La vam fer servir per entendre el punt de partida, ordenar la feina i revisar millor el resultat.
Perquè el problema d’una migració no és el codi que deixa de funcionar. És el que continua funcionant d’una altra manera.
Que el codi funcioni no vol dir que estigui bé
Una IA generativa està feta per produir una resposta plausible. En desenvolupament, «plausible» té un parany: el codi o funciona o no funciona, i quan funciona sembla que la discussió s’ha acabat.
No s’ha acabat.
En un projecte real, un canvi es jutja per coses que l’execució no mostra. Si encaixa amb el que ja existeix. Si respecta les normes del projecte, encara que siguin antigues. Si algú el podrà entendre d’aquí a un any. Si fa exactament el mateix que abans o ho canvia sense avisar.
La IA et pot dir si una cosa funciona. No et pot dir si encaixa.
Això depèn d’informació que no és a la pregunta que li fas: per què el codi es va escriure així, què es va provar i es va descartar, quines restriccions té el client, què es construirà després.
Quan falta aquest context, la IA omple els buits amb el més habitual. I el més habitual, codi modern amb framework i estructura de projecte actual, no sempre és l’adequat per a l’aplicació que tens al davant.
Abans de demanar codi, cal entendre el que ja hi ha
Què és la fase 0 d’una migració
En alguns projectes d’Èmfasi anomenem fase 0 la feina de recopilar i comprovar informació abans de començar. En SEO vol dir una cosa; en desenvolupament, una de bastant semblant.
Abans de tocar res reunim el context real: quins fitxers hi ha, de què depèn el projecte i amb quines versions, què s’executa a cada pantalla, quines parts reben més trànsit, quins serveis externs hi ha connectats, què es pot provar en local i què només existeix al servidor de producció.
En aquest projecte la fase 0 va donar un resultat incòmode, que és justament per al que serveix: no hi havia documentació, no hi havia proves automàtiques i bona part de la lògica estava barrejada amb el disseny de les pantalles. La persona que ho va escriure ja no estava disponible per preguntar-li res.
Aquest, i no la sintaxi, era el problema real de la migració.
El context no és una introducció quilomètrica abans d’una instrucció. És informació seleccionada, ordenada i comprovada.
L’inventari del que calia canviar no el vam fer a mà
Aquí és on la IA va aportar valor des del primer dia, i no escrivint codi.
Una migració d’aquest salt comença per saber exactament què cal tocar. Part d’aquesta feina la fan eines d’anàlisi de compatibilitat, que llisten les funcions eliminades i les crides obsoletes. Això no ho fa ni ho ha de fer una IA.
Però el llistat d’una eina et diu on és el problema. No et diu què feia aquell codi ni per què.
Amb el projecte connectat a l’editor vam poder fer preguntes que en un codi sense documentar costen dies: què fa aquest mòdul, on es fa servir aquesta funció, què passa si canvio aquest comportament, quines parts depenen d’aquesta taula. Llegir codi aliè i explicar-lo és una de les coses que la IA fa bé de debò.
En un parell de sessions teníem un mapa de l’aplicació que a mà hauria costat setmanes.
Aquell mapa no era una decisió. Era el material amb què decidir.
Donar accés al codi no és delegar les decisions
Treballar amb el repositori accessible canvia molt la qualitat del que obtens. La IA deixa d’imaginar com és el projecte i el pot llegir.
Però això no converteix les seves propostes en recomanacions automàtiques.
Una IA amb accés al codi pot detectar que hi ha tres maneres diferents de consultar la base de dades. No pot decidir quina de les tres ha de sobreviure, ni si val la pena unificar-les ara o d’aquí a un any. Aquesta decisió depèn del pressupost del client, del risc de tocar una part que funciona i de cap on va el projecte.
Una llista d’incompatibilitats no és un pla de migració. Un connector no substitueix un criteri, permet contrastar-lo millor.
Migrar no és reescriure, i aquesta és la línia que ho ordena tot
Aquesta va ser la decisió que va ordenar el projecte sencer, i la vam prendre abans de canviar una línia.
L’objectiu era que l’aplicació funcionés exactament igual en PHP 8.4. Mateix comportament, mateixes pantalles, mateixos resultats. No era el moment de millorar l’arquitectura, posar un framework ni reorganitzar carpetes.
Pot semblar obvi. A la pràctica és la línia més difícil de mantenir, i la IA empeny constantment en la direcció contrària.
Si li demanes que actualitzi un fitxer de PHP 5.3, no es limita a arreglar el que està trencat. Et proposa reorganitzar funcions, separar la lògica del disseny, canviar com es carreguen els fitxers i muntar una capa nova per parlar amb la base de dades. Cada proposta, per separat, és una bona pràctica. Totes juntes, enmig d’una migració i sense proves automàtiques que les sostinguin, són una reescriptura encoberta.
Quan canvies el motor i el codi alhora, qualsevol fallada pot venir de dos llocs. I no sabràs de quin.
Així que vam fixar una regla abans de començar: en aquesta fase només es toca el que impedeix funcionar en 8.4. Tota la resta, encara que fos lletja, es quedava com estava. El que mereixia millorar-se s’apuntava en una llista a part per a una segona fase, ja amb l’aplicació estable.
Aquesta regla la vam haver de recordar unes quantes vegades. També a nosaltres.
Un projecte així no es resol amb un únic gran prompt
Hauríem pogut demanar en una sola instrucció que analitzés el projecte, corregís totes les incompatibilitats i deixés l’aplicació llesta per a 8.4.
Hauria estat ràpid. També hauria estat difícil saber per què va prendre cada direcció, quins supòsits arrossegava i en quin moment es va equivocar.
Vam preferir dividir el problema en decisions més petites.
Primer, l’inventari d’incompatibilitats. Després, agrupar-les per tipus de problema en comptes de per fitxer:
- totes les connexions a la base de dades, escrites amb un sistema retirat fa anys;
- totes les cerques de text fetes amb una sintaxi que PHP 8 ja no reconeix;
- tot el codi que creava objectes a la manera de PHP 4;
- totes les comparacions de valors en els punts on el canvi de criteri de PHP 8 podia alterar el resultat.
Cada grup es resolia amb el mateix criteri a tot el projecte, es revisava i es tancava abans de passar al següent.
Treballar per tipus de problema té un avantatge clar: revises una decisió una vegada i l’apliques a cinquanta llocs, en comptes de revisar cinquanta decisions diferents.
No és una llista universal, els grups depenen de cada projecte. El que sí que es trasllada és el principi: mantenir el problema a una mida que es pugui revisar d’una asseguda.
Cada fase produïa una conclusió revisable que alimentava la següent. Si una decisió no se sostenia, es corregia allà, no quan ja hi havia vint fitxers construïts a sobre.
Una IA proposa, una altra ajuda a qüestionar-la
En diversos moments vam contrastar el resultat entre models diferents. No per organitzar un combat ni declarar un guanyador, sinó per donar-los papers diferents.
Un proposava els canvis d’un grup. El segon els rebia sense l’historial de la conversa i actuava com a revisor crític: quin comportament ha canviat aquí, quin cas no s’ha contemplat, quina part és més complicada del que el problema demanava, quina dependència nova no calia.
Després tornàvem aquesta crítica al primer per replantejar.
Una IA ens pot ajudar a construir una proposta. Una altra ens pot ajudar a desconfiar-ne.
Aquest desacord és útil perquè trenca la inèrcia. Quan portes vint missatges treballant sobre una mateixa solució, tant l’equip com el model comencen a donar per bones les decisions anteriors només perquè ja hi són. Posar-hi una altra revisió obliga a tornar-les a justificar.
Però convé no romantitzar el mètode.
Dos models poden coincidir i estar equivocats. Poden discrepar per raons poc rellevants o proposar canvis que milloren un fitxer i empitjoren el conjunt. La revisió creuada amplia l’anàlisi, no dicta un veredicte.
La decisió final continuava sent nostra.
Els errors que no donen error: el risc real d’actualitzar PHP
La part visible d’una migració així és la que trenca. El codi que ja no existeix en PHP 8 es detecta sol: l’aplicació deixa d’arrencar i saps exactament on mirar.
Aquesta part, amb eines i una IA que entén el projecte, avança raonablement de pressa.
El que costa de debò és l’altre: el codi que continua funcionant i ara es comporta d’una altra manera.
PHP 8 va canviar la manera com compara un text amb un número. Durant anys, comparar un text amb un zero donava cert. Ara dóna fals. És un canvi correcte i feia temps que es demanava, però en una aplicació amb catorze anys a sobre vol dir que hi ha filtres, condicions i validacions que fan una cosa diferent de la que feien ahir.
No llancen cap error. Simplement retornen una altra cosa.
Traduït al que veu el client: un llistat que mostra registres de més, un filtre que deixa fora resultats que haurien d’aparèixer, un formulari que accepta una cosa que abans rebutjava. Res no cau. Tot sembla normal fins que algú mira els números i no quadren.
I aquí la IA és una ajuda relativa. Et pot assenyalar tots els llocs on hi ha una comparació d’aquest tipus, i són molts. El que no et pot dir és quin d’ells importa, perquè això depèn de quines dades arriben realment a cada punt de l’aplicació. La IA no sap que aquell camp sempre ve d’un desplegable amb valors controlats, ni que aquell altre s’omple des d’un formulari públic on hi entra qualsevol cosa.
Això ho sap qui coneix l’aplicació, o ho esbrina mirant les dades.
El temps que estalvies generant l’inverteixes revisant. El guany és que revisar surt més barat que escriure des de zero, no que la revisió desaparegui.
Una cosa semblant va passar amb els avisos que en PHP 8 van passar a ser errors. Codi que durant anys havia conviscut amb avisos silenciats va començar a comportar-se d’una altra manera. Cap eina et diu si aquell avís era irrellevant o si tapava un problema des del principi.
Els errors més cars són els que semblen bones pràctiques
La IA té una inclinació natural a proposar, ampliar i completar. Si li demanes alternatives, poques vegades respon: «De fet, aquí no cal tocar res».
El criteri professional treballa moltes vegades en la direcció contrària.
En aquesta migració vam decidir no posar-hi un framework, tot i que cada revisió ho suggeria d’alguna manera. No era a l’objectiu i multiplicava el risc. No vam reorganitzar l’estructura de fitxers: és antiga i no l’hauríem fet així, però moure-la ens hauria deixat sense poder comparar l’abans i el després. No vam afegir comprovacions estrictes de tipus de manera general, perquè en un codi sense proves automàtiques aquesta és una manera molt eficaç de descobrir en producció quins valors arribaven de debò a cada funció. I no vam reescriure els mòduls més antics, precisament els que més ganes fan de reescriure: funcionaven, gairebé ningú els tocava i no era el seu torn.
Durant el procés vam rebutjar propostes ben argumentades que milloraven un fitxer concret i empitjoraven el que de debò importava: poder saber, si alguna cosa fallava, si la fallada venia de la versió de PHP o dels nostres canvis.
Una proposta no es tornava adequada per estar ben escrita.
Limitar, ajornar i deixar coses com estan també són decisions tècniques.
Poder generar vint enfocaments en segons no elimina la necessitat de triar-ne un. Només fa més visible la responsabilitat de fer-ho.
Documentar la migració no és guardar converses
Tot el procés es va recollir en un document de migració.
Incloïa què es va canviar a cada grup i amb quin criteri, quins comportaments podien haver canviat i on vigilar-los, què vam decidir no tocar i per què, i la llista de millores ajornades a una segona fase.
Això és molt diferent de conservar un historial de xat.
Una conversa pot contenir idees valuoses, però també preguntes provisionals, camins abandonats, respostes contradictòries i molt material que només tenia sentit en el moment en què es va produir.
Buscar mesos després la decisió important entre desenes de missatges és una forma poc sofisticada d’arqueologia digital.
La documentació converteix l’intercanvi en memòria de projecte.
En una migració això té un valor evident. Quan alguna cosa falli d’aquí a tres mesos, la primera pregunta serà si té a veure amb el canvi de versió. Amb aquell document al davant, es respon en deu minuts en comptes de en dos dies.
El codi diu el que fa. Gairebé mai diu per què es va fer així en comptes de l’altra manera, que era la que semblava òbvia.
Què vol dir per a nosaltres ser una agència AI First
No consisteix a generar més de pressa, fer servir totes les eines disponibles o automatitzar qualsevol tasca que admeti una instrucció.
Tampoc a acceptar la primera resposta perquè arriba en deu segons i arrenca.
En aquesta migració la IA ens va estalviar la part més lenta i menys interessant: entendre un codi sense documentar, localitzar tot el que calia canviar i aplicar el mateix criteri a desenes de llocs sense saltar-nos-en cap. Això és molt.
El que no va fer va ser decidir fins on arribava el projecte, què es quedava com estava i quins riscos podíem assumir amb una aplicació en ús. Aquestes decisions eren les que determinaven si la migració sortia bé.
El criteri professional continua definint l’abast, interpretant les restriccions, establint prioritats i responent del que es desplega.
Perquè quan alguna cosa es trenca en producció a les onze de la nit, no hi ha cap model a qui reclamar res.
No fem servir la IA per deixar de pensar. La fem servir per pensar amb més informació, més ordre i més capacitat crítica.
Aquesta manera de treballar no es limita al desenvolupament. També l’apliquem en processos com la IA aplicada al SEO o el disseny UX/UI assistit per intel·ligència artificial, on generar opcions tampoc no substitueix la necessitat de decidir amb criteri.
Preguntes freqüents sobre migrar de PHP 5 a PHP 8 amb IA.
Es pot migrar una aplicació de PHP 5.3 a 8.4 amb IA?
La IA ajuda molt en la part d'entendre el codi, localitzar totes les incompatibilitats i aplicar el mateix criteri en molts arxius sense saltar-se'n cap. El que no resol és l'abast del projecte: fins on arribar, què deixar com està i quins riscos es poden assumir amb una aplicació en ús. Aquestes decisions continuen sent de l'equip tècnic.
Què és el que la IA no detecta en migrar codi antic?
Els canvis de comportament que no produeixen cap error. PHP 8 va modificar, per exemple, la forma en què es comparen una cadena de text i un número: codi que funcionava continua executant-se, però retorna un altre resultat. La IA pot assenyalar on són aquestes comparacions, però no quines dades arriben realment a cada punt de l'aplicació.
Convé aprofitar la migració per modernitzar el codi?
En general, no alhora. Si canvieu la versió de PHP i l'arquitectura en el mateix moviment, qualsevol fallada posterior pot venir de dos llocs i no sabreu de quin. És més segur migrar primer mantenint el comportament, i deixar les millores per a una segona fase amb l'aplicació ja estable.
Cal tenir tests abans de migrar?
Ajuda molt, però és habitual que un projecte antic no en tingui. Quan no existeixen, el substitut raonable és limitar al màxim els canvis, treballar per grups de problemes per poder revisar cada decisió una sola vegada i documentar quins comportaments poden haver canviat i on vigilar-los.
Quant de temps estalvia realment la IA en una migració?
Estalvia sobretot en comprensió: entendre un codi sense documentar i saber què cal canviar és el que més temps consumeix, i aquí la diferència és gran. En canvi, el temps que estalvieu generant l'invertiu revisant. El guany està en el fet que revisar és més barat que escriure des de zero, no en el fet que la revisió desaparegui.
Quines eines calen a més de la IA?
Una anàlisi de compatibilitat que llisti funcions eliminades i crides obsoletes, control de versions per poder comparar l'abans i el després, i un entorn on provar sense tocar producció. La IA es recolza en aquesta informació; no la substitueix.
