Este fin de semana he tenido la ocasión de desarrollar una pequeña aplicación de tareas para Windows Phone 8 para el concurso de desarrollo IAppYou. Como todo desarrollo, no ha estado libre de errores, así como de algún acierto que me gustaría repetir en el futuro, así que más que hablar de características o de cómo pasar información entre dos páginas, me pareció interesante compartir los aciertos, pero sobre todo, los errores.
Error 1: No definir correctamente el modelo de datos
Empecé con una lista, luego una segunda lista, luego una tercera, así tenía listas de listas de elementos que heredaban de otros… y cuando llevaba bastantes horas de desarrollo me di cuenta que esto no funcionaba, así que me tocó rehacer una buena parte, perdiendo unas horas muy, muy valiosas.
Cuando estemos desarrollando la aplicación, es importante sentarnos a pensar cómo van a estar organizados los datos, ya que luego nos será mucho más simple (o al menos, menos doloroso).
Error 2: No tener claras las prioridades
Cuando estás en modo hackathon lo único que que quieres es implementar la mayor cantidad de características en el menor tiempo, y no puedes empezar a pensar en la financiación, la publicidad o las compras in-app cuando no tienes definida ninguna manera de guardar información o acceder a ella una vez se cierre la app.
Error 3: No tener claro el modelo de financiación
Gratis, publicidad, compras in-app, trial? Pasé por todos los modelos hasta que encontré alguno que me gustara. Aprendí muchas características, pero eso, una vez más, me retrasó bastante. Hay cosas que no puedes probar (como las compras in-app) con seguridad hasta que la app no está subida, así que callejón sin salida.
Error 4: Demasiadas características para la primera versión.
Había cosas en el backlog como localización, Azure Web Sites, live tiles, las tareas de windows phone, envío de e-mail, localización, Skydrive… El mayor fallo estuvo en no priorizar qué características deberían salir para la primera versión, y saber cuales se quedarían para las siguientes. (Espero que haya siguientes :))
Error 5: Copy paste development
El peor error de todos, que me costó varias horas de desarrollo, copiar y pegar una función «casi» igual. Ese matiz de «casi» es lo que separa el PropertyChangingEventArgs de PropertyChangedEventArgs.
Es una diferencia que no genera errores de compilación, ni errores de ejecución, ni excepciones, ni trazas, nada. Solamente la aplicación no guarda los cambios en la base de datos, algo que es bastante crítico para un gestor de tareas. Este es un error de principiante que nos puede pasar a todos.
Pero no todo han sido errores, y creo que para esta versión he tenido un par de aciertos:
Acierto 1: Modelo en papel
Esto ha sido importante para evitar perderme en el desarrollo, una navegación clara y en papel, tener claro lo que quería que pasara en cada momento, así cuando tenía que enfrentarme a los problemas de la plataforma, no tenía que pensar qué tenía que hacer la app, porque ya estaba por escrito.
Acierto 2: Backlog de características
Otro acierto interesante, que habría sido mejor sin el fallo #4, pero la idea no era mala. Antes de empezar el desarrollo, hacer una lista de las features que querría ver en la app e intentar ajustarme al plan, agregando las cosas que se me ocurran a una lista (backlog).
Acierto 3: No comenzar a escribir código desde el minuto 0
Esto siempre se nos dice, que pensemos con el ordenador apagado, pero todos siempre empezamos por File > New Project. Es normal cuando estamos empezando una tecnología nueva, pero cuando es nuestra tercera/cuarta app el factor novedad ya ha pasado, y nos puede compensar pararnos a pensar.
Y tú, qué errores has cometido desarrollando apps?
Artículos relacionados
rlbisbe @ dev 
Me parece muy bueno tu comentario, sin embargo es bueno aclarar que ningun proyecto se debe empezar sin planificacion, eso es algo que debe ser obligatorio para cada proyecto, incluso herramientas como UML deben ser declaradas como obligatorias para iniciar cualquier trabajo, y visualizar como tu muy bien lo dices cuales son los targets que persigue esta app.
Gracias por el comentario, es cierto que todos los proyectos deben pasar por una fase de planificación, aunque es habitual cuando estas haciendo un pequeño proyecto con el objetivo de aprender una tecnología, te puedas sentir tentado a empezar a escribir código.
Saludos.
No comparto esto:
«Acierto 3: No comenzar a escribir código desde el minuto 0
Esto siempre se nos dice, que pensemos con el ordenador apagado, pero todos siempre empezamos por File > New Project. Es normal cuando estamos empezando una tecnología nueva, pero cuando es nuestra tercera/cuarta app el factor novedad ya ha pasado, y nos puede compensar pararnos a pensar.»
Lo he leído N veces y no estoy de acuerdo. Personalmente el «hacer» me ayuda a «pensar» y a «descubrir» cosas. Obvio que el proyecto obtendo luego de hacer «File > New Project» no es el definitivo nunca, pero siempre me termina sirviendo.