¿Por qué necesito usar un marco popular?

Question

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 mirar a través de algunos de los otros marcos populares, todavía veo nada que sería que mucho de un ahorro de 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?

Edición: Si miras aquí algunas de las respuestas, ¿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?

Answer 1

marcos tienen varias ventajas:

• Usted no tiene 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 proporcionan 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 tienen 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.

EDIT:

Con respecto a su idea de envasar su propio marco, el beneficio de la limpieza para arriba para el consumo público puede ser mayor que el beneficio de obtener otros para usarlo.

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 correctamente, 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 con razón son tan cautelosos con su marco como lo es con los demás).

Answer 2

Puede que tenga un punto .... sin embargo, no me gustaría subestimar el poder de muchos, como un ejemplo de phpBB es en lo que a mí respecta la solución bb para su uso. ¿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, el único motivo en su caso para utilizar un marco popular es el de muchos otros que lo usan, informan errores en su contra, corrige y lo admite. Será complicado obtener la misma cobertura en sus propias bibliotecas.

Answer 3

Una cosa que se estará perdiendo es toda la Validación que entra en un marco popular.

Sus rutinas simplemente no tienen la misma exposición que las bibliotecas populares.

Answer 4

Creo que la razón principal es que cuando utiliza un marco común, hay muchas personas que están familiarizadas instantáneamente con su producto.

Aparte de eso, creo que es muy importante que las herramientas que use realmente hagan el trabajo. Si resulta familiar para otras personas, entonces eso es una ventaja.

Answer 5

Es probable que el código de la estructura 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 momento ahorrado es bueno. La pereza vale la pena en la programación.

Answer 6

Acepto que debe usar su propio marco personalizado. No solo es más fácil de entender, ¡sino que brinda lo último en seguridad laboral!

Answer 7

Tres razones que se me ocurre de inmediato:

• un marco conocido será familiar para otros desarrolladores que pueden tener que trabajar en su proyecto
• un marco conocido tendrá recursos como libros , foros de debate y otros expertos que se pueden utilizar para obtener más información
• Los gerentes suelen tener 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, todavía puede haber un lugar para sus propias soluciones. No tendríamos tantos marcos (o lenguajes de scripting) para elegir si nadie comenzaba algo nuevo.

Answer 8

Como probablemente sabrá: "el tiempo es oro". 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 es útil usar frameworks porque se vuelve más productivo, pero en algunos proyectos avanzados y difíciles puede suceder para que el framework se mantenga en su camino y tenga que encontrar soluciones.

Creo que no hay una respuesta definitiva. Debe poner en equilibrio los pros y contras y tomar la decisión correcta para su proyecto.

Normalmente adopto frameworks populares muy rápido pero no en partes críticas de los proyectos y con el tiempo extiendo su uso.

Answer 9

Creo que si no ve la necesidad de utilizar un marco, no lo haga.

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 usar 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.

Answer 10

Lo que esencialmente tiene es su 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 supera el hecho de tener otros ojos mirándolo, y otras personas que lo utilizan de maneras suficientemente diferentes que la probabilidad de que se encuentren y corrijan los problemas es mucho mayor.

Además, si su estructura es mucho mejor que el mundo vigilara, usted podría considerar la apertura de los suyos hasta la comunidad;)

Answer 11

Cualquier desarrollador con experiencia puede construir un marco - la parte difícil es convencer a otros de que vale la pena usar. 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.

Eso solo puede ser una inversión considerable, sin incluir errores que podrían aparecer 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.

Answer 12

Creo que son más útiles si está empezando desde cero y no tiene el tiempo para escribir el suyo. 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 usan herramientas, motores y marcos de terceros, no porque no sean suficientes, sino que ya han construido los suyos desde los 80 o lo que sea.

Además, si utiliza un componente comercial, no hay forma de excederlo en su área en 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 necesita comprender completamente las cosas para usarlas, siempre y cuando "simplemente funcionen", pero todos sabemos cómo funciona ... :)

Answer 13

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 los problemas que se pueden montar en 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 intenta forzar un problema dentro de un marco que simplemente no encaja o tiene alguna característica inusual no estándar, en cuyo caso completa el 90% del código muy rápido y luego pasa todo el tiempo que tiene. 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.

Answer 14

Aquí hay otra razón no para crear su propio marco. Linus' Law - "Teniendo 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 clientes es divertido, pero ¿qué ocurre 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.

Answer 15

Me iría contra la corriente aquí, y digo, debe utilizar su propio marco personalizado, si el software que está construyendo es el núcleo de su negocio. Como diría Joel, "Find the dependencies - and eliminate them". 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.

Answer 16

¿Puedes resolver los problemas que tienes con tu código de forma más rápida y confiable que los marcos públicos?

En caso afirmativo, continúe usando el suyo.

Si no, busque el marco que hace un mejor trabajo y ejecútelo para ese proyecto.

Todo se reduce a la cual base de código hace el trabajo mejor (para el valor de la mejor propuesta por el cliente;.))

Answer 17

Las ventajas son que ya está escrito y probado por varias personas, por lo tanto menos probable que se propenso a errores.

Las desventajas son que no está diseñado específicamente para su aplicación y, por lo tanto, lo más probable es que tenga un peor rendimiento.

En general, realmente no veo muchas razones para usar una porque ya tiene la suya ... aunque puede valer la pena liberar esa fuente abierta para que otros puedan verificar errores y recomendar mejoras.

Answer 18

Desventajas.

La mayoría de los trabajos de marcos no están orientados a objetos. (el encendedor de código muestra algunos promiss)

La mayor parte del código se hace a través de includes. Tratar de rastrear el problema es como tirar de un hilo en un suéter y tener que desenredar toda la prenda para entender completamente la creación.

La mayoría de los trabajos de marcos tienen una documentación mal escrita.

La mayoría de los trabajos de marcos intentan hacer muchas cosas.

De acuerdo con mi experiencia en el desarrollo de trabajos con marcos, me lleva unos buenos 3-6 meses subirme al 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 marcos php se escribieron para php 4 y se escribieron 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 de 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 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 las 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.