Flávio Caetano (@flavio_caetano) desenvolve para iOS desde 2011, quando a gerência de memória era manual e storyboard era coisa de cinema. Já trabalhou em alguns dos maiores (e menores) apps do Brasil e atualmente lidera o desenvolvimento em iOS no Winnin.
Este post é um complemento ao talk Bugreport 101 apresentado no 28º CocoaHeads SP
É muito fácil encontrar desenvolvedores que já acharam algum tipo de bug em código de terceiros. Seja numa lib externa, seja no SDK da Apple. Nosso código, lindo e cheiroso, com um comportamento indesejado por causa de uma pessoa que não está nem na mesma folha de pagamentos que você. Também não é difícil encontrar devs que já reportaram tais bugs para os responsáveis pelo código ou que contribuíram para a sua correção de alguma forma. Mas, não tão fácil é encontrar desenvolvedores que reportaram algum tipo de bug para a Apple.
A falta de material sobre bugreport, seja motivacional, sejam guidelines, acentuam esse fato. Frequentes são os reports sem informação relevante, com dados confidenciais ou cópias idênticas de reports já preenchidos sem adição de nenhum dado novo.
Na esfera do desenvolvimento para plataformas Apple, não importa o quão individualista você seja. Mesmo que não use nenhuma biblioteca de terceiros, todos estamos sob o guarda-chuva do SDK da Apple. Não importa o quão blindado o seu código seja de desenvolvedores externos, todos estamos sujeitos aos erros e acertos dos desenvolvedores da Apple.
Ilumine o problema
O motivo principal para reportar um bug não é óbvio. Ferramentas de issue tracking foram criadas para relatar incidentes, isto é, chamar atenção para um comportamento inesperado.
Secundariamente, a correção do bug motiva o report. Se houver um workaround, ou alguma forma de contornar o problema, a correção do bug pode não ser prioritária.
Ademais, não podemos nunca esquecer de quem cria essas bibliotecas. Relatar uma issue demonstra apoio ao código que usamos e às pessoas que o constroem, por isso, não peça desculpas ao reportar um bug. Agradeça pela criação da biblioteca.
Bugreport é dinheiro
Grandes empresas precisam tanto de ajuda que tornaram programas de Bug Bounty lugar-comum. A demanda por relatórios de exploits e vulnerabilidades é tão grande que Facebook, Github, Google, Microsoft e diversas outras empresas reconhecem e recompensam aqueles que descobrem e resolvem bugs antes destas inconsistências se tornarem públicas.
Em 2016 o Departamento de Defesa americano anunciou um programa chamado Hack the Pentagon no qual especialistas em seguranças foram convidados a tentar invadir páginas públicas do Pentágono em busca de falhas de segurança. Mais de US$71.000 foram pagos em recompensas.
Também em 2016, a Apple anunciou a criação do seu programa de Bug Bounty. Relatos dizem de recompensas de até US$200.000 porém a participação no programa só é possível através de convites.
Os 4 passos para um bom report
Diversas plataformas oferecem templates de relatórios, o Github inclusive disponibiliza o arquivo CONTRIBUTING guidelines para que cada repositório documente como relatar e contribuir com o desenvolvimento dos códigos. No entanto, com tantas possibilidades e sem um padrão, nem sempre é fácil focar e ser conciso na redação do relatório.
1. Tenha clareza sobre a inconsistência
Na introdução do relatório, seja claro sobre o comportamento obtido. O que era esperado? O que realmente está acontecendo?
2. Defina os passos para reproduzir o bug
Inclua os passos para reproduzir e informe se o comportamento for intermitente. Não tem problema se não der para reproduzir o bug todas as vezes, mas tenha certeza de que os passos descritos podem levar à alguma inconsistência.
3. Inclua exemplos de código
Se for um relatório para a Apple, sempre anexe um projeto ou playground contendo a reprodução da inconsistência no seu radar. No caso de uma issue no Github, pode-se incluir snippets com códigos de exemplos ou até links para repositórios contendo um projeto ou playground de exemplo.
4. Sugira uma correção ou workaround
Se você souber a causa do bug ou onde ele ocorre, sugestões de correção são mais que bem-vindas. Ou melhor que isso, corrija a inconsistência e já abra um pull-request com o fix da inconsistência.
Bugreports no Github
Acredito que o Github peça alguns cuidados especiais no relatório de incidentes, afinal, em repositórios open-source, as pessoas contribuem por boa vontade e, embora sejam os responsáveis pelo código, não é trabalho de ninguém ficar corrigindo os erros e inconsistências que estão te afetando.
É importante não ter medo de falar bobagem. A comunidade de iOS, especialmente, é super receptiva e tolerante. Ninguém vai ficar apontando dedos ou fazendo graça, e se você disser alguma besteira, no máximo será corrigido com educação.
A língua-comum da internet é a Língua Inglesa, mas nem todos são fluentes e menos ainda a têm como língua nativa. Não tenha vergonha e nem medo do seu inglês. É comum encontrar pessoas de diversas partes do mundo cometendo erros gramaticais e ninguém é corrigido, ignorado ou menosprezado porque não falou inglês perfeito. Cometemos erros até na hora de escrever em português (este artigo mesmo deve conter alguns), o que dirá em um idioma que não é o nosso. Lembre-se que a prática leva à perfeição.
Além disso, tenha em mente que os projetos e bibliotecas do Github são comunitários, consequentemente, como em toda democracia propriamente dita é comum que correções e proposals de incrementos sejam longamente debatidos antes de se chegar num acordo sobre a melhor forma de proceder. Portanto, seja coerente, tenha paciência e saiba argumentar escutando o lado oposto. Esta pode ser uma oportunidade fantástica para você aprofundar o seu conhecimento sobre aquela ferramenta, além de receber comentários sobre o seu código de desenvolvedores fantásticos que criam as bibliotecas mais usadas do mundo. Escute e aprenda!
Ainda sobre o assunto, recomendo o excelente artigo O mundo é mais que seu umbigo do Fabri que inaugurou o equinociOS
Bugreports para a Apple
A Apple possui o seu portal onde podem ser relatados issues e feature requests. Numa interface de gosto duvidoso (nem parece coisa de Jony Ive)
Para aqueles que não gostam do portal, há também o QuickRadar que provê uma interface muito mais limpa e não pede que você se logue toda vez que quiser reportar uma issue, além de te oferecer um template simples num campo de texto único para preenchimento.
Os bugs reportados para a Apple são privados por questão de segurança. Embora o grosso dos bugs seja comportamental, existem vulnerabilidades e falhas de segurança que podem ser exploradas para obter vantagem sobre os usuários e que não podem se tornar públicas para evitar exposição. Por isso, surgiu o OpenRadar que tenta ser um espelho do portal da Apple, onde os desenvolvedores replicam seus relatórios para torná-los públicos. Uma das vantagens do QuickRadar é mandar as suas issues automaticamente para o OpenRadar, mitigando a necessidade de preencher tudo duas vezes.
O OpenRadar ainda oferece a possiblidade de comentar nas páginas das issues o que acrescenta uma dinâmica mais rica na interação com a comunidade. Em 2016 reportei um bug na UICollectionView que os engenheiros da Apple descartaram como sendo o comportamento correto. Discordei da decisão mas como bug documentado é feature pedi para que tal comportamento fosse adicionado na documentação, pedido que foi ignorado, e no rdar://28323532 podemos ver que o usuário nicolas.millasseau também discordou da decisão dos engenheiros.
Reporte duplicatas
Não se acanhe e nem se desmotive se seus bugs estiverem sendo sinalizados como duplicatas. É improvável ser o primeiro a relatar um incidente, o que torna a ocorrência de duplicatas ainda mais comum, mas isso não tira a sua importância, já que quanto mais gente sendo afetada por aquele problema, mais a prioridade da issue tende a subir. Além disso, duplicatas apresentam abordagens diferentes de uma inconsistência.
Consequentemente, ao reportar uma duplicata, você está fornecendo mais informação que pode ajudar na resolução de um incidente. Pode ser que você esteja conseguindo reproduzir o bug de uma forma diferente, ou então que você saiba de alguma solução ou workaround para o ocorrido, ou até que o seu crashlog contenha informações complementares aos outros radares.
No Github, há uma controvérsia quanto ao 👍. Acredito ser importante adicionar o +1 nas issues como forma de sinalizar uma duplicata, pois caracteriza que há mais gente sendo afetada por aquela inconsistência, porém há quem acredite que não agrega em nada. Inclusive, na sessão 213 da WWDC, os engenheiros da Apple pedem que, ao criar um radar, não simplesmente copie e cole um já existente pois isso não agrega informação e não sobe a prioridade.
Caso algum radar seu seja marcado como uma duplicata, será informado o id da issue original, que pode ser buscado no OpenRadar onde pode-se ler os comentários para saber se há alguma forma de contornar o problema, qual o status atual (se estiver atualizado) e o que a comunidade está falando em geral sobre isso.
Deal with it 🕶
“Não apresente problemas, apresente soluções” - eu mesmo
Leve este mantra para a sua vida: “reclame menos”. Se você tem poder para mudar algo, não reclame: mude! Se você não tem poder para mudar, de que adianta reclamar? Na hora de resolver uma situação, seja no trabalho, seja em casa ou na rua, não apresente um problema: apresente uma solução. Isso não significa que você deve reportar menos bugs, justo pelo contrário! Reportar um bug é o primeiro passo para resolvê-lo.
Se você reportar um bug, sempre que possível, apresente um fix ou ao menos um workaround. Se for no Github, submeta um pull-request. Seja pró-ativo e resolva seu próprio problema ao invés de esperar que os outros o resolvam por você.
De nada adianta chorar sem agir. Ilumine o problema. Seja parte da solução. Melhore as ferramentas que você usa no dia-a-dia. Diminua a sua dor. Otimize o seu tempo. Ajude a comunidade a crescer. Pode ter certeza que no caminho você cresce junto.