El código importa

Tal y como ha explicado Jake en el post anterior, un buen diseño de cualquier aplicación es necesario. Por diseño debe entenderse siempre diseño interno, lo que acaba viendo el usuario puede encargarse, sin menosprecio, a cualquier diseñador gráfico que sepa que es un CSS y que el flash no es esa gran herramienta que para webs maravillosas.

Esta tarea de diseño suele encargarse a grandes Jefes de proyecto, para que luego sus lacayos, llamémosles becarios, lleven a cabo sus más maléficos planes. Sin embargo, esa gran persona encargada de poner los cimientos, de crear una estructura, decidir cómo hacer las cosas, va y coge el Word y te hace 4 cajas. Como maestro del wordart que es, te pinta cuatro cajas representado lo de siempre, lo que todo desarrollador deber saber: Vistas + Dominio + Persistencia + BD.

Mientras tanto, sigue maquinando con el cliente como tiene que ser la aplicación, rellenando miles de papeles, firmando contratos, garantías, actas... "Cualquier cosa que marque una metodología pesada como RUP nos llevará al éxito", deben pensar. Y eso no se puede negar, pero lo habitual es que entre tanto diseño, se olvida la figura del técnico, del ingeniero de software, del picateclas que le sacará las castañas del fuego.

Cuando su diseño llega a las manos de los desarrolladores, normalmente estos cogen las cajas y empiezan a crear monstruos. Y lo más grave de todo, no piensan en quien vendrá después o con quien tienen en su equipo. En quien cogerá semejante trozo-de-mierda para su mantenimiento y acto seguido hará las maletas para irse a la fin del mundo.

Esto es culpa tanto del Jefe de proyecto / diseñador, y el propio programador. Hacer un código elegante implica hacer buen código, código eficiente y efectivo. Todos los frameworks, libros, jefes y demás, se llenan la boca afirmando que su código es reutilizable. Eso no es más que una gran mentira si el código que implementa tu aplicación no se revisa y no se tiene en cuenta.

El código debe ser revisado por otros, pulirse y rehacerse, es decir hacer refactoring. La típica frase de "si funciona no lo toques" no debería ser vuestra pan de cada día. Sin lugar a dudas las metodologías ágiles como eXtreme Programming te llevan a crear una aplicación de calidad en poco tiempo. Te obligan a testear (ave JUnit) cada parte de tu software, reescribir tu código y en definitiva, mejorar tu software.

Los grupos de trabajo jerárquicos con el gran Jefe de proyectos en la cima, con sus expertos haciendo las mil maravillas, deben pasar a la historia. Hay que apostar por grupos colaborativos donde todos dependen de los demás y todos hacen de todo. Hay que dedicar más tiempo al diseño y a una buena implementación. Seguramente al principio se avanzará más lentamente, pero la curva de desarrollo aumentará de tal manera que compensará el esfuerzo inicial. Los que crean que es mejor hacer que simplemente todo funcione de cualquier manera, ya tardan en seguir a nuestro enviado al fin del mundo.

Somos ingenieros

Una de las cosas que más nos motivan en el proyecto de eventuo es el probar y experimentar con nuevas tecnologías, patrones de software, frameworks, etc. Principalmente para hacer las cosas bien e incluso mejorarlas -se está haciendo un gran esfuerzo en este aspecto, para así cumplir una serie de características del la ingeniería del software- o simplemente para innovar -siempre que sea a mejor-.

De hecho, a falta de una remuneración económica -esperemos que no muy lejana-, el aprender nuevas tecnologías supone nuestra mayor motivación y recompensa. Obtenemos así un amplio abanico de conocimientos y habilidades que nos permiten poder enfrentarnos a cualquier desafío, pudiendo casi asegurar que creamos un software de calidad, un software creado por ingenieros.

Y es que la mayor parte de los problemas que aparecen a lo largo de la vida de un sistema software, ya sean simples webs o complejas aplicaciones, vienen dados porque no se consideran obras de ingeniería.

Me explico. Sólo un ingeniero de caminos puede crear la estructura de un puente, porque se supone que sólo él es capaz de tener en cuenta todas las variables necesarias para su construcción. Si otra persona que no fuese ingeniera de caminos diseñase el puente, seguramente no se aguantaría.

Pues ocurre lo mismo con la ingeniería informática. Parece que, sobretodo en las consultorías, el trabajo de un ingeniero informático lo puede realizar cualquiera. Después los proyectos van como van.

Por eso en eventuo dedicamos todo el tiempo necesario a aplicar los conocimientos de la ingeniería informática y sobretodo de la ingeniería del software a hacer las cosas bien. Ahora estamos en la fase de implementación, quedando patente que realizar un buen diseño hace que el desarrollo sea mucho más guiado y sencillo. Y sabemos que los cambios y las revisiones no supondrán problemas.

Entonces, ¿no es mejor dedicar más tiempo a realizar un buen diseño -por alguien que sea ingeniero- para que luego todo sea más sencillo y elegante, en lugar de, realizar un diseño rápido que habrá que ir modificando constantemente teniendo que rehacer código o creando parches?

Adobe Flex y eventuo

Cuando aún no se había empezado en serio con el proyecto de eventuo, se barajaron diferentes tecnologías para la realización de la capa de presentación. Personalmente era partidario de utilizar Adobe Flex, ya que en la empresa donde antes trabajaba -SITEP- se estaba utilizando cada vez en más proyectos. De hecho, mi proyecto de final de carrera lo utilizaba y quedé bastante satisfecho con los resultados.

Mi amigo y partner Giro, realizó prototipos de lo que sería la pagina principal de eventuo con Adobe Illustrator y a partir de las imágenes creadas, se pasaron a código. Giro lo hizo mediante HTML, CSS, JavaScript y JSP, y yo con Flex. Tal vez por mi falta de experiencia el resultado con Flex era bastante distinto al de los prototipos. Además, la interfaz se mostraba inestable colocando de vez en cuando, por ejemplo, elementos donde no tocaba. Finalmente, se optó por las tecnologías que ambos conocíamos , y otras de las que se hablará en futuros post.

A continuación, enumero los elementos que considero positivos y negativos, y que habría que tener en cuenta antes de desarrollar en Flex:

Ventajas

• Al compilar Flex se crea un archivo Flash, pudiendo asegurar que se verá igual en cualquier navegador, sin necesidad de pelearse con los estilos.
• Se crean páginas de manera rápida, sencilla y con un acabado excelente.
• La ayuda y los ejemplos ofrecidos por Adobe son muy buenos.
• El framework es gratuito, antes era de pago.
• Ahora Google puede indexar páginas Flash.
• Facilidad para separar por componentes.
• Se pueden añadir componentes a la web, como gráficas, que dan un aspecto muy conseguido.
  

Desventajas

• A mi modo de ver, orientado a páginas donde el usuario ha de interactuar con una interfaz de aplicación o con fines comerciales como la venta o presentación de productos.
• Para sitios más dinámicos, donde se manejan grandes cantidades de información, no me parece la solución más idónea.
• Con páginas de cierta complejidad se pierde pierde rendimiento y estabilidad.
• Las barras de loading al cargar, sobretodo si estos son largos, hacen que la página se vuelva pesada.
• Nunca será tan rápido como una página de texto plano.
• Dificultad para aplicar patrones software.
• A fecha de hoy, no se puede desarrollar en Linux.

En resumen, Flex es muy bueno para unas cosas, sobretodo cuando se quiere conseguir una estética de aplicación vía web, por ejemplo. Pero no es tan bueno para sitios donde el usuario está de paso y sólo busca información.