Al contrario que en el 2007, donde todo lo que hice en CS3 y AS3 fue en solitario, durante este año he trabajado en varios proyectos en equipo, tanto con compañeros de mi agencia como estudios o freelances. En general, me considero bastante flexible a la hora de trabajar con otros programadores y no intento imponer nada (y más en el mundillo Flash, donde hay mil maneras distintas de alcanzar un objetivo), pero aún así, he llegado a la conclusión de que hacen falta una serie de “buenas prácticas” para que el proceso no sea un sufrimiento para el resto.
Los puntos que voy a explicar me parecen igual de válidos si se trabaja solo, pero obviamente la repercusión es mucho menor porque no afecta a nadie más. Y con trabajar en equipo no me refiero sólo a dos o más personas simultáneamente, sino también aquellos desarrollos que un día empieza uno y luego ha de continuar otro.
Separar código fuente y archivos finales
Hace no muchos años era frecuente ver proyectos como el siguiente
donde los fla, html, xml, jpg, etcétera convivían mezclados. Y también era normal que allá donde hubiera un fla estuviera su correspondiente swf. Evidentemente, esto no facilita nada la navegación por el proyecto ni poder mover el directorio de producción entre diferentes servidores. Y no todo el mundo ha conseguido desprenderse de este viejo hábito.
A no ser que sea un proyecto muy pequeño (un banner o similar), es imprescindible contar con carpetas separadas para el código fuente y para los archivos finales. Yo suelo utilizar como nomenclatura src y bin, o también source y deploy.
Bibliotecas ordenadas
¿Hay alguien que no odie abrir un fla y encontrarse cientos de símbolos desperdigados en la biblioteca? En todos los años que llevo utilizando Flash he visto muy poca gente que le dedique tiempo a ordenar coherentemente la librería.
El sistema que suelo utilizar es un árbol de carpetas con la misma estructura que siguen los movieclips en la linea de tiempo. Me gusta porque al tener una relación 1 a 1 es facilísimo encontrar cualquier elemento y navegar por la biblioteca como si fuera el escenario, aunque por contra obliga a generar demasiadas carpetas y niveles y hay que ser muy exhaustivo.
Tampoco me desagrada ordenar por grupos lógicos (por ejemplo, una carpeta para el “Panel de Login”, otra para el “Menú de navegación”, etc) siempre y cuando no haya demasiado contenido. En ese caso, prefiero añadir más directorios intermedios.
Código en timeline y en la clase
Normalmente intento reducir al mínimo el código en linea de tiempo, aunque tampoco me opongo en rotundo (a veces es mejor picar 2 o 3 instrucciones en un frame que no generar una clase nueva).
También en algunas ocasiones hay que poner código en frames en movieclips que cuentan con su propia clase. Cuando un mc tiene una clase asociada ésta se ejecuta en el primer frame, así que, por ejemplo, no podemos escuchar un TextInput que se encuentra en el frame 5. Tendremos que esperar hasta alcanzar dicho frame para poder referenciarlo. Hay que tener mucho cuidado con esto porque puede hacer el seguimiento muy difícil al estar divido el código en 2 sitios.
A mi parecer, lo más “limpio” es dispachar eventos notificando en que punto nos encontramos, e intentar que el framecode no se encargue de hacer demasiadas tareas.
Se haga lo que se haga, es muy importante comentar tanto en el frame como en la clase, indicando quién hace qué, porque sino te puedes volver realmente loco.
Instanciando desde la biblioteca
Me parece genial que en AS3 ya no se utilice más attachMovie y que siempre haya que generar nuevas instancias con el operador new. De todas maneras, la ventaja de attachMovie era que inmediatamente sabías que se utilizaba una instancia de la biblioteca, y ahora no. En este caso, me parece más que interesante comentar indicando que la clase se encuentra en la librería.
Y de manera contraria, me parece también necesario comentar al inicio las clases que tienen un movieclip o un sprite asociado, ya que sino lo sabes puedes perder mucho tiempo buscando en el resto de clases quién instancia cuando resulta que simplemente se ha arrastrado un elemento al escenario.
NO declarar instancias del escenario automáticamente
Ya hace tiempo dediqué un extenso apartado a explicar en que consiste esta opción que nos facilita Flash CS3 y cómo funciona internamente:
Básicamente nos permite no tener que declarar en nuestra clase propia los movieclips que se han añadido manualmente al escenario. Personalmente me parece un error, ya que luego no sabes de dónde salen los objetos, y crea muchísima más confusión si el código no es tuyo.
Siempre, al principio de cada clase, declaro todos los objetos del escenario:
[as3]// MC en el escenario
public var fullscreen_mc:MovieClip;
public var opciones_mc:MovieClip;
public var panel_mc:MovieClip;
public var slider_radio:Slider;
public var check_circular:CheckBox;[/as3]
así, de un vistazo se sabe qué instancias se encuentran en el fla, y además habilita el código de
autocompletado en editores como FlashDevelop.
Activar modo estricto
Como ya sabemos, ActionScript cuenta con dos modos para compilar un programa: el modo estricto y el modo estándar. En modo estricto el compilador resuelve los errores tanto en tiempo de compilación como en tiempo de ejecución, con lo que nos proporciona mucha más información si algo no funciona como debería.
Uno de los mayores problemas del modo estricto es que muchas de las fallas que detecta no son errores “reales”, simplemente es que el compilador no tiene información suficiente sobre qué está pasando y no nos deja continuar. Es aquí donde entra la tediosa tarea de castear objetos. Otras veces el problema puede ser tan insignificante como usar dos veces una variable en una función (la típica i en un for).
Hay programadores que optan por desactivar esta opción evitándose este tipo de errores. Aunque al principio se puede pensar que se gana tiempo, nada más lejos de la realidad: cuesta muchísimo más encontrar errores tontos (del tipo llamar a una función que no existe o pasar un número incorrecto de argumentos) que ser minucioso con el código que se escribe.
Siempre pongo el paralelismo de las variables en AS1 cuando no se tipaban: era mucho más cómodo no tener que decir si una propiedad era un String o un Int, pero en cuanto uno se acostumbra los beneficios son muchísimos más. No me imagino a nadie que programe en AS3 que no utilice el tipado. Lo mismo debería ocurrir con el modo estricto.
Resumiendo
En el título del post hablo de “consejos” porque entiendo que no todo el mundo estará de acuerdo con que los puntos son tan importantes, pero para mí, van a ser un requisito en futuros proyectos en que trabaje con más gente.
Me parece que seguir estas pautas no supone un gran sacrificio, y realmente pueden ahorrar mucho mucho tiempo a otras personas.
Muy buen artículo/Blog :)
Lo único que añadiría es seguir un estilo de programación y nomenclatura común, el que sea pero común.
Gracias!
Sería ideal, pero éste es un punto más delicado. Si me obligaran a cambiar mi nomenclatura me costaría bastante aceptar :) Personalmente, mientras haya un mínimo de coherencia me basta.
Por cierto, desde hace varios meses tengo un artículo a medias sobre este tema. A ver si me animo y lo acabo…
Realmente este es uno de los primeros artículos que escucho para el trabajo en equipo en proyectos de as3, con el tiempo mi equipo a optado formas de trabajar muy similares a la que usted expone aquí y hemos obtenido buenos resultados, gracias!
Hablando de trabajo en equipo incluiría algún consejo adicional sobre herramientas de control de versiones. Sin decantarse sobre ninguna en concreto, pero sí de usarlas.
Saludos!
Lo de no instanciar de la libreria debe ir por mi, pero bueno almenos la libreria venia ordenada :)
Estoy deacuerdo, con lo que dices si veo algun otro punto que pueda ser considerado lo pondre por aqui.
#4 Reconozco que yo he sido uno de esos cabezotas que se resistían a usar control de versiones hasta no hace mucho. Ahora no sé vivir sin él. Al margen de Flash, un CVS en desarrollo es imprescindible (aunque esté uno solo)
#5 Hombre Jordi, qué sorpresa :)
Que conste que yo no digo que no se deba instancia de la librería, es más, en muchos casos me parece absurdo hacerlo dinámicamente, pero sí que creo que por el modelo este mixto que tiene Flash, si se comenta se gana mucho tiempo y claridad. Y sí, la biblioteca estaba de coña ;)
Y obviamente, cualquier otra práctica de este tipo es bienvenida. Mola aprender de la forma de trabajar de otros. Saludos!
Es un artículo genial, gracias por compartilo. Añado un pequeño apunte, desde las primeras versiones de Flash, ahora mismo me viene a la memoria Flash 5, siempre me ha gustado leerme la ayuda para tener un buen comienzo y ahí mismo, en la documentación de Flash existe un capítulo “Prácticas recomendadas”, donde se recogen muchas de las prácticas que comentas en este post, en la documentación online de Flash CS3 es el siguiente link:
http://livedocs.adobe.com/flash/9.0_es/UsingFlash/help.html?content=WSd60f23110762d6b883b18f10cb1fe1af6-7b5e.html
Y para Flash CS4 es el siguiente:
http://help.adobe.com/en_US/Flash/10.0_UsingFlash/flash_cs4_help.pdf
Saludos, me encanta su blog :D
Excelente articulo!
Estoy 100% de acuerdo con tus ideas de organizacion!
La verdad nunca desactive la declaracion automatica de MovieClips del escenario, pero me parece una muy buena practica la cual probare en futuros proyectos.
Como siempre un grande Llops!
abrazos
Yo añadiría:
– Números mágicos en vez de constantes o en vez de usar las proporciones de los objetos o el Stage.
– Código sin tabular o mal tabulado.
– Comentarios
No te imaginas la tiempo que he perdido con archivos .fla que no siguen ninguna de las recomendaciones que dan. Es como bajar a lo oscuro del averno…
Lo puedo decir, he trabajado con Dani y es un placer. Porque aun uso su metodología. Sobre todo lo de separar archivos fuente de archivos finales. Aun en el estudio me preguntan el por qué de esa nomenclatura ( source y deploy) y me acuerdo del site de BMW que hice con llops. Tambien su “manía” buena de ordenar todas las bibliotecas. Y ahora me alegro . Tambien es importante que la gente postee artículos como este. El proceso , como nos lo montamos es fundamental. Dani tio , sigue escribiendo posts que ahora que estoy metida en AS3 por tu culpa resultan super interesantes. Eso si. He declarado instancias automaticamente. Para la próxima ya sabré. :)
Acabo de ver tu blog es lo encuentro muy muy util en temas de Flash. Con grandes aportes para los iniciados o no.
Quiero segir tu metodología de este post, pero por ejemplo no se como separar los src de los bin. Me explico mejor, quiero saber como decir a CS4 que me cree los SWF en un determinado punto y no en el mismo sitio que sus correspondientes FLA.
Gracias Antonio.
En cuanto a tu duda, sólo tienes que modificar las opciones de publicación (Ctrl+Shift+F12). Ahí le indicas qué tipo de ficheros exportarás, su nombre y dónde los quieres guardar. Lo ideal es que lo hagas con rutas relativas. Ej: Si tiene un “test.fla” en una carpeta, podrías exportar en “../deploy/test.swf”.
Hola, me encanta el blog y me parecen fantásticas las recomendaciones.
Estoy empezando con AS3 y uff!.. suerte que he hecho un poco de JAVA.
Yo también lo que hago es poner todo lo que va al servidor en internet en una carpeta a la que llamo web.
Entonces ahí dentro meto todos los swf, imágenes, documentos, etc.. ordenados en carpetas.
Todo lo demás .fla, .as, etc lo tengo en la carpeta inmediatamente superior.
Así cuando he de colgar la web en el servidor no tengo que ir mirando… este va.. este no va, este si, este no…
Es algo muy obvio, pero hay quien no lo hace O_o’
Saludos y felicidades!