php - semanas - ¿Por qué necesito usar un marco popular?
menu de la dieta de las tres semanas (18)
¿Puedes resolver los problemas que tienes con tu código de forma más rápida y confiable que los marcos públicos?
Si es así, entonces sigue usando el tuyo.
Si no, entonces encuentre el marco que hace un mejor trabajo y ejecute con él para ese proyecto.
Todo se reduce a qué base de código hace el trabajo mejor (por el valor de mejor dado por el cliente;))
He sido desarrollador de PHP por muchos años, con muchas herramientas en mi haber; herramientas que yo mismo he desarrollado, o soluciones de uso libre en las que he aprendido a confiar.
Miré en CodeIgniter recientemente, y descubrí que tienen muchas clases y rutinas de ayuda para ayudar con el desarrollo, pero no vi nada en los ejemplos que no pude hacer tan fácilmente con mis propias herramientas. Cosas simples como abstracciones de bases de datos, ayudantes de correo electrónico, etc. Había un código interesante relacionado con las rutas: asignación de URL a los controladores correctos; pero incluso eso no es particularmente difícil de codificar si alguna vez ha escrito una aplicación web de estilo MVC con URL bonitas.
Incluso después de revisar algunos de los otros marcos populares, todavía no veo nada que ahorre mucho tiempo. Incluso al mirar los foros, veo personas que luchan por obtener las herramientas para trabajar para ellos. Entiendo cómo serían más útiles para los desarrolladores junior, ya que las habilidades de diseño del sistema completo toman un tiempo para comprender y apreciar completamente.
Sin embargo, a menudo me dicen que debería usar un marco estándar para producir mis soluciones, pero aún no estoy convencido. ¿Cuál es el beneficio real para alguien como yo? ¿Acabo de ser elitista, o es esta una opinión común?
Editar: Mirando algunas de las respuestas aquí, ¿debería considerar empaquetar mi conjunto de herramientas como su propio marco, escribir documentación y publicar tutoriales? Si tengo dudas sobre cómo abordar los marcos de otros, ¿abrirlos y tener más en cuenta me ayudaría a mejorar mis habilidades / herramientas?
Aquí hay muchos comentarios sobre las ventajas de usar un marco, y ciertamente creo que en muchos casos son perfectamente correctos.
SIN EMBARGO
Todos los marcos vienen con la desventaja de que tienen un dominio de problemas que se pueden adaptar a ellos. Si su problema está dentro del alcance del dominio, entonces usar un marco no es un problema, y la mayoría de las veces es evidente si su problema está fuera del dominio, por lo que no lo piensa. Los problemas surgen cuando intentas forzar un problema en un marco que simplemente no encaja o tiene alguna característica inusual no estándar, en cuyo caso completas el 90% del código muy rápido y luego pasas todo el tiempo que tienes guardado averiguar cómo doblar o extender el marco para que pueda cumplir algún requisito oscuro. Debido a que en este caso su solución / extensión debe conectarse al marco, a menudo puede ser más difícil codificar que si lo hiciera de manera independiente.
En circunstancias equivocadas, esto puede ser realmente desastroso. Por ejemplo, si un cliente solicita un proyecto que usted cree que encajará en una solución de marco y cotiza en consecuencia, luego de completar el 90% usted encuentra el gotcha, entonces puede estar realmente en el arroyo, especialmente si es una característica que el cliente es insistente (y siempre lo es). Estos problemas tienden a surgir porque no siempre es evidente a partir de la palabra donde podrían estar las trampas, particularmente si estás usando un marco con el que estás menos familiarizado (y tienes que hacerlo de vez en cuando).
Este es realmente el mismo problema que surge al implementar cualquier software de terceros en un proyecto. Yo por experiencia no tengo reparos en usar marcos o similares, pero dada la elección, siempre elegiré el envoltorio más liviano y delgado que pueda encontrar y que haga lo que necesito. De esa manera, obtengo las ventajas, sabiendo que si surgen problemas (y generalmente es menos probable que los apliquen con un envoltorio más delicado), entonces es más fácil descubrir cómo solucionarlos que aprender una extensa base de código hasta el punto. donde puedo modificarlo de forma segura.
Aquí hay otra razón para no crear su propio marco. Ley de Linus : "con suficientes ojos, todos los errores son superficiales". En otras palabras, cuantas más personas usen un marco dado, más sólido y libre de errores será.
¿Has visto cuántos frameworks web hay para Java? En el pasado, estaba de moda que cualquier desarrollador / arquitecto medio decente escribiera su propio marco web personalizado. Y al final del día, el 95% de ellos parecía una implementación personalizada de Struts (el framework web Java más popular en ese momento). Así que básicamente crearon un clon de Struts que era: 1) propietario; y 2) no tan bien documentado y probado.
Seamos realistas: escribir nuestro propio marco de trabajo para el cliente es divertido, pero ¿qué pasará después? Se convierte en una carga de mantenimiento mantener el marco usted mismo (o el alma pobre que lo reemplaza). Y mantener el software es mucho, mucho más costoso, especialmente cuando se trata de marcos personalizados. ¿La empresa está en el negocio para resolver problemas de dominio o en el negocio de mantener los marcos?
Olvidé quién lo dijo, pero una vez escuché una gran cita: "La primera regla para crear tu propio marco es: no". Alguien más probablemente haya realizado el esfuerzo de hacerlo y probablemente haya hecho el mismo trabajo que tú hubieras hecho. Ahórrese tiempo, esfuerzo y pruebas.
Como probablemente sabe: "el tiempo es dinero". Entonces, al utilizar un marco popular con muchos ayudantes, una gran cantidad de ejemplos de código en la web y una gran comunidad, usted hace más en menos tiempo.
A veces está bien si usas frameworks porque te vuelves más productivo, pero en algunos proyectos avanzados y difíciles puede suceder para que el framework se mantenga en tu camino y tengas que encontrar soluciones temporales.
Creo que no hay una respuesta definitiva. Debe poner en equilibrio los pros y contras y tomar la decisión correcta para su proyecto.
Por lo general, adopto frameworks populares muy rápido pero no en partes críticas de los proyectos y con el tiempo extiendo su uso.
Creo que la razón principal es que cuando utilizas un marco común, hay muchas personas que están familiarizadas instantáneamente con tu producto.
Aparte de eso, creo que es muy importante que las herramientas que uses realmente hagan el trabajo. Si resulta familiar para otras personas, entonces eso es una ventaja.
Creo que si no ves la necesidad de usar un framework, entonces no lo hagas.
La razón por la que utilizo un marco, por ejemplo Django para python o Rails para Ruby o Webforms y MVC para ASP.net es porque hacen que sea más fácil y rápido escribir aplicaciones para ellos. En el caso de Ruby y Python, no usar un marco para mí me volvería loco.
Si tiene algo que funciona y no ve la necesidad de utilizar un marco, le diría que se quede con lo que cree que es mejor. Pero, aún estaría al día con los marcos.
Creo que son más útiles si estás empezando desde cero y no tienes tiempo para escribir el tuyo. Si ya tiene una base de código que desarrolló a lo largo de los años, puede ser mucho menos útil, pero aún puede ser útil echar un vistazo y ver qué hicieron.
Por ejemplo, estoy seguro de que las principales tiendas de desarrollo de juegos no utilizan herramientas, motores y marcos de terceros, no porque no sean suficientes, sino que ya han construido los suyos desde los años 80 o lo que sea.
Además, si está usando un componente estándar, no hay forma de excederlo en su área particular. Si necesita ser un líder del mercado en una dimensión particular, debe construir su propia solución en esa dimensión, para que pueda liderar. Si no necesita esta capacidad, usar un componente de terceros que sea tan bueno como el suyo puede ser una buena solución siempre que sea una transición fácil. Sin embargo, el tiempo para entrenar en la nueva herramienta y vivir con sus idiosincrasias puede o no valer la pena.
La otra cosa a considerar es que si puedes construir algo, realmente lo entiendes. De lo contrario, no lo haces. Ahora, no es necesario que entiendas completamente las cosas para usarlas, siempre y cuando "simplemente funcionen", pero todos sabemos cómo va eso ... :)
Cualquier desarrollador experimentado puede construir un marco: la parte desafiante es convencer a otros de que vale la pena usarla . Deberá crear documentación y tutoriales para quienes planean usarlo o mantenerlo. Probablemente necesites crear un sitio de demostración para demostrar que es útil y funciona como debería.
Solo eso puede ser una inversión considerable, sin incluir errores que podrían surgir en el medio. Cuando todo esté dicho, podría valer la pena dedicar tiempo a aprender otro marco en lugar de hacer el suyo propio.
Mencionaste CodeIgniter. Personalmente creo que es un marco bonito. No tiene mucho más que eso.
Desventajas
La mayoría de los trabajos de marcos no están orientados a objetos. (el encendedor de código muestra alguna promiss)
La mayor parte del código se hace a través de includes. Tratar de localizar el problema es como tirar de un hilo en un suéter y tener que desenredar la prenda entera para comprender completamente la creación.
La mayoría de los trabajos de marco tienen documentación mal escrita.
La mayoría de los trabajos de marcos intentan hacer muchas muchas cosas.
A partir de mi experiencia en el desarrollo de trabajos de marcos, me parece que se necesitan entre 3 y 6 meses para obtener el código base. Y es solo después de ese período de tiempo que descubrirás el tiempo en el que intentas insertar una estaca cuadrada en un agujero redondo. Dado que la mayoría de los proyectos de php quieren terminar antes de que haya transcurrido ese período, a los empleadores les costará más conseguir que cualquier proyecto utilice un gran "trabajo de marco" para su realización.
Muchos de los trabajos de Frame php fueron escritos para php 4, y fueron escritos en un entorno diferente. Se han ampliado mucho, pero están mostrando sus orígenes. El uso de restricciones globales es particularmente frecuente. Estoy esperando que php 6 ponga a la mayoría de ellos a la muerte. El encendedor de código escapa a la mayoría de esto, pero es nuevo y tiene partes orientadas a objetos.
Algunos trabajos de marcos tienen código escrito que no es necesario y causa problemas. Por ejemplo: CAKE tiene un excelente controlador de vista modelo, pero su manejo de sesión es un desastre. Lamentablemente, los trabajos de marcos no están escritos de forma modular. A menudo es una opción de todo o nada.
Los programadores de MOst "piratean" el trabajo del marco para que haga lo que quieran. Esto deja a los futuros programadores agitando sus cabezas. También hace que la "actualización" del trabajo de marco sea imposible.
Todavía tengo que ver un trabajo de marco que implemente pruebas unitarias. (¿Cómo sabes que no lo has roto?)
dame un objeto bien escrito en cualquier momento. Al menos ellos conocen el alcance desde el principio.
Es probable que el código del marco esté bien probado y relativamente libre de errores. Al usarlo, se ahorrará tiempo probando / manteniendo su propio código para hacer lo mismo.
Y cualquier tiempo ahorrado es bueno. La pereza vale la pena en la programación.
Estoy de acuerdo en que deberías usar tu propio framework personalizado. No solo es más fácil de entender, ¡sino que brinda lo último en seguridad laboral!
Las ventajas son que ya está escrito y probado por varias personas, por lo tanto, es menos probable que sea propenso a errores.
Las desventajas son que no está específicamente diseñado para su aplicación y, por lo tanto, probablemente tenga un peor rendimiento.
En general, realmente no veo muchas razones para usar una considerando que ya tienes la tuya ... aunque puede valer la pena liberar esa fuente abierta para que otros puedan verificar errores y recomendar mejoras.
Lo que esencialmente tienes es tu propio marco. Por lo tanto, no es un ahorro de tiempo PARA USTED, porque ya ha dedicado el tiempo para desarrollar el marco. Si no tuviera eso para construir, sería más fácil y más rápido usar un marco existente que hacer el suyo propio.
Lo que debe observar es si su marco de trabajo es mejor que otras opciones y si su familiaridad con su propio código es mayor que si otros ojos lo observaran y otras personas lo usaran de maneras lo suficientemente diferentes que la probabilidad de que los problemas encontrados y corregidos son mucho más altos.
Además, si su marco es mucho mejor que los demás, podría considerar abrir el suyo a la comunidad;)
Los marcos tienen varias ventajas:
No tienes que escribir todo. En su caso, esto es menos útil porque tiene su propio marco que ha acumulado a lo largo de los años.
Los marcos brindan formas estandarizadas y probadas de hacer las cosas. Cuantos más usuarios hay de un marco dado, más casos extremos se han encontrado y codificado. Tu propio código puede, o no, ser endurecido por la batalla de la misma manera.
Otros pueden ser reclutados en un proyecto con un marco estándar y tener acceso a la documentación, ejemplos y experiencia con ese marco. Sus propios fragmentos pueden o no estar totalmente documentados o tener ejemplos de uso ... pero no hay muchas posibilidades de que los demás se sientan cómodos con ellos inicialmente.
EDITAR:
Con respecto a su idea de empaquetar su propio marco, el beneficio de limpiarlo para el consumo público puede ser mayor que el beneficio de lograr que otros lo usen.
La razón es simple: tendrá que volver a evaluar sus suposiciones sobre cada componente, cómo encajan y qué tan clara es cada pieza para comprender. Una vez que publique su marco, su éxito dependerá en gran medida de lo fácil que sea ponerlo en funcionamiento.
Las grandes ganancias con poco esfuerzo son esenciales para la adopción (esas ganancias alentarán a las personas a profundizar en el marco). Ruby on Rails en un ejemplo de un marco que da grandes ganancias con poco esfuerzo, y luego tiene capas ocultas de características que habrían abrumado a alguien que acaba de comenzar. (La cuestión de la calidad de las aplicaciones RoR no es el punto, el punto es acerca de la velocidad de adopción).
Después de que las personas adoptan un marco, se trata de la facilidad de uso continuo. Pequeños detalles como los patrones de uso de parámetros consistentes marcan la diferencia aquí. Si una clase tiene muchos parámetros en cada método, mientras que otra tiene instaladores que se espera que sean invocados antes de invocar métodos, perderá usuarios porque no pueden obtener una "sensación" de lo que se espera en un caso dado sin recurrir a la documentos.
Si los problemas de facilidad de adopción y de facilidad de uso se abordan de forma adecuada, solo tiene que tener la suerte de que las personas adopten su marco. Si esos problemas no se abordan adecuadamente, incluso un interés inicial en el marco disminuirá rápidamente. La razón es que hay muchos marcos: tendrá que destacarse para obtener las ventajas de tener a otros utilizando su kit (ya que, por derecho, son tan cautelosos con su marco como lo son con los demás).
Me iría contra la corriente aquí, y digo, debería usar su propio marco personalizado, si el software que está construyendo es el núcleo de su negocio. Como diría Joel: " Encuentra las dependencias y eliminalas ". Si solo está instalando un pequeño sitio web para su empresa, y su empresa no está manteniendo sitios web, entonces continúe y utilice un marco. Pero cuando ese sitio web es su negocio, entonces no debe depender de un marco de otra persona para que pueda hacer el trabajo.
Puede que tengas razón ... sin embargo, no subestimaría el poder de muchos, como un ejemplo, phpBB es lo que me preocupa que use la solución bb. ¿Por qué? Porque hay muchos, muchos miles de mensajes en sus paneles de soporte y muchas personas que lo usan que están bien informados y pueden ayudar a las personas a resolver problemas.
Por lo tanto, la única razón en su caso para usar un marco popular es el de muchos otros que lo utilizan, informan errores en su contra, lo reparan y lo respaldan. Será complicado obtener la misma cobertura en sus propias bibliotecas.
Tres razones por las que puedo pensar de inmediato:
- Un marco bien conocido será familiar para otros desarrolladores que puedan tener que trabajar en su proyecto.
- Un marco bien conocido tendrá recursos como libros, paneles de discusión y otros expertos que se pueden usar para buscar más información
- Los gerentes a menudo tendrán una filosofía de "no reinventar la rueda". De hecho, las soluciones existentes probablemente hayan resuelto los mismos problemas que descubrirías si creas tu propia solución.
Dicho todo esto, aún puede haber un lugar para sus propias soluciones. No tendríamos tantos marcos (o lenguajes de scripting) para elegir si nadie comenzaba algo nuevo.
Una cosa que se perderá es toda la Validación que entra en un marco popular.
Sus rutinas simplemente no tienen la misma exposición que las bibliotecas populares.