SÃO FRANCISCO, CA Collin Donnell quer que os desenvolvedores de aplicativos aprendam com seus erros.
Donnell, um desenvolvedor iOS em tempo integral desde 2008, cujos créditos de aplicativos incluem Pinbook para Pinboard, compartilhou algumas dicas para uma sala lotada em AltWWDC, que temos estivetudosobre como uma capa de iPad aconchegante. Ele os dividiu em práticos e filosóficos, mas eles meio que se misturam.
Aqui estão algumas de suas dicas principais:
- Abrande no início.
Pense muito mais antes de começar e projetar o código primeiro.
“Como programadores, queremos pressionar os botões desde o início, mas essa nem sempre é a melhor abordagem.”
Ele recomenda ir para a prancheta com OmniGraffle ou um aplicativo de mapeamento mental, como Mind Node para obter suas ideias antes de começar a digitar. “Projetar o código fornece um roteiro, dessa forma você pode ver onde os gargalos estão à frente. Muitas vezes você está cometendo os mesmos erros e olhar para eles antes de começar às vezes pode evitar isso. ”
- Se você quiser rápido, teste a direção de uma Ferrari, não de um Fiat.
Donnell admite ser um "muito ingênuo" ao testar o download e a análise de dados para Pinbook, um quadro de avisos cuja API funciona um pouco como o Delicious. Pareceu rápido o suficiente quando ele tentou em seus próprios 300 ou mais marcadores, mas como se viu, usuários pesados tinham cerca de 30.000 ou 40.000 marcadores. O aplicativo definitivamente não seria útil se demorasse 10 minutos para sincronizar.
- Se você precisa de alto desempenho, não tenha medo de tomar uma direção diferente, tente algo um pouco mais difícil ou aprenda algo.
Ele precisava diminuir o tempo de espera de sete minutos vagarosos para alguns segundos rápidos, e o o caminho a percorrer acabou exigindo uma mudança no analisador LibXML streaming SAX, que pode ser baixado enquanto analisa. O outro intensificador de velocidade era descobrir uma maneira de buscar objetos que foram atualizados sem uma solicitação de busca durante a análise. A lição foi: por mais caching que você tenha que fazer inicialmente, sempre será mais rápido do que um monte de solicitações de busca. Obter uma assinatura de mudança diria se algo mudou e uma solicitação de busca com dados centrais faria isso.
“Eu não sabia o que ia funcionar e não havia muita documentação. Essa foi uma vantagem difícil de enfrentar ”, disse ele. "Mas se você não gosta porque as coisas difíceis são divertidas, talvez não seja para você."
- Google pode ser seu melhor amigo
Donnell jura por esse método para problemas de desempenho, especialmente quando ele recebeu um aplicativo desenvolvido por outra pessoa.
Primeiro carregue o aplicativo nos instrumentos e, em seguida, ajuste as configurações para que ele mostre a árvore de chamada reversa. Nesse ponto, você tem uma ideia do que está causando o problema. Então Donnell diz que cola isso no Google, adicionando a palavra “lento” depois. “Você ficaria surpreso com quantas vezes alguém escreveu uma postagem de blog realmente detalhada explicando por que é mais rápido transformá-lo em um NSData e obter o alcance da comparação lá ”e voila ', seu aplicativo lento está agora de volta acompanhar.
“Todos nós gostamos de escrever posts sobre todas as coisas divertidas que descobrimos”, disse ele, então aproveite isso. Por outro lado: ajude aqueles que vierem depois de você, compartilhando coisas legais que você descobriu.
- Seis graus de Kevin Bacon são divertidos em uma festa, mas não para o seu código
Sempre que puder, favoreça uma conexão mais direta em vez de uma menos direta, para que você possa seguir o caminho do código de componente a componente. E mantenha esses componentes o menor possível, para que você possa separá-los para acelerar as coisas. “Se escrever um delegado é mais digitar, mas sei que é a melhor coisa a fazer, é isso que farei... Quando faço algo menos direto, acaba criando problemas. Você não consegue descobrir por que existem seis graus de Kevin Bacon enviando uma notificação ”e você está preso.
“Não sou inteligente o suficiente para escrever um código tão ruim. Para mim, código ruim que não tem um bom desempenho é geralmente um código complicado, então geralmente mantenho a simplicidade. Se eu fosse mais inteligente ou tivesse um diploma de ciência da computação, provavelmente seria melhor escrevendo coisas com pior desempenho. ”