Los frameworks de desarrollo y la Thermomix

Frameworks de desarrollo

Iba a escribir un artículo sobre las razones que hacen de Silex mi framework de desarrollo PHP favorito, y después de un buen rato escribiendo me he dado cuenta de que mi post se había convertido en una crítica sobre los frameworks de desarrollo, o mejor dicho, la mala elección que se hace de ellos. Prometo que retomaré en unos días el artículo original, pero en este voy a centrarme en la relación que para mí existe entre dos cosas tan distintas como una Thermomix y un framework de desarrollo.

Por contextualizar, tengo que decir que a pesar de tener 26 años, llevo ya más de 9 años programando en serio proyectos web en PHP. Durante la mayor parte de este tiempo he estado buscando un framework (antes si quiera de saber que eso que yo buscaba se llamaba framework) que me proporcionara el esqueleto básico a partir del cual empezar a construir mis proyectos web. Es más, encontrar respuestas a esta cuestión fue una de las razones principales que me llevaron a cursar un Máster en Ingeniería del Software para la Web (que para ser justos, he de decir que no me aportó mucho). Tras probar durante estos años distintas opciones, hace unos meses empecé a trabajar con Silex y, por fin, he encontrado lo que buscaba. Pero, como decía en el inicio de este post, eso es otra historia que retomaré en unos días.

Empecé, como casi todos, por utilizar PHP a pelo, a la vez que maquetaba horribles páginas webs con tablas. Fui aprendiendo y mejorando, y con el paso del tiempo probé varios de los frameworks que por aquella época estaban de moda, sin que ninguno de ellos llegara a convencerme ni resultarme suficientemente ágil. Hasta que un día me decidí a crear mi propio framework. Un framework que nunca publiqué, pero al que dediqué cientos de horas de mi trabajo para construir algo que hiciera mi día a día más sencillo y, sobre todo, me permitiera construir proyectos de una forma ágil pero a la vez robusta y escalable.

Tras muchas iteraciones, con innumerables cambios y alguna que otra reescritura completa, llegué a tener un framework del que sentirme orgulloso. Seguramente la mayoría de los desarrolladores pensarían que no mereció la pena el tiempo que le dediqué, habiendo tantos frameworks públicos estables con una gran comunidad por detrás. Sin embargo, diré que la experiencia y el aprendizaje que me ha aportado tiene para mí un valor incalculable. No solo no me equivoqué, si no que recomiendo a todo aquel que quiera llevar a otro nivel su visión de la ingeniería del software para la web y el desarrollo de proyectos, que intente desarrollar su propio framework.

Entre otras cosas, me ha aportado una visión crítica sobre los frameworks comerciales, ya que al haber construido uno propio entiendo mucho mejor qué es lo que necesito y, sobre todo, qué no necesito. Porque para mí, el quid de la cuestión está precisamente en todas las funcionalidades que nos aportan los frameworks y realmente no necesitamos para nada en nuestros proyectos.

Matar moscas a cañonazos

Eso, precisamente, es lo que creo que ocurre con la mayoría de frameworks en la mayoría de proyectos: que matamos moscas a cañonazos. En otras palabras, sobrecargamos nuestros proyectos con funcionalidades que alguien dice que molan mucho, pero a la hora de la verdad no se ajustan completamente a las necesidades de nuestro proyecto y/o, en muchas ocasiones, penalizan notablemente el rendimiento. Y el caso más evidente son los ORM, como Doctrine en el caso de Symfony. Creo que todos los beneficios que, supuestamente, tienen, no compensan las problemas de rendimiento que vamos a encontrar en cualquier proyecto medio serio a largo plazo. Por lo tanto, la cuestión no es si utilizar o no un framework, si no utilizar el que más se ajuste a nuestras necesidades.

En mamicenter utilizamos Symfony, seguramente a día de hoy el framework PHP más popular, y para el que siempre había querido tener una excusa para empezar a trabajar con él. Tanto Mario como yo éramos novatos, sin embargo le sacamos mucho jugo en poco tiempo. No descubriré la rueda si digo que es un framework muy potente, con una gran comunidad de usuarios por detrás y con una documentación excelente. No creo que haya ningún tipo de proyecto web que a día de hoy no se pueda hacer partiendo de Symfony. Y precisamente, ese es para mí su mayor problema. Cuando algo sirve como solución para prácticamente todo, es porque aporta muchas más cosas de las necesarias para la mayoría de usuarios.

La Thermomix

Por buscar un ejemplo más gráfico, Symfony (y cualquiera de los grandes frameworks) es como la Thermomix. Con ella puedes cocinar prácticamente lo que quieras, es el sueño de cualquier ‘cocinillas’. Te lees los manuales y te das cuenta de lo bien que suenan todas las cosas que puedes hacer, y empiezas a pensar en qué momento vas a hacer cada una de ellas.

Luego lo que pasa es que si lo piensas friamente, realmente solo necesitas freir un huevo, hacer unas lentejas y cocer pasta. ¿No es mejor para eso utilizar una olla y una sartén? No solo no ahorrarás dinero (tiempo de formación y desarrollo), sino que cocinarás (trabajarás) de manera más eficiente.

Los frameworks no son malos

Y con esto, una vez más, no quiero decir que los frameworks sean malos, nada más lejos de la realidad. Los frameworks son soluciones muy potentes y simplifican la vida de cualquier equipo de desarrollo, permitiendo además tener un marco de trabajo común que permita (idealmente) incorporar y sustituir desarrolladores sin que tengan que pasar semanas aprendiendo y asimilando cómo está desarrollado el proyecto.

Por lo tanto, antes de decidir si para tu proyecto o el proyecto de la empresa para la que estás trabajando vas a utilizar Symfony, Laravel o cualquier otro de los frameworks ‘molones’ de los que todo el mundo habla maravillas (o incluso antes de sentarte a desarrollar desde cero uno nuevo), siéntate y piensa qué es lo que de verdad necesitas. Y sobre todo estudia bien qué es lo que no necesitas, porque es todo ese sobrante lo que a largo plazo puede convertirse en un lastre y pisotear la agilidad en el proceso de desarrollo.

Silex es un gran ejemplo. Un microframework PHP, basado en Symfony, pero mucho más ligero y fácil de aprender, que no me cabe duda de que es una mejor opción para muchos de los proyectos construidos con Symfony. Pero claro, no mola tanto. En unos días como ya comentaba al principio del post, explicaré por qué me gusta tanto.

Moraleja

Las horas o días que dediques a analizar todas las alternativas posibles a la hora de elegir (o desarrollar desde cero) un framework, estarán más que bien invertidas. Y si una vez empezado, ves que no cumple al 100% tus necesidades y crees que te has equivocado en la elección, empieza de nuevo con otra alternativa mejor, antes de que sea demasiado tarde. Tu “yo” futuro te lo agradecerá, te lo aseguro.

Uso de cookies

Este sitio web, como todos, utiliza cookies. Si continúas navegando por la web estás dando tu consentimiento para la aceptación de la política de cookies de este sitio web. ACEPTAR

Aviso de cookies