Minha Última Frustração com a Apple
Como alguém que passa muito tempo construindo bots e ajustando código, não sou estranho a bugs. Eles são parte do processo. O que não faz parte do processo, ou pelo menos não deveria, é ter seus relatos de bugs encerrados aleatoriamente sem qualquer resolução real. E ainda assim, aqui estamos, falando da Apple novamente.
Eu estive profundamente envolvido em um projeto que, como muitos dos meus bots, interage com vários sistemas, incluindo alguns frameworks da Apple. Naturalmente, quando encontro um obstáculo, faço o que qualquer bom desenvolvedor faz: reporto o bug. A ideia é contribuir para melhorar as ferramentas para todos. Mas a Apple parece ter uma visão diferente sobre como isso funciona.
O Loop do “Verifique se Ainda Está Quebrado”
O problema não é apenas que bugs ficam sem correção – isso acontece em todos os lugares. A questão é o hábito da Apple de fechar relatos de bugs com um pedido que se resume a: “Verifique se este bug ainda existe.” Isso não é algo isolado; é um padrão recorrente, e é incrivelmente frustrante para desenvolvedores como eu que estão tentando fazer as coisas funcionarem.
Pense nisso pela minha perspectiva. Eu passei tempo isolando um problema, escrevendo um relato claro e, às vezes, até fornecendo código de exemplo que mostra o problema. Então, semanas ou meses depois, recebo uma notificação de que o relato foi fechado. Não porque foi corrigido, mas porque a Apple quer que eu o re-verifique. Isso frequentemente acontece sem qualquer indicação de que eles tentaram reproduzir o problema do lado deles, ou que quaisquer mudanças foram feitas que poderiam ter resolvido incidentalmente.
Por Que Isso Afeta os Desenvolvedores (e Meus Projetos de Bot)
Para mim, isso se traduz em tempo e esforço desperdiçados. Quando estou construindo um bot, preciso de ferramentas confiáveis. Se um componente de um framework da Apple tem bugs, isso impacta diretamente minha capacidade de entregar um bot estável. Reportar bugs é a minha forma de sinalizar esses problemas, para que eu possa, esperançosamente, obter uma correção ou pelo menos uma solução alternativa, e então seguir em frente.
Quando um relato é fechado com um pedido de “verifique se ainda existe”, a responsabilidade volta para mim. Eu então tenho que:
- Voltar para o projeto ou configuração antigos.
- Repetir os testes que expuseram o bug em primeiro lugar.
- Frequentemente, atualizar para a versão mais recente do SO ou do framework (o que pode introduzir novos bugs ou quebrar meu trabalho atual).
- Gastar mais tempo apenas para provar que um bug ainda é um bug.
Isso não é produtivo. Meu tempo seria melhor gasto construindo novas funcionalidades para meus bots, otimizando seu desempenho ou corrigindo *novos* bugs que inevitavelmente surgem. Não é bem utilizado re-verificando os antigos que deveriam ter sido investigados pelo fornecedor em primeiro lugar.
O Que a Apple Poderia Fazer Melhor
Se a Apple quer que os desenvolvedores contribuam para um ecossistema melhor, eles precisam mostrar que as contribuições dos desenvolvedores são valorizadas. Simplesmente fechar relatos e pedir que re-verifiquemos parece uma forma de limpar sua fila sem realmente abordar os problemas subjacentes.
Uma abordagem melhor seria:
- Comunicar claramente: Se um relato de bug está sendo fechado, declare *por que*. Foi reproduzido? Uma correção foi implementada? É uma limitação conhecida?
- Fornecer contexto: Se eles estão pedindo re-verificação, indique quais mudanças (se houver) foram feitas que poderiam impactar o bug. Isso ajudaria a restringir meus testes novamente.
- Priorizar: Mostrar que eles estão realmente analisando esses relatos. Parece que muitos relatos apenas ficam em uma fila até que acionem algum gatilho arbitrário de “re-verificação”.
Até lá, é apenas mais um obstáculo no já desafiador mundo da construção de bots. E, honestamente, isso me faz pensar duas vezes antes de gastar meu valioso tempo reportando bugs para a Apple em primeiro lugar, o que não é bom para ninguém.
🕒 Published: