Usando el marco existente.
En primer lugar la creación de un marco de cero representa una gran inversión en tiempo y esfuerzo. El proceso implica mucho ensayo y error, porque estás diseñando algo que debe ser simple y poderoso. Para cada decisión de diseño, tendrá que preguntarse cómo afectará cada proyecto futuro que se construirá en su marco.
Cree que podría tomar cada decisión de diseño y sopesarla con los requisitos como lo haría con cualquier otro proyecto de software, pero lo que pasa es que no conoce sus requisitos. No puede conocerlos, porque se supone que un marco puede hacer casi cualquier cosa (o tener la capacidad de extenderse para hacer casi cualquier cosa) dentro de su dominio. El proyecto futuro a deberá poder hacer x. ¿Puede su marco permitir eso sin convertirlo en código de spaghetti? ¿Y si el proyecto b tiene que hacer y? ¿Qué sucede si el proyecto c necesita hacer z?
¿Has predicho todo?
Ahora la respuesta normal a esto es que si algo no funciona, simplemente lo cambiarás en el futuro. Es un software después de todo. Sin embargo, un marco no es como una simple aplicación. Se supone que tiene una interfaz y, una vez que la expones al software que la usará, no puedes cambiarla. Puedes extenderlo, pero no cambiarlo. Entonces ahora debes pensar en métodos de desaprobación, versiones api y compatibilidad de versiones. Se trata de un nuevo conjunto de problemas para tratar junto con el mantenimiento normal del marco y la escritura de nuevas aplicaciones.
Luego está la documentación.Necesitas una API, tutoriales, código de ejemplo. Una vez que construyes tu propio marco, tienes que lidiar con esto también. Podría ignorarlo, pero le aseguro que eventualmente usted mismo tendrá que averiguar qué hace ese método que escribió hace 6 meses. ¿Qué devuelve? ¿Qué sucede si ocurre un caso especial x? ¿Has escrito todo eso o necesitas volver a pasar por el código? Y ni siquiera mencionaré lo fácil que será para un nuevo miembro del equipo iniciarse en un marco personalizado cuya documentación se encuentre completamente o al menos en su cabeza.
También debe reconocer que, a menos que trabaje con los mejores y más brillantes (y tenga un presupuesto que coincida), nunca tendrá el extenso conjunto de bibliotecas que los frameworks existentes presumen. ¿Puedes analizar, diseñar, codificar, probar y depurar más rápido que una comunidad de código abierto?
Finalmente, debe preguntarse si es lo suficientemente hábil para escribir un marco. ¿Has buceado en el código de un framework OO PHP5 moderno para descubrir qué lo hace funcionar? Y lo más importante, ¿sabe usted por qué hace las cosas de esa manera en particular? Tenga en cuenta que cualquier error que cometa en su diseño puede explotar en su cara dentro de unos meses y puede terminar pagándolo una y otra vez.
Para resumir, le aconsejo que vaya con un marco existente; sin embargo, eso no significa que tengas que elegir uno y te guste. Tómese el tiempo que de lo contrario habría dedicado al desarrollo de un nuevo marco y dedíquelo a aprender uno existente. Luego puede ampliarlo para que se ajuste a sus necesidades. También recuerde que podría haber cosas que no podrá hacer. Pero te aseguro que también habría cosas que no podrías hacer con tu propio marco, así que no importa demasiado. Un marco impone algunas limitaciones. Es el precio que paga por poder desarrollar aplicaciones más rápido.