Há quem já esteja usando o iOS/iPadOS 13 ou o macOS Catalina 10.15 e não tenha nenhuma reclamação quanto aos softwares mais recentes da Apple; por outro lado, existe também um grupo de usuários (principalmente desenvolvedores e engenheiros de software) que sabem quando algo não vai tão bem quanto o esperado, mesmo que isso não cause um alarde generalizado.

Esse é o caso do ex-Apple David Shayer, que trabalhou em Cupertino como engenheiro de software por mais de 18 anos. Nesta semana, ele compartilhou um “desabafo” sobre os novos sistemas da Apple, apontando seis possíveis razões para que eles estejam mais “bugados” que o normal.

O iOS 13 e o macOS 10.15 Catalina foram lançamentos da Apple cheios de bugs incomuns. Os betas já foram lançados com erros na WWDC em junho, o que não é inesperado, mas mesmo depois que a Apple removeu alguns recursos antes do lançamento final em setembro, mais problemas obrigaram a empresa a publicar atualizações de correção. Por quê? Com base em meus 18 anos de experiência trabalhando como engenheiro de software da Apple, tenho algumas ideias.

Implementação de recursos avançados inacabados

Segundo Shayer, a Apple é “agressiva” ao incluir recursos significativos em seus novos softwares. Isso significa que os desenvolvedoras da Maçã devem trabalhar incessantemente para dar conta do recado a tempo de cada lançamento, porém isso também tem um custo: é inevitável que um ou outro recurso não fique pronto e seja adiado para futuros lançamentos, como o caso do compartilhamento de pastas do iCloud Drive.

Em um projeto bem executado, os recursos que estão atrasados ​​são cortados previamente para que os engenheiros possam dedicar seu tempo a polir os recursos que realmente serão incluídos.

O engenheiro sugere que a Apple passe a não incorporar tantos novos recursos em cada versão dos seus softwares justamente para evitar problemas assim, mas de antemão ele afirma que essa não é a “cultura” da Maçã.

Erros “identificáveis”

Tanto o iOS quanto o macOS possuem um recurso interno responsável por enviar relatórios de erros do sistema para a Apple. É vero que tais relatórios incluem muitos dados, porém o principal deles é stack trace, também conhecido como rastreamento de pilha, o qual informa exatamente onde o erro ocorreu a partir de um “mapa” de execução do sistema no momento em que tal falha se deu.

Em suma, são esses dados que ajudam os desenvolvedores a saberem especificamente onde está o erro, mas não tem como eles conhecerem uma possível falha se certos problemas não são reconhecidos como tais.

Nesse sentido, Shayer aponta que os relatórios de erros da Maçã não incluem dados sobre fotos que nunca são enviadas para o iCloud, falhas de sincronização de contatos do Mac para o iPhone (e vice-versa), backups do Time Capsule corrompidos e, ainda, um tipo de problema específico enfrentado por ele, no qual a tela de configuração do iPhone 11 exigia o login no iCloud repetidas vezes.

Isso se dá, em parte, porque a Maçã rastreia esses erros bugs da maneira antiga: com pessoas (engenheiros de controle qualidade) testando os aparelhos ou acompanhando testes automatizados, além de relatórios de desenvolvedores e reclamações enviadas ao Suporte da Apple. Para Shayer, esse método torna muito mais difícil identificar os bugs e, para os engenheiros, consertá-los.

Erros menos importantes são “filtrados”

Shayer também ilustrou outra característica do processo de criação de um novo software da Apple que pode contribuir para o número de bugs no lançamento de um sistema final; nele, os desenvolvedores da Maçã tem níveis de liberdade diferentes para consertar certos problemas à medida em que o desenvolvimento do software avança.

Mais precisamente, ele afirma que, no início, os desenvolvedores têm praticamente total liberdade de corrigir qualquer bug, mas essa possibilidade é reduzida ao passo em que ele vai ficando mais complexo, por um motivo técnico e bem simples: na programação, é bem provável você mexer em algo e atrapalhar outra coisa — imaginem isso em nível de sistema operacional.

Portanto, apenas os erros mais graves são corrigidos às vésperas do lançamento de um novo iOS/macOS, justamente porque a Apple não pode arriscar atrapalhar tudo o que foi feito antes caso, digamos, o usuário tenha decidido ajustar a data do iPhone para 1º de janeiro de 1970 e ele travar por completo.

Assim, os bugs que são raros ou não “terrivelmente graves” — como aqueles que causam mera confusão em vez de perda de dados — são “empurrados” para segundo plano pelo sistema de “triagem” da companhia.

Erros antigos perpetuarão para sempre

A característica acima leva a outra: se um problema viveu o suficiente por mais de uma geração do iOS/macOS, as chances de ele ser corrigido pela Apple são ínfimas. De acordo com Shayer, a gigante de Cupertino é “péssima em corrigir erros antigos”, justamente porque eles são comercialmente inviáveis e algumas possíveis correções podem atrapalhar os softwares mais recentes.

Mais precisamente, ele afirma que, se um engenheiro de controle de qualidade determinar que um bug existe apenas em versões antigas do SO, ele é marcado como “não regressivo”, ou seja, a possibilidade de ele afetar os novos sistemas é baixa e, assim, muito provavelmente nenhum profissional será designado para corrigi-lo.

Poucos testes automatizados

Aqui, Shayer faz mais uma constatação do que uma crítica, de fato. Segundo ele, hoje em dia os testes automatizados estão em alta, mas a Apple, como já dito, prefere executar algumas análises manualmente, algo que pode se mostrar como uma faca de dois gumes para a companhia.

O engenheiro confessa que a área na qual a Maçã realiza o maior número de testes automatizados está relacionada à bateria de seus produtos. Assim, sempre que uma grande mudança é realizada em seus sistemas operacionais, a equipe corre com os aparelhos de testes para verificar se a alteração não afetou o desempenho da bateria; ainda assim, esses testes analisam apenas o código da Apple, numa tentativa de simular as interações “no mundo real” que possam resultar em problemas significativos para os usuários.

Além da bateria, outro setor que utiliza com certa frequência os testes automatizados é o de desenvolvimento Safari, no qual qualquer novo código adicionado ao navegador exige a execução de um teste de performance. Sendo assim, Shayer sugere que mais testes automatizados poderiam ajudar a aumentar a qualidade dos softwares da Apple.

Aumento da complexidade

Não há como negar que o iOS 13 oferece muito mais recursos do que a versão anterior a ele, e assim por diante — esse, afinal, é o fundamento de se ter novas versões sucessivas, com novidades. Ao mesmo tempo, isso também serve com gatilho para o surgimento de novos problemas, que antes não existiam ou não eram tão graves.

Dessa forma, o engenheiro afirma que um sistema operacional moderno da Apple possui dezenas de milhões de linhas de código. Além disso, cada Mac, iPhone, iPad, Apple Watch, AirPods e HomePod conversa entre si e com o iCloud. Todos os aplicativos são multiencadeados e se comunicam por meio da internet, a qual também tem seus problemas.

Tudo isso dificulta o desenvolvimento e os testes de todos os recursos, bem como a descoberta de novos bugs. Somam-se a isso acontecimentos assíncronos e que não dependem da Apple, permitindo que diversas falhas passem pelo crivo dos engenheiros da Maçã, contribuindo para que eles cheguem ao consumidor final.

·   •   ·

Bom, não é fácil também ser a Apple. Além disso, todos os fatores supracitados podem ser entendidos como possíveis causas para 1) a existência de falhas em qualquer sistema operacional, e 2) para o maior número de atualizações de software liberadas pela Maçã.

Nesse sentido, Shayer garante que a Apple lançará mais correções de erros (em forma de atualizações de software) do que estávamos acostumados, mas que isso também é um sinal positivo, pois comprova que a companhia está aquém das suas falhas.

Você pode conferir o relato completo do engenheiro por aqui.

via Daring Fireball

Taggeado:

Posts relacionados

Comentários