Cada vez que empiezo un nuevo proyecto siempre está la pregunta: ¿Uso un framework? Y después ¿Cuál?
La realidad, para proyectos cortos, como los que mencioné antes, suelo usar CakePHP, YiiFramework o CodeIgniter.
Pero si estamos hablando de un proyecto, supongamos de una startup, o de mi trabajo, donde sé que voy a tener que mantener ese código durante años, no me parece lo mejor usar un framework, mis motivos:
- Soporte: Nunca vamos a tener la seguridad que el framework siga vivo de aca a 5 años.
- Adaptabilidad: Aprender de un software hecho por otro, siempre es mas dificil a escribir software propio.
- Compatibilidad: En cada nuevo release estamos obligados a actualizar nuestro framework para no estar expuestos a bugs de seguridad, con lo que el roadmap de nuestro equipo de programación lo dicta gente fuera de mi empresa.
- Seguridad: Algo que en teoría es mejor que algo cerrado, se vuelve en contra cuando, demoramos en actualizar (punto anterior), o el proyecto deja de ser sostenido por una comunidad (primer punto), con lo que gran parte de nuestro software es conocido por todos y estamos expuestos a cualquier tipo de ataque si se descubre una vulnerabilidad.
La conclusión a la que llegue en este tiempo, es que es mucho mas confiable depender de librerías y componentes, pero no de todo un framework sobre el que montar nuestra aplicación.
¿Alguien tiene experiencias en usar frameworks en el largo plazo?
No puedo estar más en desacuerdo. Paso a explicar.
1. Soporte: Seguro no se puede estar nunca. Incluso no podes estar seguro que el proyecto para el cual estas eligiendo un framework va a existir de acá a 5 años.
2. Adaptabilidad: Si bien es cierto lo que decís, en el caso que tu equipo se agrande, es mas difícil que los nuevos miembros aprendan tu código que contratar gente que ya tenga experiencia con el framework que elegiste. Y, aunque contrates a alguien sin experiencia previa, con un framework tenes documentación y una comunidad entera que puede ayudar a que la curva de aprendizaje sea mínima.
3. Compatibilidad: El código de un framework lo revisan miles de personas todos los días. Cuantos mas ojos ven el código mas posibilidades de encontrar bugs.
Por el contrario, es mucho mas difícil que vos encuentres bugs en tu propio código.
Me parece que tener a toda una organización/comunidad (aunque sea externa) ayudando a encontrar bugs en el código que vos usas, es algo muy bueno.
4. Seguridad: Esto ya depende de vos. Si usas un framework tenes que mantenerlo actualizado. Pensalo así, es como si en tu propio código encontrás un bug critico de seguridad y no lo arreglas.
Personalmente creo que empezar a construir una aplicación sobre las bases de una estructura hiperprobada no tiene precio. Ademas te quita el overhead de tener que construir y mantener dicha estructura para tu aplicación.
Me parece que el tema no es el tiempo (largo vs. corto plazo) si no, el tamaño. A mayor tamaño mayor necesidad de una buena base.
Gracias por tu comentario, hay cosas que sí comparto totalmente, como la facilidad de agregar gente al proyecto y que, mientras el framework tenga una comunidad, va a ser mas confiable que cualquier cosa propia. Hay otras, que en mi experiencia no funcionan como suponía.
Por ejemplo, un nuevo release del framework deja deprecados métodos que usabas en tu aplicación, y los nuevos no responden igual, esto implica que tengas que corregir y testear gran parte de tu aplicación. No tenes opción de no mantener el framework actualizado, asi que asignas recursos a esto, dejando de lado proyectos que seguramente eran importantes. Con lo que los tiempos de desarrollo de tu empresa, pueden quedar a meced de quienes manejan el framework.
Por eso me parece mas saludable usar librerías, encapsuladas para que las puedas cambiar sin romper tu aplicación. A diferencia de un framework, que una vez elegido, estás casado de por vida.
Estamos de acuerdo que si es un proyecto de mediano a chico no vamos a tener mayores problemas usemos o no un framework, por eso me fui a la variable tiempo.
Cuando el framework hace un nuevo release, eso quiere decir que hay mejoras/arreglos para el core de tu aplicacion. Si hay otros projectos mas importantes que actualizar el core de tu aplicacion, entonces me parece que hay un problema en el management del projecto.
Vos estas asumiendo que si el codigo lo haces vos, no vas a tener bugs o no vas a necesitar mantenimiento. Esto es totalmente errado.
Bugs vas a tener tanto en un framework como en tu propio codigo. La diferencia es que si usas un framework tenes a miles de personas testeando y fixeando el mismo codigo que vos usas como core de tu aplicacion.
Hola, otro más completamente en desacuerdo, las razones están bastante bien explicadas por Federico.
La mayoría de los frameworks serios tienen gran compatibilidad hacia atras, brindan años de soporte, y en cada nueva versión generan documentación para que en pocos minutos puedas estar al tanto de los cambios que tendrías que hacer para mantenerte actualizado (seguramente sean contadas lineas de código), y la mayoría de las veces no vas a tener que cambiar nada.
La única situación en la que vale la pena no trabajar en un proyecto con un framework popular, que tiene una gran comunidad atrás, es que tengas un presupuesto millonario y puedas pagar a los miles de desarrolladores que hoy en día trabajan en cualquier framework.
Solamente hablando de Symfony, Yahoo! respuestas tiene 200 millones de usuarios, es decir que en ese caso particular estamos hablando de 200 millones de testers generando feedback, ¿podes competir con eso en tu propio desarrollo?
Saludos!
Nosotros comenzamos un proyecto con CakePHP 1.2 y cada versión nueva que salió la fuimos actualizando al instante. Hoy el proyecto usa la última versión de Cake (1.3.7 a la fecha) y realmente el paso de una versión a otra nunca significó gran problema. Sólo hubo que hacer pequeños ajustes en el salto de 1.2 a 1.3 y todas las incompatibilidades hacia atrás fueron perfectamente documentadas por el equipo de desarrollo.
Además, nos ayudó mucho tener un alto porcentaje de código cubierto por casos de testing, algo que igualmente se debería hacer siempre y más aún en proyectos a largo plazo, se use framework o no.
Capaz me quedó el mal sabor de boca de haber agarrado el paso de 0.x a 1.0, donde cambió medio framework. Voy a darles una nueva oportunidad.
Yo arranqué con Cake cuando estaba en 1.2 RC1, pero leyendo tickets y blog posts antiguos siempre pensé que no debe haber sido nada fácil desarrollar en versiones anteriores con tanto para corregir y mejorar. Supongo que todo proyecto open source requiere su tiempo de maduración.
Se llama asi por que al empezar a programar queria olvidarme de la parte grafica y concentrarme en la programacion necesitaba un personaje con las animaciones definidas busque en google por game sprites y en los resultados encontre a este personaje con animaciones muy completas lo que fue perfecto para empezar a trabajar..Me parecio inutil programar mi propio framework en mi primer proyecto al comienzo uno quiere ver las cosas funcionando desde las primeras lineas de codigo y si comenzaba programando el framework posiblemente me frustaria y dejaria todo a medias al no ver resultados al corto plazo por eso me decidi a usar en su version 1.0 para este desarrollo.
Yo uso XML para la configuracion de Spring porque me brinda mayor control pero en la version 2.5 ya puedes configurar bastantes mas cosas de Spring sin necesidad de usar XML con anotaciones como Autowired Resource PostConstruct y Required..Sin embargo si no quieres usar Spring puedes usar solamente el IoC de Tapestry puedes leer y . A veces no podemos escoger por esos criterios sino simplemente por el criterio de porque es la politica de esta empresa usar el framework X version Z ….No creo que Tapestry sustituya a Struts o a JSF o ICEFaces porque son demasiado diferentes y migrar de una tecnologia a otra en cualquiera de las dos direcciones es un esfuerzo bastante significativo. Si tienes la oportunidad de hacer un proyecto nuevo y no tienes restricciones de que se tenga que usar tal o cual framework si te dejan decidir el framework por el que te decidas puede ganar popularidad…