Il sito era nato su PrestaShop 1.6. Poi erano arrivati override delle classi, controller modificati e moduli custom scritti in momenti diversi. A un certo punto, prima ancora di capire come portarli verso una versione nuova, serviva ricostruire che cosa facessero.<\/p>\n
Una parte del lavoro era nel codice. Un\u2019altra nelle relazioni fra quei pezzi: dove entrava un dato, chi lo modificava, quale modulo si aspettava di ritrovarlo. Leggere un file alla volta lasciava aperta tutta questa seconda parte.<\/p>\n
Nota del 13 ottobre 2026.<\/strong> Questo \u00e8 il racconto di un lavoro storico sui moduli legacy. La revisione chiarisce il metodo e i suoi limiti; non aggiorna lo stato del rilascio di quel sito n\u00e9 certifica la compatibilit\u00e0 attuale dei singoli moduli.<\/p>\n Nel lavoro raccontato qui avevo isolato i moduli sviluppati internamente in repository dedicati. In ogni repository potevamo concentrarci su un contesto pi\u00f9 piccolo: funzioni, hook, tabelle, interfacce e dipendenze di quel modulo.<\/p>\n La separazione aiutava a leggere il codice. Le dipendenze, per\u00f2, continuavano a esistere. Se un modulo si appoggiava a un altro, dovevamo conservare anche quel collegamento nell\u2019analisi. Una cartella pulita non rende indipendente un pezzo che prima non lo era.<\/p>\n Insieme agli agenti avevamo organizzato gli audit dentro Il codice originale restava il riferimento. Un report poteva rendere pi\u00f9 leggibile un comportamento, ma poteva anche perderne uno o interpretarlo male. Per questo l\u2019analisi passava attraverso revisioni, domande e correzioni prima di diventare il punto da cui sviluppare.<\/p>\n La cartella cominciava cos\u00ec a contenere qualcosa che una nuova sessione poteva rileggere, senza dover ricostruire tutto dalla conversazione precedente.<\/p>\n Da quel materiale preparavamo Separare i compiti aiutava a mettere in discussione il lavoro. Avere un agente chiamato Reviewer, per\u00f2, non bastava a rendere corretta la sua revisione. Anche i suoi rilievi dovevano tornare al codice, alla documentazione e alle prove.<\/p>\n Le regole tecniche andavano scelte per la destinazione: versione di PrestaShop, ambiente PHP, API e parti del modulo da mantenere o cambiare. I requisiti ufficiali di PrestaShop<\/a> e la documentazione dei moduli<\/a> sono il riferimento da rileggere quando si affronta un lavoro nuovo. Il file di istruzioni conserva le scelte del progetto, non sostituisce quel controllo.<\/p>\n Nel percorso descritto il nuovo repository partiva dall\u2019audit e dalle istruzioni, per costruire il modulo destinato alla nuova versione. Era una scelta di quel lavoro, da valutare anche rispetto a quello che conveniva conservare.<\/p>\n Il passaggio utile era portare con noi la conoscenza raccolta: comportamenti da riprodurre, dipendenze, dubbi e verifiche necessarie. Ripartire dal codice nuovo senza quei riferimenti avrebbe reso pi\u00f9 difficile accorgersi di una funzione persa per strada.<\/p>\n Nel primo racconto avevo scritto \u201cprova, rifinisci, ritenta, torna indietro, fallo due volte e poi ok\u201d. Il problema \u00e8 proprio quel \u201cpoi ok\u201d \ud83d\ude00<\/p>\n Due giri non sono una misura della stabilit\u00e0. Per decidere se un modulo \u00e8 pronto servono le prove pertinenti: installazione, percorsi che usa davvero, dati che legge e scrive, convivenza con gli altri componenti. E condizioni di prova abbastanza chiare da poterle ripetere.<\/p>\n Il numero di revisioni racconta quanto ci abbiamo lavorato. L\u2019esito delle verifiche racconta qualcosa sul risultato. Tenerli separati rende pi\u00f9 utile anche l\u2019analisi.<\/p>\n Da questo percorso avevo ricavato Audit-to-Refactor<\/a>: leggere il sistema, conservare quello che abbiamo capito e usarlo per organizzare il lavoro successivo.<\/p>\n La scheda del metodo<\/a> tiene insieme i due racconti. Il lavoro sul contesto dei progetti continua anche con Repo Forge<\/a>, su un piano diverso: istruzioni, decisioni e piani da mantenere mentre cambia il codice.<\/p>\n La parte che mi interessa \u00e8 quella che rimane fra una sessione e l\u2019altra. Se il ragionamento \u00e8 stato buono, devo poterlo ritrovare. Se era sbagliato, mi serve capire da dove eravamo partiti per poterlo correggere.<\/p>\n","protected":false},"excerpt":{"rendered":" Un lavoro storico sui moduli PrestaShop legacy: separare il codice, conservarne il comportamento e preparare lo sviluppo con gli agenti, senza confondere revisioni e verifiche.<\/p>\n","protected":false},"author":1,"featured_media":74,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[56],"tags":[3],"class_list":["post-73","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-sviluppo","tag-intelligenza-artificiale"],"_links":{"self":[{"href":"https:\/\/www.matteobononi.it\/blog\/wp-json\/wp\/v2\/posts\/73","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.matteobononi.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.matteobononi.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.matteobononi.it\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.matteobononi.it\/blog\/wp-json\/wp\/v2\/comments?post=73"}],"version-history":[{"count":2,"href":"https:\/\/www.matteobononi.it\/blog\/wp-json\/wp\/v2\/posts\/73\/revisions"}],"predecessor-version":[{"id":206,"href":"https:\/\/www.matteobononi.it\/blog\/wp-json\/wp\/v2\/posts\/73\/revisions\/206"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.matteobononi.it\/blog\/wp-json\/wp\/v2\/media\/74"}],"wp:attachment":[{"href":"https:\/\/www.matteobononi.it\/blog\/wp-json\/wp\/v2\/media?parent=73"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.matteobononi.it\/blog\/wp-json\/wp\/v2\/categories?post=73"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.matteobononi.it\/blog\/wp-json\/wp\/v2\/tags?post=73"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Separare per riuscire a capire<\/h2>\n
Prima capire cosa succedeva<\/h2>\n
audit_update\/<\/code>. I documenti descrivevano cosa faceva il modulo, quali hook usava, come lavorava sui dati, quali schermate esponeva e da quali altri componenti dipendeva.<\/p>\nLe istruzioni nascevano dall\u2019analisi<\/h2>\n
AGENTS.md<\/code>: obiettivi, vincoli, ruoli e regole per chi avrebbe lavorato sul modulo. Auditor, Architect, Coder e Reviewer erano modi per distinguere i compiti dentro il flusso.<\/p>\nIl nuovo repository aveva un punto di partenza<\/h2>\n
Prova, rifinisci, ritenta<\/h2>\n
Il metodo che \u00e8 rimasto<\/h2>\n