Quando hai un modulo vecchio da portare avanti, la prima difficolt\u00e0 pu\u00f2 essere capire cosa stai cercando di conservare. Il codice funziona dentro un sito, incontra dati e configurazioni, si appoggia ad altri moduli. Riscriverlo leggendo solo le funzioni rischia di lasciare fuori proprio quei collegamenti.<\/p>\n
Nel racconto sul lavoro con PrestaShop legacy<\/a> descrivo il contesto da cui \u00e8 nato Audit-to-Refactor. Qui provo a spiegare come avevamo organizzato il percorso.<\/p>\n \u00c8 il nome che ho dato al metodo per analizzare i moduli, conservare le informazioni utili e preparare lo sviluppo insieme agli agenti. L\u2019audit produce un punto di partenza: funzioni, dipendenze, vincoli e dubbi. Il lavoro successivo deve ancora verificarlo.<\/p>\n Nel caso raccontato il metodo accompagnava la riscrittura di moduli verso una versione nuova di PrestaShop. Il refactoring di un componente e la migrazione del sito sono lavori collegati: la disponibilit\u00e0 di un modulo riscritto, da sola, non documenta il completamento della migrazione.<\/p>\n Nel percorso iniziale avevamo isolato i moduli custom in repository dedicati. Questa scelta restringeva il contesto da leggere, ma richiedeva di annotare le dipendenze che attraversavano quel confine.<\/p>\n Prima di decidere che un pezzo va riscritto, conviene capire quali funzioni servono ancora, quali sono gi\u00e0 disponibili altrove e quali vincoli ci portiamo dietro. La riscrittura \u00e8 una scelta da motivare, anche quando l\u2019IA rende pi\u00f9 facile cominciarla.<\/p>\n I report erano raccolti in I nomi dei file aiutavano a ritrovare le informazioni. Per un altro progetto possono cambiare. Quello che deve restare comprensibile \u00e8 da dove arriva un\u2019osservazione, quale comportamento descrive e dove manca ancora una risposta.<\/p>\n Gli agenti aiutavano a leggere e a rivedere il materiale. Un secondo passaggio poteva trovare un errore del primo, oppure riprenderne la stessa interpretazione sbagliata. Per questo la revisione deve confrontarsi con codice, documentazione e prove del comportamento.<\/p>\n La documentazione ufficiale dei moduli PrestaShop<\/a> e i requisiti della versione di destinazione<\/a> servono anche a decidere quali regole mettere nel progetto. Una lista di tecnologie copiata da un audit vecchio pu\u00f2 essere un altro pezzo da correggere.<\/p>\n In Se nasce un repository nuovo, l\u2019audit e le istruzioni possono entrarci come contesto iniziale. I riferimenti al codice precedente vanno comunque conservati: servono per controllare ci\u00f2 che il nuovo modulo deve fare.<\/p>\nChe cosa intendo con Audit-to-Refactor<\/h2>\n
1. Delimitare il modulo e i suoi collegamenti<\/h2>\n
2. Conservare l\u2019audit in una forma rileggibile<\/h2>\n
audit_update\/<\/code>. La struttura descritta nel lavoro iniziale comprendeva:<\/p>\n\n
01_overview.md<\/code>: funzioni e scopo del modulo.<\/li>\n02_hooks.md<\/code>: hook usati e comportamento collegato.<\/li>\n03_database.md<\/code>: tabelle, dati e relazioni.<\/li>\n04_ui.md<\/code>: interfacce e form.<\/li>\n05_dependencies.md<\/code>: moduli e componenti esterni.<\/li>\n06_notes_migration.md<\/code>: rischi, scelte da valutare e verifiche mancanti.<\/li>\n<\/ul>\n3. Rivedere l\u2019analisi prima di usarla<\/h2>\n
4. Preparare istruzioni e piano di lavoro<\/h2>\n
AGENTS.md<\/code> avevamo distinto i compiti di analisi, architettura, sviluppo e revisione. Le istruzioni indicavano obiettivi e vincoli; il piano organizzava i passaggi da affrontare.<\/p>\n