La Mia Ultima Frustrazione con Apple
Essendo qualcuno che trascorre molto tempo a creare bot e modificare codice, non sono nuovo ai bug. Fanno parte del processo. Ciò che non dovrebbe far parte del processo, o almeno non dovrebbe, è avere i tuoi rapporti sui bug chiusi a caso senza una reale risoluzione. Eppure, eccoci qui, a parlare di Apple di nuovo.
Sono immerso in un progetto che, come molti dei miei bot, interagisce con vari sistemi, compresi alcuni framework di Apple. Naturalmente, quando incontro un ostacolo, faccio ciò che farebbe qualsiasi buon sviluppatore: riporto il bug. L’idea è contribuire a migliorare gli strumenti per tutti. Ma Apple sembra avere un’idea diversa su come funzionano le cose.
Il Ciclo del “Verifica che sia Ancora Rotto”
Il problema non è solo che i bug rimangono irrisolti – questo accade ovunque. Il problema è l’abitudine di Apple di chiudere i rapporti sui bug con una richiesta che equivale a: “Verifica che questo bug esista ancora.” Non si tratta solo di un episodio isolato; è un modello ricorrente, ed è incredibilmente frustrante per i costruttori come me che stanno cercando di far funzionare le cose.
Pensateci dalla mia prospettiva. Ho speso tempo a isolare un problema, scrivere un rapporto chiaro e, a volte, anche fornire codice di esempio che mostra il problema. Poi, settimane o mesi dopo, ricevo una notifica che il rapporto è chiuso. Non perché sia stato risolto, ma perché Apple vuole che lo verifichi di nuovo. Questo succede spesso senza alcuna indicazione che abbiano anche provato a riprodurlo da parte loro, o che siano state apportate modifiche che potrebbero averlo risolto incidentalmente.
Perché Questo Dà Fastidio agli Sviluppatori (e ai Miei Progetti di Bot)
Per me, questo si traduce in tempo e sforzo sprecati. Quando costruisco un bot, ho bisogno di strumenti affidabili. Se un componente di un framework di Apple presenta bug, questo influisce direttamente sulla mia capacità di fornire un bot stabile. Riportare i bug è il mio modo di segnalare quei problemi, sperando di ottenere una soluzione, o almeno una soluzione temporanea, e poi andare avanti.
Quando un rapporto viene chiuso con una richiesta di “verificare che esista ancora”, la responsabilità torna a ricadere su di me. Devo quindi:
- Tornare al vecchio progetto o setup.
- Ripetere i test che hanno messo in evidenza il bug in primo luogo.
- Spesso, aggiornare all’ultima versione del sistema operativo o del framework (che potrebbe introdurre nuovi bug o compromettere il mio lavoro esistente).
- Spendere più tempo solo per dimostrare che un bug è ancora un bug.
Questo non è produttivo. Il mio tempo è meglio speso a costruire nuove funzionalità per i miei bot, ottimizzando le loro prestazioni, o risolvendo bug *nuovi* che spuntano inevitabilmente. Non è tempo ben speso a verificare di nuovo quelli vecchi che avrebbero dovuto essere indagati dal fornitore in primo luogo.
Cosa Potrebbe Fare Meglio Apple
Se Apple vuole che gli sviluppatori contribuiscano a un ecosistema migliore, deve dimostrare che i contributi degli sviluppatori sono apprezzati. Chiudere semplicemente i rapporti e chiedere di verificare di nuovo sembra un modo per liberarsi dell’arretrato senza affrontare realmente le questioni sottostanti.
Un approccio migliore sarebbe:
- Comunicare chiaramente: Se un rapporto di bug viene chiuso, indicare *perché*. È stato riprodotto? È stata implementata una soluzione? È una limitazione nota?
- Fornire contesto: Se chiedono una riesame, indicare quali cambiamenti (se ce ne sono) sono stati fatti che potrebbero influenzare il bug. Questo mi aiuterebbe a restringere i miei test di riesame.
- Dare priorità: Mostrare che stanno effettivamente esaminando questi rapporti. Sembra che molti rapporti rimangano in coda finché non attivano un qualche arbitrario trigger di “verifica di nuovo”.
Fino ad allora, è solo un’altra barriera nel già difficile mondo della creazione di bot. E onestamente, mi fa riflettere due volte su come spendere il mio prezioso tempo a segnalare bug ad Apple in primo luogo, il che non è vantaggioso per nessuno.
🕒 Published: