Ciao,
siccome mi sono appena imbattuto con una custom3.js abbandonata in uno specifico progetto vi racconto in due righe come facciamo noi per non perdere traccia delle patch.
Spesso durante un’assistenza si fa una patch in custom.css o in custom3.js, oppure si aggiunge un workaround nel codice.
Queste cose nel tempo si sedimentano e vengono dimenticate.
Idealmente se la patch js verrà risolta con la NPQ00NNNNN dovrei toglierla.
Noi abbiamo inventato il trucco che vi descrivo.
Nel nostro componente Tools che usiamo in ogni progetto abbiamo una classe DevTools con un metodo statico temporaryWorkaround di cui vi mostro il codice:
Un esempio di uso (Quello che ho gestito oggi e chi mi ha ispirato questo post) è:
DevTools.TemporaryWorkaround('Ricordarsi di togliere la patch NP05250 dal custom3.js perché dovrebbero ora avere risolto il problema di visualizzazione dei campi fuori lista','21.5')
la prima riga prende la versione di inde che è tipo 22.5.1234 e ritorna solo “22.5”
In questo modo chiamando il metodo (che è bene scriverlo nell’Initialize) appena sto usando la versione di Inde che ho dichiarato nel metodo avrò un DTTError nel debug, me ne accorgo e rimuovo la patch. Testo che con il nuovo inde funzioni tutto e poi eventualmente ufficializzo il “de-pachamento”.
È un trucco semplice ma efficace, lo abbiamo inventato perché in passato abbamo penato a causa di patch dimenticate che poi andavano in conflitto con le nuove versioni di Inde.
Cosa ne pensate?
Ciao!
4 Mi Piace
In effetti, ad ogni cambio versione, dobbiamo riprendere per mano tutte le custom, verificare se il problema per cui è nata la singola patch è stato risolto e verificare che le personalizzazioni non vadano in conflitto con la nuova versione. Un lavoraccio.
1 Mi Piace
Ciao @r.bianco,
la nostra soluzione nasce da un approccio “pigro”: chiamando il metodo TemporaryWorkaround so già che appena compilerò con la versione di Inde che ho specificato nel secondo parametro, avrò un errore nel debug. E nonostante la pigrizia alla fine quegli errori li noti e vai a toglierli rimuovendo anche il workaround.
In ogni caso è stato utile parlarne: mi rendo conto che il parametro “Details” è troppo generico, ovvero non ti porta a descrivere bene il problema.
Faccio quindi subito una modifica alla signature e passerò da
TemporaryWorkaround(Details: string, requiredIndeVersion: string)
a
TemporaryWorkaround(Details: string, requiredIndeVersion: string; typeOfWorkaround: string; howToTest: string)
ovvero lascio Details per spiegare diche si tratta ma mi invito a scrivere anche che tipo di workaround (typeOfWorkaround) è (ad esempio “modifica a custom3.js”) e cosa devo testare (howToTest) per caprie che l’ho tolto con successo. Chiaramente prima tutte queste informazioni le avrei potute scrivere in Details, ma andando di fretta spesso ho scritto poco, tant’è che ritrovandomi l’errore mesi o anni dopo ho dovuto ricostruire tutto per capire cosa fosse successo.
Ho condiviso questo trucco, credo comunque che, a meno che l’IDE non metta a disposizione uno strumento per tracciare queste patch, sia una soluzione efficace al momento.
Ciao!
3 Mi Piace
