Evitare che gli avvisi di deprecazione diventino un falso allarme
Quando PHPStan segnala un metodo come deprecato, di solito si cerca un sostituto. Ma cosa succede se non ne esiste nessuno?
Shopware utilizzava il tag @deprecated per annunciare modifiche pianificate, come l'aggiunta di un nuovo parametro opzionale. Gli strumenti di analisi statica trattavano questi tag come vere deprecazioni e segnalavano ogni singola chiamata. Il rumore di fondo è aumentato, gli sviluppatori hanno iniziato a ignorare gli avvisi e gli alert hanno perso il loro valore. È il classico caso del "gridare al lupo".
In Shopware 6.7.14.0 abbiamo separato i segnali.
@deprecated– riserva questo tag per le API che scompariranno o saranno sostituite. È necessario migrare il codice.- Attributi BC-change – usali per le modifiche pianificate che mantengono l'API attiva, come nuovi parametri opzionali o tipi di ritorno modificati.
I nuovi attributi si trovano in Shopware\Core\Framework\Deprecation\BCChange. Ti dicono esattamente cosa cambierà e chi ne sarà influenzato.
Li abbiamo divisi in due gruppi:
- CallSiteCompatibilityChange – influisce sul codice che chiama un metodo.
- ExtenderCompatibilityChange – influisce sulle classi che estendono o sovrascrivono un metodo.
Ora puoi preparare la tua estensione per Shopware 6.8 prima del rilascio della prossima versione major.
Esempio: un metodo riceverà un nuovo parametro opzionale. Aggiungi quel parametro ai tuoi override oggi stesso; il codice funzionerà sia sulla versione attuale che su quella futura.
Questa modifica ripristina la fiducia negli avvisi di deprecazione.
Tre passi per gli sviluppatori
- Tratta
@deprecatedcome una correzione obbligatoria; l'API scomparirà. - Abbandona i pattern di ignore troppo ampi che potrebbero nascondere problemi reali.
- Fai attenzione agli attributi BC-change e applica piccoli aggiornamenti sicuri ora, invece di una migrazione massiccia in seguito.
Fonte: https://dev.to/shopware/when-deprecated-cries-wolf-making-shopwares-next-major-upgrades-easier-983