SAN FRANCISCO, CA Collin Donnell veut que les développeurs d'applications apprennent de ses erreurs.
Donnell, un développeur iOS à temps plein depuis 2008 dont les crédits d'application incluent Pinbook pour Pinboard, a partagé quelques conseils dans une salle comble à AltWWDC, que nous avons ététousplus de comme un étui iPad câlin. Il les a divisés en pratique et philosophique, mais ils se mélangent en quelque sorte.
Voici quelques-uns de ses principaux conseils :
- Ralentissez au début.
Réfléchissez beaucoup avant de commencer et concevez d'abord le code.
"En tant que codeurs, nous voulons appuyer sur les boutons dès le début, mais ce n'est pas toujours la meilleure approche."
Il recommande d'aller à la planche à dessin avec OmniGraffle ou une application de cartographie mentale telle que Nœud de l'esprit pour vous faire une idée avant de commencer à taper. « La conception du code fournit une feuille de route, de cette façon, vous pouvez voir où se trouvent les goulots d'étranglement. Souvent, vous faites les mêmes erreurs et les regarder avant de commencer peut parfois empêcher cela.
- Si vous voulez être rapide, assurez-vous de tester la conduite d'une Ferrari, pas d'une Fiat.
Donnell admet être un "assez naïf" lors des tests de téléchargement et d'analyse des données pour Pinbook, un tableau d'affichage dont l'API fonctionne un peu comme Delicious. Cela semblait assez rapide quand il l'a essayé sur ses propres 300 signets, mais il s'est avéré que les gros utilisateurs avaient plutôt 30 000 ou 40 000 signets. L'application n'allait certainement pas être utile si la synchronisation prenait 10 minutes.
- Si vous avez besoin de hautes performances, n'ayez pas peur de prendre une direction différente, essayez quelque chose d'un peu plus difficile ou apprenez quelque chose.
Il avait besoin de réduire ce temps de latence de sept minutes tranquilles à quelques secondes rapides, et le chemin à parcourir a fini par nécessiter une modification de l'analyseur SAX en streaming LibXML, qui peut être téléchargé au fur et à mesure analyse. L'autre accélérateur de vitesse consistait à trouver un moyen de récupérer les objets qui ont été mis à jour sans demande de récupération lors de l'analyse. La leçon était la suivante: quelle que soit la quantité de mise en cache que vous devez effectuer en amont, elle sera toujours plus rapide qu'un tas de requêtes d'extraction. Obtenir une signature de changement indiquerait si quelque chose a changé et une requête d'extraction avec des données de base le ferait.
« Je ne savais pas ce qui allait fonctionner et il n’y avait pas beaucoup de documentation. C'était un avantage pour moi contre lequel me heurter », a-t-il déclaré. "Mais si vous n'êtes pas dedans parce que les choses difficiles sont amusantes, ce n'est peut-être pas pour vous."
- Google est peut-être votre meilleur ami
Donnell ne jure que par cette méthode pour les problèmes de performances, en particulier lorsqu'on lui a remis une application développée par quelqu'un d'autre.
Chargez d'abord l'application dans les instruments, puis modifiez les paramètres pour qu'elle vous montre l'arborescence des appels inversée. À ce stade, vous avez une idée de la cause du problème. Ensuite, Donnell dit qu'il colle cela dans Google, ajoutant le mot "lent" après. « Vous seriez surpris du nombre de fois où quelqu'un a écrit un article de blog vraiment détaillé expliquant pourquoi il est plus rapide de transformez-le en NSData et obtenez la gamme de la comparaison là-bas" et le tour est joué, votre application lente est maintenant de retour Piste.
"Nous aimons tous écrire des articles de blog sur toutes les choses amusantes que nous découvrons", a-t-il déclaré, alors exploitez-le. D'un autre côté: aidez ceux qui vous suivent en partageant la chose intéressante que vous avez découverte.
- Six degrés de Kevin Bacon est amusant lors d'une fête, mais pas pour votre code
A chaque fois que vous le pouvez, privilégiez une connexion plus directe par rapport à une connexion moins directe, afin de pouvoir suivre le chemin du code d'un composant à l'autre. Et gardez ces composants aussi petits que possible, afin de pouvoir les séparer pour accélérer les choses. « Si écrire un délégué c’est plus taper mais je sais que c’est la meilleure chose à faire, c’est ce que je vais faire… Quand je fais quelque chose de moins direct, ça finit par créer des problèmes. Vous ne pouvez pas comprendre pourquoi il y a six degrés de Kevin Bacon envoyer une notification" et vous êtes bloqué.
« Je ne suis pas assez intelligent pour écrire du code aussi mauvais. Pour moi, un mauvais code qui ne fonctionne pas bien est généralement un code compliqué, donc je le garde généralement simple. Si j'étais plus intelligent ou si j'avais un diplôme en informatique, je serais probablement meilleur pour écrire des trucs qui fonctionnent moins bien.