¿Hay algo malo en el desarrollo de proyectos en frameworks PHP creados por uno mismo?

¡Hola!

Un marco que parece prometedor es Laravel. He querido probarlo durante mucho tiempo, pero bueno, es lo que es y también tengo cosas que hacer 🙂

¿Sabes dónde realmente podrías hacer la diferencia? Una vez más, esta es una idea con la que he jugado pero no tengo tiempo, pero creo que, si alguien lo hiciera y fuera de código abierto, casi todos estarían encantados de crear una capa en la parte superior de la API de PHP.

Para entender lo que estoy diciendo, considere la administración de arreglos: toneladas de funciones con parámetros inconsistentes, haciendo cosas muy diferentes, etc. Ahora, si alguien lo pensó y creó una clase sangrienta que maneja arreglos y que simplemente necesita para ser incluido, ¿no sería genial?

Obviamente, las matrices son la fruta colgante (y no la única, hay muchas otras), pero imagina las posibilidades. Apuesto a que tendrías un montón de personas dispuestas a ayudar, mejorando todo con el tiempo y finalmente poniendo algo de cordura en ese lío.

Piénsalo, concéntrate en lo que realmente importa 🙂

En general, suele ser una mala idea, especialmente si está bajo restricciones de tiempo o presupuesto, trabajando con un equipo y / o en un proyecto comercial.

La mejor pregunta es “¿realmente necesito un marco?” Muchos de los pequeños proyectos únicos no. No cometa el error de novato de tratar de resolver problemas que aún no tiene, ni anticipe las necesidades de proyectos futuros que aún no ha comenzado. La generalización prematura, como la optimización prematura, es cáncer de código.

El objetivo de un marco es tener una colección de problemas resueltos y preguntas respondidas sobre estilo y arquitectura que sean aplicables a una amplia gama de proyectos, a fin de servir como un punto de partida para poner en marcha un nuevo proyecto rápidamente.

Si está escribiendo un nuevo “marco” cada vez que crea una nueva aplicación, todo lo que realmente está haciendo es escribir código que no necesita para resolver un problema que no tiene , porque el problema que resuelve un marco es “Necesito poner esto en marcha con un mínimo esfuerzo utilizando herramientas que ya entiendo”. Claramente, si está escribiendo un nuevo marco no ha resuelto ese problema, por lo que tampoco tiene el problema y no necesita el código o tiene el problema y no lo está resolviendo.

Entonces, el momento adecuado para escribir un marco es cuando no tienes un proyecto para terminar, tienes experiencia con suficientes otros marcos para entender cómo funcionan, por qué existen y qué problemas están destinados a resolver, y piensas ha identificado una nueva clase de proyectos que no abordan o una mejor manera de hacer las cosas.

Si crea su propio marco, será la única persona que puede actualizarlo o realizar cambios. Este es un profesional y un estafador. Hace que su trabajo sea más original y genuino, pero también puede hacer que se pierdan pequeñas cosas en el proceso.

La belleza de los marcos abiertos es que generalmente hay un par de cientos de personas que lo usan cada día que realizan actualizaciones o corrigen errores. Sin embargo, esto significa que habrá muchas otras personas que usen dicho marco.

En general, definitivamente no hay nada de malo en desarrollar proyectos utilizando sus propios marcos.

El mayor problema es que los marcos públicos están bien utilizados y bien probados, ¿es suyo? Si el cliente prefiere un determinado marco, entonces debe usarlo. No tenerlo puede significar que no puedes conseguir el trabajo.

Ahora, si eres autónomo y a tus clientes no les importa, usa lo que quieras.

Estoy tratando de explicar los contras en breve.

Tienes un proyecto de un cliente.

Lo desarrollas con tu propio marco.

Después de 1 año, el cliente lo dejó y asignó a mi equipo para algunas actualizaciones.

Ahora desde mi perspectiva

  1. mi equipo necesita entender todo el código.
  2. ¿Hay alguna documentación disponible? No
  3. Necesito entrenar a todo mi equipo. significa pérdida de tiempo y dinero
  4. ¿Está estructurado el código? puede ser si o no. Depende de ti.
  5. ¿El código sigue los estándares? puede ser si o no. Depende de ti.

Entonces ves que hay muchos inconvenientes para ello.