¡Buenas!

Lo sé, ha pasado demasiado tiempo desde que empecé el blog y publico la siguiente entrada. Me resulta muy difícil escribir posts porque me da la sensación de que no voy a escribir nada relevante y para qué me voy a molestar v_v. Pero por fin me he recordado a mi mismo que estoy escribiendo para mi (por eso no hay comentarios) y que qué mas da.

Esto me dijo John Constantine cuando le dije que me daba palo publicar

Así que voy a escribir el primer post técnico del blog. Bueno, medio técnico en realidad. No voy a escribir código, ni técnicas ni nada ininteligible para los no-informáticos. Más bien os vengo a hablar de los diferentes tipos de herramientas para el desarrollo web y los problemas que nos encontramos los desarrolladores cuando tenemos que elegir una.

¡Empezamos!

Diversidad infinita

Hoy en día hacer una aplicación web no es un proceso sencillo, aunque a muchos os lo pueda parecer. Desde la publicación de contenidos a la identificación de usuarios, seguridad en las comunicaciones, sistemas de comentarios, formularios, darle un aspecto moderno y dinámico a la web, etc. La cosa más tonta que te puedas imaginar podría potencialmente llevar un día entero o incluso más días de trabajo.

Sin embargo, vivimos en un mundo impaciente donde necesitamos tener hecho todo lo antes posible porque el tiempo es dinero y el dinero se acaba. Por eso los desarrolladores hemos ido creando diferentes herramientas que nos intentan facilitar la vida: Lenguajes de programación, frameworks de desarrollo, sistemas especializados, etc. Y los tenemos a miles.

En lenguajes de programación encontramos por ejemplo: PHP, Java, Javascript (con diversas variantes), Python, Ruby, Go, Kotlin, C++, C# y muchos, muchísimos otros que probablemente me estoy dejando y que incluso no conozco. Algunos están más enfocados al desarrollo web y otros no, pero se pueden usar igualmente invirtiendo algo más de esfuerzo.

Luego tenemos los diferentes frameworks de programación. Los frameworks son un conjunto de herramientas hechas en un lenguaje de programación enfocadas a hacer un tipo de desarrollo. Por ejemplo, para PHP tenemos varios frameworks de programación web como Symfony, Cake PHP, Laravel, Zend, FuelPHP, etc... Cada lenguaje probablemente tenga al menos un framework y la mayoría van a tener varios.

Y si nos ponemos en plataformas especializadas nos encontramos con cosas CMS (Content Management Systems), ERPs, CRMs, etc. Aquí encontramos cosas como Drupal, Wordpress, Magento, Salesforce, Invoiceninja... si las dos listas anteriores eran largas como un día sin pan, esta es directamente infinita. Cada día se crean nuevos sistemas especializados y los existentes evolucionan para intentar cubrir nuevos requisitos que aparecen.

La problemática

La problemática es bastante evidente de entrada. Si quiero hacer una aplicación web, ¿qué utilizo? ¿Cual es la mejor herramienta? Y la respuesta depende de muchos factores:

  • ¿Con qué herramientas has trabajado más y por lo tanto dominas mejor?
  • ¿De cuánto tiempo dispones para desarrollar la aplicación?
  • ¿Tienes tiempo y energías para aprender algo nuevo que no conozcas?
El drama

La verdad es que no suele haber nunca una única respuesta correcta. Casi todo se puede hacer con cualquier lenguaje o framework de programación y algunas plataformas como Drupal o Wordpress son suficientemente generales como para poder hacer casi cualquier cosa, con mayor o menor dolor.

Si no tienes tiempo o ganas de aprender y el deadline de entrega está muy cerca, simplemente usa lo que conozcas y tira millas, ya que no te queda más remedio. Posiblemente no sea la mejor herramienta para lo que necesitas, pero podrás cubrir las carencias con suficiente agilidad como para que no se note demasiado.

Pero ten en cuenta que el resultado no será perfecto y probablemente se deberá ir parcheando de vez en cuando y que el mantenimiento puede llegar a ser un infierno a la larga. Para estos casos recomiendo desarrollar el proyecto teniendo en mente una posible migración a otro sistema más apropiado en un futuro.

Si tienes algo más de tiempo para al menos valorar diversas herramientas y tienes una decente capacidad de aprendizaje, mi recomendación es que hagas un poco de investigación de las distintas herramientas e incluso unas pocas pruebas de concepto. Busca herramientas que estén enfocadas al tipo de aplicación que quieres hacer y elige aquella que te haya resultado más cómoda.

También puedes buscar opiniones sobre el tipo de aplicación que quieres hacer y la herramienta que quieres elegir. Pero mucho cuidado con esto: Hay gente que puede ser muy negativa con una herramienta porque han tenido una mala experiencia con ella, pero que no es culpa de la herramienta sino de su propia inexperiencia y falta de tiempo para aprenderla correctamente. Como todo lo que leas en Internet, coge las opiniones con pinzas.

Ten en cuenta que si eliges una tecnología que no pilotas, durante el desarrollo vas a encontrarte con algunos problemas:

  • La documentación de la tecnología puede ser inexistente.
  • Puede dar por supuesto que tienes ciertos conocimientos (por ejemplo de orientación a objetos o de programación funcional) que en realidad no posees.
  • Puede requerir o depender de otras tecnologías o lenguajes de programación que tampoco conoces y que también tendrás que aprender.

En general eso no es malo, ya que vas a aprender un montón de habilidades nuevas que no tenías antes y vas a evolucionar como desarrollador. Simplemente asume que es probable que tardes un poco más de lo que pensabas en desarrollar la aplicación.

Otra cosa que debes saber es que tarde o temprano vas a necesitar bucear en el código de la herramienta que utilices. No importa la herramienta que sea, muy rara vez la documentación cubre todos los casos y posibilidades de la misma. La única manera de saber si puedes hacer lo que quieres hacer es mirar si el código te lo permite. Saber leer código ajeno es una de las habilidades más útiles que puedes adquirir como desarrollador.

Errores típicos

Dicho todo esto, voy a comentar los errores más típicos y las cosas más surrealistas que he visto a lo largo de mi (corta) carrera a la hora de elegir una tecnología para un proyecto de web:

Voy a necesitar un trago después de esto...

Los CMS genéricos sirven para todos los tipos de proyectos.

Este es un clásico para mi, que he trabajado con Drupal durante mucho tiempo (más de diez años). Básicamente herramientas como Drupal, Joomla o Wordpress te traen implementadas de base muchas herramientas importantes: Gestión de usuarios y permisos, gestión de contenidos, categorización...

Instalas el sistema en cinco minutos y, voilá, ya puedes crear usuarios, contenidos y categorizarlo todo. Eso hace que muchos piensen "pues si esto ya lo tengo, solo tengo que desarrollar lo demás encima de esto y me estoy ahorrando mogollón de coste de desarrollo. ¡Para qué reinventar la rueda!".

Hay que reconocer que el argumento tiene mucha lógica. Al fin y al cabo es estúpido rehacer la misma cosa una y otra vez cuando lo puedes tener ya de base y no picar una línea de código. En lugar de eso, instalas el CMS y luego ya programas el resto de funcionalidades que no tienen que ver con el CMS.

Pero esto acaba presentando rápidamente varios problemas. Por ejemplo

  • Si el cliente necesita que el sistema de usuarios se comporte de forma distinta a lo que viene instalado, en algunos casos cambiarlo tiene un coste igual que implementarlo de cero y en otros directamente mayor.
  • El resto de partes de la aplicación pueden tener un coste mayor de desarrollo en el CMS de lo que lo tendrían porque hay que cambiar partes del funcionamiento del mismo para que se adapten a lo que se quiere implementar.

Ejemplo 1: En Drupal los permisos sobre un contenido se controlan por rol y solo para crear, editar y borrar un contenido. Si quieres controlar los permisos de un dato concreto de un contenido (por ejemplo, solo quiero que el usuario de tipo editor cambie el campo de texto de una noticia, pero no la fecha de publicación), necesito un módulo extra, pero si además necesito que un usuario solo acceda a los contenidos de una determinada categoría, la implementación requiere varios módulos trabajando entre ellos y probablemente la inclusión de código extra para cubrir todos los posibles casos. Ya has trabajado lo mismo o más que haciéndolo desde cero.

Las herramientas especializadas sirven para cualquier cliente

Si vuestro cliente quiere un e-commerce, Magento funciona de una forma, Prestashop de otra y WooCommerce de otra. Casi todas permiten un cierto grado de personalización, pero no son la panacea. Cada uno organiza la información como le parece y aquí solo hay dos opciones:

  1. Que vuestro cliente adapte sus procesos a la herramienta.
  2. Que invirtáis posiblemente mucho tiempo en cambiar la herramienta para que se adapte al cliente. En algunos casos es factible, en otros puede ser un infierno.

El primer punto es muy válido si vuestro clientes es pequeño y no dispone de mucho presupuesto. Además puede ser buena idea porque muchas de estas herramientas llevan años desarrollándose y son muy a prueba de balas. Vuestro cliente podría beneficiarse de cambiar su forma de trabajar a una más eficiente.

Lo mejor es conocer vuestras herramientas lo mejor posible y tener claro qué puede y qué no puede hacerse antes de venderlo a cliente.

Hacer tu propio producto. Con casinos. Y biryani de pollo.

Es más, paso de la plataforma. Y de los casinos.

Este plato indio es glorioso.

Este es otro clásico. Tu jefe se acerca y te dice "Oye, y si en lugar de usar siempre X desde cero, hacemos un producto propio? Le ponemos Y y Z módulos, para que tenga eso de base y lo vendemos como churros".

A eso solo se puede responder: Eso ya existe. Se llama Drupal. O Wordpress. O Magento. O cualquiera de las herramientas especializadas. O incluso los frameworks, aunque tengas que configurar cosas. Lo único que estás haciendo es añadirle features, pero en esencia es lo mismo y tiene los mismos problemas antes mencionados. Estás especializando una herramienta que probablemente ya esté bastante especializada y por lo tanto te estás poniendo más trabas desde el punto de vista de desarrollo.

Un framework no, que hay que picar código

"¿De verdad quieres hacer esto usando [Inserte su framework aquí]? Hay que picar código y eso acaba dando problemas y errores."

Os juro que esto me ha pasado. Y no es tan raro, cuando trabajas con Drupal o un CMS similar. Muchas veces no tienes que picar código porque para la funcionalidad X instalas un módulo o un plugin y lo puedes configurar todo por interfaz web. Es la gracia de este tipo de sistemas realmente porque ponen al alcance de las personas no técnicas una serie de herramientas para poder tener un blog o un publicador de noticias.

Pero nosotros no somos usuarios no técnicos. Somos desarrolladores de software. Hacemos aplicaciones adaptadas a las necesidades del usuario. Y picamos código. Sí, el código falla. Por eso testear el código siempre es importante. Otro día hablaré sobre el testing.

Pero donde este argumento me parece más absurdo es en el hecho de que con esta forma de pensamiento el problema es (potencialmente) mucho mayor. Tu no estás picando código, pero al añadir módulos, estás añadiendo código que no controlas y que también puede petar. Es decir, lo único que te estás ahorrando es no tener que pensar tú en tu código. Nada más.

En resumen

No existe una única herramienta correcta para hacer un trabajo. Busca, experimenta y aprende. Elige una que te parezca lo suficientemente buena y tira millas con ella. No tengas miedo de aprender, no te asustes de la complejidad. Con el tiempo ganarás experiencia y sabrás elegir mejor y desarrollar más rápido.

Y sobretodo no cometas el error de pensar que una sola herramientas sirve para todo. Si eso fuera así, no tendríamos la diversidad que hay hoy en día.