¿Cómo ser un buen Site Builder de Drupal? Paso a paso III
Muy buenas a todos, seguimos con esta tercera parte de ¿Cómo ser un buen Site Builder de Drupal? Paso a paso, en esta ocasión hablaremos del Harcoding, comencemos:
 
 
4. Evite el Hardcoding
 
 
La tentación de hardcode le pasa al mejor de nosotros - es por eso que incluso el mejor de nosotros está en riesgo de ser quemado por ella.
 
 
Definición del hardcoding
 
 
Hardcoding es la práctica de hacer código adaptado para manejar casos o funcionalidades muy específicas.
 
 
Estos son algunos ejemplos de Hardcoding con Drupal:
 
  • Insertar una consulta SQL en un archivo .tpl
  • Escribir un script con consulta a la BD para hacer cambios en nodos.
  • Usar una expresión regular como salida de una función del tema para cambiar una clase de html por otra.
 
Estos ejemplos se pueden dar en casos concretos o durante todo tu proyecto, y son una puerta abierta de acceso para los piratas del núcleo, además de causar otros efectos no deseados en tu instalación.
 
 
Vale, pero ¿por qué debo evitar el hardcoding?
 
 
A menudo es muy atractivo para los programadores hardcodear porque tenemos prisas en entregar una determinada funcionalidad y no tenemos tiempo para desarrollar un módulo o porque sencillamente estamos aprendiendo y no tenemos los conocimientos suficientes aún para lograr dicho caso. 
 
 
El problema intrínseco que incluye estas decisiones es que a priori parece una manera de ahorrar muchísimo tiempo, a corto plazo, y es verdad.
 
 
El problema es que hay costos ocultos al hardcodear que suelen suponer un coste mayor de tiempo y recurso a medio - largo plazo.
 
 
Comentarios como "don't put code into the theming layer" (no pongas código en la capa de presentación) o "use the hook system" (usa el sistema de hook) son muy comunes y presentan advertencias preceptivas contra el hardcoding.
 
 
Aun así, suele ser bastante complicado que los nuevos “Drupaleros” puedan encontrar información sobre porque el Hardcoding es una mala idea.
 
Es por esto que a continuación se presentan problemas concretos sobre decisiones Hardcoding que pueden causar problemas en el futuro:
 
Si estás desarrollando una plantilla o tema
Imagina que añades una consulta SQL personalizada para recuperar y mostrar el número de usuarios que tienes en tu web. Ahora quieres desplegar esta plantilla en otra instalación. ¿Qué pasaría si la estructura de tablas cambia en otra instalación? Pues que tu consulta sería inútil, por lo que no es muy aconsejable hacer esto.
 
Diseñas una función personalizada para para recuperar y mostrar información sobre los usuarios de tu sitio
Esto acaba abusando intensamente del procesador de tu máquina y al no haber tenido en cuenta la posibilidad de cacheos de resultado podría provocar la ralentización de tu web.
 
Necesitas cambiar los banners que se muestran en tu sitio
Imaginate que el código de elegir un banner al azar se ha colocado en archivo page.tpl de sitio. Esto quiere decir que no se mostrarán estos hasta que no se haya renderizado esta función, pero ¿y si necesitas modificar antes el HTML?
 
 
Tienes cinco variante de plantillas de tu sitio
Cada una tiene una consulta personalizada, si ahora tuvieras que cambiarla, tendrías que acceder a cada una de estas seis plantillas y cambiarlas manualmente, ¡uy que digo seis, si son cinco! ya pero también la tienes que modificar en la versión móvil ¿no? Esto seguro que no se nos olvida ¿verdad?
 
Otra persona comienza a trabajar con tu código
 
Traducción literal de la comunidad:
Si estás hardcodeando una solución, ¿tienes idea de lo que está pasando, incluso si tienes mucha experiencia en Drupal? Recuerda que si este proyecto es diferente a tu blog personal, alguien más puede involucrarse con el proyecto. Incluso si es sólo tu blog, ¿cómo puedes saber cuánto vas a recordar de tu código dentro de un año?
 
Aportación propia:
Llegado a este punto, me gustaría hacerte referencia a algo escuchado en la Drupal Camp de 2015 de Jerez de la Frontera de parte de Marcos Cano (https://vimeo.c...) “Imaginemos por un instante que el desarrollador que va a recoger tu proyecto es un psicopata asesino que además sabe donde vives…” Se trata de una metafora exagerada de la realidad pero creo que nos hace llegar el mensaje.
 
 
Recuerde que el principal motivo por el que evitar el hardcoding es para anticipar errores. Por cada página cargada de tu sitio el servidor ejecuta cientos de funciones y es por eso que se recomienda las personalizaciones en Drupal mediante el uso de los Hook existenes (o ganchos) contemplados en el flujo normal de la aplicación.
 
Quizás sea el momento de plantearte si entendemos a fondo todas las formas en las que estas funciones interactúan. Si no es así, quizás debiéramos ponernos al día con ello u operar fuera del Framework de Drupal.
 
Desde Drupaleros.es recomendamos que ante cualquier duda o problema durante el desarrollo de tu sitio, primero busques en la documentación oficial del CMS -> Documentation Drupal.org
 
Excepciones
 
A pesar de todo lo anterior, el hardcoding es algo totalmente diferente de la piratería núcleo de un sentido crucial: hay muchos usos legítimos para ello y la mayoría de los desarrolladores de Drupal tendrán que hacerlo de vez en cuando. 
 
En ocasiones, sabes que solo vas a necesitar algunas veces determinadas funciones (e.j. un tema para halloween que solo lo modificas una vez al año). En estos casos es más operativo dejar documentada la función y recordar donde estaba dicha documentación. 
 
Si vas a codificar, tenga cuidado, y recuerda siempre pedir consejo si no estas seguro sobre si se debe o no hacer. Es más, ten mucho más cuidado cuando estás seguro, porque suele ser muchísimo más peligroso.
 
 
Esperamos que os sea de ayuda.
Atentamente y con cariño, Drupaleros Team
Total de votos: 143

Entradas relacionadas

Comentarios (0)

Deja un comentario