En este artículo, una reflexión acerca de cómo elegir un framework de PHP a la hora de comenzar un nuevo proyecto.
Este es un viejo artículo que publiqué originalmente en Medium y que rescato porque creo que vale la pena revisar y tener en cuenta algunos aspectos fundamentales.
Si bien me refiero siempre a PHP, muchas de las cuestiones pueden aplicarse a cualquier otra tecnología.
Te dejo ahora con el artículo original.
Contenido
Un error que lamentaré por muchos años
Después de cometer un error que considero grosero y que creo que me acompañará el resto de mis días, medité al respecto y llegué a la conclusión de que lo mejor que podía hacer para redimirme ante mi propia conciencia era analizar el error y no volver a repetirlo nunca más.
El error en sí mismo fue una mala decisión a la hora de elegir el destino de un desarrollo a nivel técnico.
Las opciones eran la de desarrollar en base a un framework genérico o modificar uno que se ajustaba más a las necesidades y que por ende, a priori, estaba mejor preparado.
Claro está que la opción de desarrollar todo desde cero jamás fue tenida en cuenta porque en los días que corren nada se desarrolla desde cero.
A pesar de haber realizado en su momento un análisis que consideré profundo, claramente me equivoqué puesto que a la larga terminó siendo un verdadero dolor de cabeza el desarrollo, despliegue y mantenimiento del sistema.
Analizando el error y descomponiéndolo en partes aparecen una serie de aspectos que deberé tener en cuenta a futuro. Esto aplica a todo sistema pre desarrollado como pueden ser los frameworks MVC, CMSs o cualquier otra solución de código abierto.
Expondré a continuación, los ítems que hay que tener en cuenta a la hora de seleccionar un framework o un sistema de código abierto para desarrollar en PHP y las preguntas más frecuentes que deberíamos hacernos.
¿Quién va a usar el framework?
Antes de meternos con especificaciones técnicas del framework. ¿Quién o quiénes serán los encargados de desarrollar el proyecto sobre este sistema? ¿Seremos nosotros mismos solos, o como parte de un equipo? ¿Será un equipo de desarrollo que lideraremos? ¿Tendremos nosotros la posibilidad de escribir código también?
Si no somos nosotros mismos o si vamos a desarrollar junto con otros no hay que dejar de pensar en la capacidad técnica, la experiencia profesional y la experiencia con la tecnología específica a utilizar de los demás.
No tiene sentido, por ejemplo, que un programador PHP senior tenga que desarrollar un 80% del sistema en Javascript.
Seguramente podrá hacerlo porque tiene suficiente experiencia a lo largo de su carrera, pero sería un desperdicio de recursos.
Por lo tanto, en caso de que no programemos solos, hay que considerar la capacidad, la experiencia y también los gustos o preferencias a nivel técnico del equipo. Después de todo, serán los programadores los que deberán desarrollar el proyecto.
Versión de PHP
¿Para qué versión fue desarrollado este sistema? Si se trata de una versión antigua del lenguaje, claramente es descartable.
Hoy en día descartaría cualquier desarrollo para versiones anteriores a la 7.1. Para poder decidir de esta forma es necesario tener un profundo conocimiento de las distintas versiones del lenguaje. Qué diferencias hay entre cada una, qué se ha agregado y qué se ha quitado, cuáles son los posibles problemas que pueden aparecer.
Versión del proyecto
¿Es un framework muy nuevo? O todo lo contrario ¿Es muy viejo? Cualquiera de las dos puede representar un problema.
Si es muy viejo puede estar desactualizado y si es muy nuevo puede estar lleno de bugs.
No olvidar que lo recomendable es siempre utilizar la versión estable que ofrece el desarrollador de la aplicación.
Actividad del proyecto
En internet está lleno de proyectos de desarrollo, incluyendo plugins o pequeñas librerías que parecen salvarnos la vida. Pero lo cierto es que solo unas pocas se encuentran activas. Esto significa que pueden haber quedado obsoletas.
Para evitar este problema hay que chequear cuándo fue el último commit, cuándo se reportó el último bug y si tuvo alguna respuesta.
Incluso, si es necesario, se puede contactar con el o los desarrolladores a cargo del mantenimiento.
Tan simple como mandar un mail o enviar un mensaje vía Twitter u otra red social.
Dependencias
Como hoy en día nada se desarrolla desde cero, todo proyecto tiene una serie de dependencias con otros paquetes. Hay que revisar esas dependencias y chequear que no sean obsoletas.
Aquí la experiencia es fundamental. El conocimiento de tecnologías que fueron pasando y quedaron en el camino puede marcar la diferencia. Pero la mejor forma de tener este conocimiento es haber tenido contacto con esta tecnología en algún momento.
El sistema de dependencias que usa también puede ser decisivo. Hoy, todo framework decente en PHP debe poder instalarse con Composer. Los tiempos de bajarse el código y descomprimirlo quedaron en el pasado.
Documentación y comunidad
Otro aspecto a tener en cuenta es qué tan documentado está el proyecto. ¿Hay un manual oficial? ¿Una wiki? ¿Un foro? ¿Arroja Google muchos o pocos resultados de búsqueda al investigar la plataforma en cuestión?
Si hay un foro, ¿Cuántos usuarios tiene activos? ¿Cuántos hilos abiertos hay? ¿Cuántos hilos sin respuesta? Muchas veces ocurre que hay solamente dos o tres usuarios respondiendo inquietudes y muchos foros o subforos están completamente muertos.
Lo ideal en este caso es que haya una comunidad activa y que los temas y respuestas estén actualizados al menos en el último mes.
¿Quién mantiene el proyecto?
Y esto quizás no sea muy genérico pero está vinculado particularmente a mi error. El programador que mantenía el proyecto que usé de base era claramente un front-end developer, con lo cual muchas de sus decisiones de arquitectura fueron espantosas, algo que no analicé correctamente al comienzo del proyecto.
A veces creemos que lo que hacen los demás está siempre bien, puesto que mucha gente lo usa o porque la página web es confiable y el logo del proyecto está muy bien hecho.
No, no hay que fiarse por nada de eso. Lo que me lleva a los dos siguientes puntos.
Arquitectura
¿Utiliza este framework algún tipo de arquitectura? ¿Es posible descubrir capas de desarrollo de un vistazo? ¿Hay un modelo, un controlador y una vista? Si no es así, ¿hay algo similar que actúe de forma parecida?
Es importante que en una primera impresión la organización de los directorios y los archivos del proyecto tengan algún tipo de sentido.
Hay que chequear que haya un directorio de acceso público que contenga el Javascript y el CSS, junto con otros recursos. También hay que intentar descifrar dónde se almacenan las reglas de negocio de la aplicación y asegurarse que estén en una única capa.
Mirar el código
Hay que sentarse, tomarse el tiempo necesario y examinar el código. Quizás sea necesario hacer una prueba de concepto.
Allí seguramente saldrán a la luz defectos que no pueden estar presentes hoy en día en un proyecto web profesional: PHP que escribe Javascript o CSS, Javascript obstrusivo que sobrescribe partes de la página luego de que esta carga, etc.
¿El código es estructurado o es orientado a objetos? ¿Está bien indentado?¿Está bien comentado? ¿Es monolítico o modular? ¿Es posible distinguir si el que escribió el código tenía idea de lo que estaba haciendo? ¿Hay código repetido? ¿Es fácilmente extensible o hay que modificar tocando directamente los archivos?
Todas estas son preguntas que tenemos que hacernos para poder llegar a una decisión acertada.
Un punto a tener en cuenta es el del legacy code. Hay que mirar con mucha atención cómo se hacen las cosas. Las funciones que se invocan y las técnicas que se usan.
Hay varios detalles que se pueden revisar. Por ejemplo, si utiliza MySQL, ver con qué API de acceso a base de datos lo hace. También, verificar el uso de funciones deprecadas.
Librerías, plugins y extensiones
Otro de los ítems a considerar es verificar si el framework trae módulos independientes que puedan agregarle nueva funcionalidad. Para cada uno de estos módulos hay que volver a repasar esta misma lista de ítems.
La ausencia de estos módulos implica que agregarle funcionalidad al framework va a requerir más tiempo y dedicación. También indica que la comunidad de desarrolladores que tiene no es tan grande como nos gustaría que fuera.
Footprint
Lo pongo como último ítem porque me parece que aquí ya se entra en decisiones que tienen que ver con los requerimientos.
El footprint o huella es el consumo de recursos por parte del framework por el simple hecho de usarlo. Es decir, un framework con un footprint elevado será más pesado y, por supuesto, más lento.
Como aclaré, esto depende de lo que se necesite desarrollar y hay que tener en cuenta que seguramente la aplicación a desarrollar hará uso de herramientas para mejorar la performance como puede ser OpCache, Memcached, Varnish y muchas otras.
Pero bueno, también hay que tener el footprint en cuenta.
Conclusión
A veces conviene tomar un framework más moderno, activo, con el respaldo de una comunidad que lo mantenga y que se base en estándares y en técnicas de programación modernas.
Seguramente no incorporará por defecto algunas funcionalidades que necesitamos, pero como está bien desarrollado, nos será sencillo extenderlo y agregarle el comportamiento necesario.
También garantizará la integración con herramientas modernas y lo más importante: hará que el proyecto sea ameno de programar, simple para desplegar y fácil a la hora de mantener.
