Algunos detalles técnicos sobre el front-end de FaasT

miércoles, 14 de mayo de 2014

FaasT se ha convertido en un proyecto de gran magnitud, tanto en su back-end (bases de datos, servidores, procesos, informes, consumidores, hilos...) como en su interfaz web. Hablaremos de qué herramientas y librerías se están utilizando para implementarla y, además, un esbozo de cómo se está organizando el código.

Existen muchas guías de buenas prácticas y diferentes formas de organizar código, todas válidas y aceptadas. Para FaasT se ha utilizado una de ellas, que se ha considerado adecuada. No tiene por qué ser la mejor para todos los proyectos, pero sí que la estrategia adoptada está mostrándose útil en un entorno de un trabajo de gran magnitud donde colaboran diferentes programadores con perfiles dispares.

Reglas importantes

Un proyecto de front-end como FaasT no lo crea una sola persona. Es necesario pensar como equipo desde un primer momento y eso conlleva respetar algunas normas. Por ejemplo:

  • Código modular: Algo que aplica a cualquier proyecto de programación es que en la medida de lo posible hay que hacer el código tan modular como se pueda, para que a la hora de tener que hacer un cambio, se agilice la búsqueda de la zona afectada. Otra ventaja es que si se quiere añadir nueva funcionalidad siempre es más sencillo si todo está separado en bloques con funcionalidad específica.
  • Comentarios: En cualquier código con lógica debe haber comentarios explicando funciones o métodos que no sean muy obvios, tanto pensando en otras personas que puedan leer el código, como para el propio autor que no debe confiar en exceso en su propia memoria. Los comentarios en HTML son tan útiles como los de código "tradicional", sobre todo porque obliga al grupo de trabajo a mantener una estructura dentro de un archivo. No es necesario insertar comentarios de HTML con <!—Mi comentario -->... muchos back-end permiten guardar comentarios con etiquetas suyas, que luego no se muestran al cliente ni en el código fuente que se envía. Así, se mantienen los comentarios como algo interno para desarrollo.
  • Principio KISS: Un principio creado en la marina americana hace 50 años que significa: “Keep It Simple, Stupid”. El proyecto es muy grande. Tal vez, que una persona invierta tiempo en conseguir un trozo de código más simple, puede significar que otras personas del equipo luego puedan continuar el hilo sin perder mucho más tiempo en documentación. 
Las tres reglas tienen un obvio factor en común: si se es parte de un equipo, se ha de trabajar en equipo.  

Front-end

FaasT depende de muchas librerías, plugins de JavaScript, reglas de CSS, etc. Organizar todos estos archivos que componen la interfaz web en carpetas puede resultar complicado. Para solucionarlo, se ha usado HTML5 Boilerplate.

Se trata de una plantilla de front-end para hacer páginas web siguiendo los estándares de HTML5 y con una serie de plugins y archivos por defecto que, aunque obviamente pueden ser modificados, proporcionan una muy buena base para empezar el front-end de cualquier proyecto web.

Directorios

Cómo se estructuran los directorios es algo que no solo ayuda a llevar una buena organización del código que nos pueda ser útil, sino que también facilita la vida al resto de programadores. La estructura usada en FaasT está basada en la que ofrece HTML5 Boilerplate con unas pequeñas modificaciones (como la carpeta de archivos less).

Estructura de directorios en FaasT
Esta jerarquía de documentos es muy sencilla de entender a simple vista y salvo el cambio de directorio que almacena archivos .less que se explicará brevemente, el resto está todo en la documentación de HTML5 Boilerplate.

CSS y LESS

Los archivos CSS de un proyecto web no reciben quizás la misma atención que por ejemplo los archivos JavaScript. Sin embargo, no por ello se deben dejar de seguir algunas buenas prácticas:
  • Todas las reglas CSS deben encontrarse en archivos específicos. No es buena idea tener reglas CSS dentro de etiquetas en el propio HTML, o como reglas dentro del elemento al que se le aplica el estilo.
  • !important no se debe usar más que en caso de emergencia. Si se debe forzar una regla CSS, es que algo se está haciendo mal. 

JavaScript

Igual que con las reglas de CSS, la lógica que se le ponga al front-end no debe encontrarse ni en etiquetas de [script] ni como parte del elemento al que se refiere. Deben encontrarse en un archivo .js aparte. No respetar esta regla puede suponer un gran problema para depurar código JavaScript (cosa ya relativamente complicada de por sí). En FaasT, como en tantos otros proyectos, usamos librerías externas que se referencian vía CDN pero de las que también disponemos de un fallback local en caso de caída del CDN. Estas librerías están todas almacenadas separadas del resto de archivos .js en la carpeta "vendor", así no se mezclan archivos nuestros con librerías. Por ejemplo:


Usabilidad y diseño

Dicho lo anterior, en el proyecto se han elegido las siguientes librerías:

Para Javascript:
  • Jquery: fácil, versátil y con muchos plugins que se usan constantemente. 
  • Jquery UI, perfecto para extender la funcionalidad base y adaptarla a nuestras necesidades, para accordions, sliders y otros usos.
  • Normalize.js: para resetear CSS
  • Modernizr.js: para que navegadores antiguos puedan usar elementos de HTML5 y CSS3.
Para CSS:
  • Twitter Bootstrap: sobre todo por la comodidad de organizar los tamaños de los divs, también tiene un montón de elementos útiles como botones o glyphicons.
  • Para la gestión de nuestros propios CSS hemos usado LESS, un lenguaje de hoja de estilos dinámico que permite el uso de variables para usar en colores, por ejemplo, acelerando y simplificando el posible cambio de estilos. Así no hace falta escribir un color cientos de veces como #F5F5F5, sino que cambiando la variable podemos modificar las cientos de veces que se llama a ese color. También proporciona otras pequeñas ventajas como reglas anidadas o extender clases.
Todo esto luego se compila en archivos .less en .css que es lo que se le presenta al cliente.

Juan Luis Sanz
juanluis.sanz@11paths.com

No hay comentarios:

Publicar un comentario