Frameworks propios, parte 2
Supongo que debido a la magia de los trackbacks Enrique Place (PHP Senior) se pasó por aquí a comentar mi post sobre su post sobre frameworks propios. Volvemos a estar en desacuerdo :)
No tiene sentido seguir re-inventando la rueda, para aprender ya tienes el propio framework [externo] y los proyectos que puedes construir arriba de ellos, sin tener que seguir lidiando con programación artesanal y errores típicos de la falta de experiencia.
Si quieres aprender, nadie te impide que te hagas un framework, pero si quieres ser profesional y te dedicas a proyectos comerciales concretos, no será muy buena decisión optar por un framework no probado.
De todas los razonamientos que me vienen a la cabeza para rebatir empiezo por el que me parece más contundente:
Dime qué framework usas y dime qué hubiera pasado si su creador hubiera leído tu post y seguido tu consejo a rajatabla.
RoR, Django, Spring, Struts, CakePHP, CodeIgniter… todos esos frameworks no llevan ahí por los siglos de los siglos. En algún momento alguien miró lo que tenía disponible, no encontró lo que buscaba y dió el paso.
En lo que sí estoy de acuerdo es en que los frameworks abiertos son mucho más potentes que los cerrados. Muchos frikis ven más que uno (o dos o los que haya en una empresa).
A título personal te comento, si has tenido que hacer 3 frameworks, es que ninguno han sido lo suficientemente “frameworks” (herramientas genéricas) como para seguir construyendo y mejorando a continuación de cada proyecto.
Voy a comentar aquí mis 3 frameworks no para tirar de currículum sino porque creo que son buenos ejemplos.
** PRISA, año 2004. Para los que no lo sepan, PRISA basa toda su arquitectura PHP en un framework propio basado en PEAR. Como les había dado buen resultado querían algo parecido para hacer aplicaciones Flash. A ello que nos pusimos. Miramos las poquísimas opciones disponibles en aquella época y vimos que no había nada que se adaptara lo suficiente a los requisitos (bastante peculiares, por cierto). Estuvimos 2 semanas haciendo pequeñas pruebas y esquemas sin tirar prácticamente una línea de codigo. Si tuviera que hacerlo hoy le daría una oportunidad a GAIA.
Por desgracia no puedo asegurar que lo sigan utilizando ya que yo me fui a los 6 meses cuando terminé el proyecto.
** CTAD, año 2006. Los requisitos era un framework libre y que fuera compatible con player 6 ya que tenía que funcionar para aplicaciones de escritorio y dispositivos móviles. No había (ni hay) ninguno disponible. A día de hoy hay cerca de 30 aplicaciones utilizándolo. Como digo algunas son aplicaciones de escritorio, otras aplicaciones para móviles, otras sencillas actividades educativas. Todas tiran del mismo framework. A mi me gustaría liberarlo porque creo que vale la pena, otra cosa es lo que piensa mi jefe sobre “que la competencia se aproveche”.
** ZCode, año 2008. Harto de hacer frameworks para los demás, hago el mio y lo libero. Al próximo sitio que vaya ya no empiezo desde 0.
En los 3 casos creo que las decisiones han sido correctas. Hemos mirado lo que había en el mercado y no hemos encontrado nada que se ajustara lo suficiente. Algo que por ejemplo no he hecho con PHP ya que no que tengo el nivel necesario. En PHP uso CodeIgniter.
Así que yo sigo en las mías, hay sitio para los frameworks propios y framework propio no significa “casero” o “poco profesional”. Vamos, ni mucho menos.
Salud!
June 16th, 2008 at 7:40 am
Yo estoy de acuerdo contigo, sobre todo en cuanto miras más allá del ubicuo PHP…
June 24th, 2008 at 6:05 pm
Disculpa la demora en responder ;-)
“Dime qué framework usas y dime qué hubiera pasado si su creador hubiera leído tu post y seguido tu consejo a rajatabla.”
No es justificación pero si excusa para reinventar la rueda. En la mayoría de los casos no estamos ni tú ni yo dentro del grupo de creadores de grandes frameworks que sobrevivan en el mercado y sean usados por una gran masa de usuarios. Por lo pronto debemos desarrollar sistemas, no frameworks, que en sí es una herramienta más, es lo mismo que me dijeras que tal o cual lenguaje no te “quedó cómodo” e implementaste el propio.
Da a lugar para muchas equivocaciones.
Con respecto al otro punto, ahora que comentas los casos concretos, se justifica la creación de 3 frameworks distintos, pensé que seguíamos en el contexto de un mismo tipo de framework sobre PHP.
Pero nuevamente, nuestros clientes piden sistemas, no frameworks (aunque habrán excepciones) y en el 95% de los casos no se justifica hacer “otro”, igual que “otra” distribución de Linux, etc.
Pero sí, respeto todas las posiciones y opiniones, no quiero con esto ser “absolutista” ni tengo la “única verdad”.
December 9th, 2008 at 2:26 pm
[...] Juan (Zárate) en su día sobre los frameworks (¿Ahora picar frameworks propios es malo? y Frameworks propios, parte 2), todo depende de las necesidades del cliente, de tus habilidades, del tiempo de desarrollo, de la [...]