SAN FRANCISCO, CA Collin Donnell quiere que los desarrolladores de aplicaciones aprendan de sus errores.
Donnell, un desarrollador de iOS a tiempo completo desde 2008 cuyos créditos de aplicaciones incluyen Pinbook para Pinboard, compartió algunos consejos para una sala llena en AltWWDC, que tenemos estadotodossobre como una funda de iPad acurrucada. Los dividió en prácticos y filosóficos, pero en cierto modo se mezclan.
Éstos son algunos de sus principales consejos:
- Reduzca la velocidad al principio.
Piense mucho más antes de comenzar y diseñe el código primero.
"Como programadores, queremos presionar los botones desde el principio, pero ese no es siempre el mejor enfoque".
Recomienda ir a la mesa de dibujo con OmniGraffle o una aplicación de mapas mentales como Nodo mental para plasmar sus ideas antes de empezar a escribir. “El diseño del código proporciona una hoja de ruta, de esa manera puede ver dónde están los cuellos de botella desde el principio. A menudo comete los mismos errores y mirarlo antes de comenzar a veces puede evitarlo ".
- Si quieres rápido, asegúrate de estar probando un Ferrari, no un Fiat.
Donnell admite ser un "bastante ingenuo" al probar la descarga y el análisis de datos para Pinbook, un tablón de anuncios cuya API funciona un poco como Delicious. Parecía lo suficientemente rápido cuando lo probó con sus propios 300 marcadores, pero resultó que los usuarios habituales tenían más de 30 000 o 40 000 marcadores. La aplicación definitivamente no sería útil si tardaba 10 minutos en sincronizarse.
- Si necesita un alto rendimiento, no tenga miedo de tomar una dirección diferente, intente algo un poco más difícil o aprenda algo.
Necesitaba reducir ese tiempo de demora de unos tranquilos siete minutos a unos pocos segundos rápidos, y el camino por recorrer terminó requiriendo un cambio en el analizador SAX de transmisión LibXML, que puede descargarse analiza. El otro potenciador de velocidad fue encontrar una forma de recuperar objetos que se han actualizado sin una solicitud de recuperación durante el análisis. La lección fue: sin importar cuánto almacenamiento en caché tenga que hacer por adelantado, siempre será más rápido que un montón de solicitudes de recuperación. Obtener una firma de cambio indicaría si algo había cambiado y una solicitud de recuperación con datos básicos lo haría.
“No sabía qué iba a funcionar y no había mucha documentación. Esa fue una ventaja difícil para mí con la que chocar ”, dijo. "Pero si no te gusta porque las cosas difíciles son divertidas, tal vez no sea para ti".
- Google puede ser tu mejor amigo
Donnell confía en este método para los problemas de rendimiento, especialmente cuando se le entregó una aplicación que desarrolló otra persona.
Primero cargue la aplicación en los instrumentos, luego modifique la configuración para que le muestre el árbol de llamadas inverso. En ese momento, tiene una idea de la causa del problema. Luego Donnell dice que lo pega en Google, agregando la palabra "lento" después. "Te sorprendería saber cuántas veces alguien ha escrito una publicación de blog muy detallada que explica por qué es más rápido conviértalo en un NSData y obtenga el rango de la comparación allí "y listo", su aplicación lenta ahora está de vuelta pista.
“A todos nos gusta escribir publicaciones en blogs sobre todas las cosas divertidas que descubrimos”, dijo, así que aproveche eso. Por otro lado: ayude a quienes vengan después de usted compartiendo lo bueno que descubrió.
- Seis grados de Kevin Bacon es divertido en una fiesta, pero no para tu código
Siempre que pueda, favorezca una conexión más directa sobre una menos directa, de modo que pueda seguir la ruta del código de un componente a otro. Y mantenga esos componentes lo más pequeños posible, para que pueda separarlos para acelerar las cosas. “Si escribir a un delegado es más mecanografiado pero sé que es lo mejor que puedo hacer, eso es lo que voy a hacer... Cuando hago algo menos directo, termina creando problemas. No puede averiguar por qué hay seis grados de Kevin Bacon enviando una notificación "y estás atascado.
"No soy lo suficientemente inteligente para escribir un código tan malo. Para mí, el código incorrecto que no funciona bien suele ser un código complicado, por lo que normalmente lo mantengo simple. Si fuera más inteligente o tuviera un título en ciencias de la computación, probablemente sería mejor escribiendo cosas que funcionen peor ".
