¿Te presentamos Rails en una tienda PHP? ¿O construir lo que ya usamos?

Question

Aquí está la configuración en nuestra tienda:

• 1 muy grande de aplicaciones PHP (Kohana 2) con muchos de Dev y mucha infraestructura
• múltiples (4-5) y crecientes pequeña PHP aplicaciones con 1- Trabajo 2 de dev en estos

Problemas:

• ninguna prueba
• ninguna documentación
• una implementación frágil y tedioso proceso de

que estoy de estar situada en la gran aplicación única a un lado de la casa con las múltiples aplicaciones más pequeñas. La falta de pruebas y un proceso de implementación adecuado en nuestra tienda me pone nervioso porque dedicaré más tiempo a corregir errores y a implementar soluciones que a escribir códigos para nuevas funciones.

Solución A:

• Introducir PHPUnit y el selenio
nos
• pasar a Phing y Dbdeploy

problema con un: Configuración de PHPUnit ha sido relativamente fácil, pero funcional las pruebas con Selenio han sido un dolor total. Nuestro VM funciona muy bien para dev, pero Selenium clava la aguja, además de unas pocas pruebas simples que duran para siempre. No dudo que pueda hacer que todas estas tecnologías funcionen bien juntas, pero todo parece un desastre y la complejidad de trabajar juntas parece frágil.

Solución B:

• Cambiar a rieles
• Uso pruebas integradas y/o Rspec/pepino (integración de la último parece sencilla)
• uso integrado migraciones DB
• Uso Capistrano para implementaciones

Basado en los principales problemas o f pruebas, comencé a mirar en Rails. En función de la naturaleza de estos otros sitios que administramos, creo que Rails puede ser una buena solución. Pruebas integradas, gran comunidad, muchas herramientas excelentes y desarrollo rápido.

Problema con B: Todas las aplicaciones que tenemos en este momento está en Kohana 2 (framework PHP) y nadie en la organización sabe rieles. La desventaja de la introducción de una nueva tecnología sería fracturar a los equipos. Si migro los sitios a Rails, luego me atropella un autobús, estamos medio jodidos.

En pocas palabras:

En base a los puntos de dolor (despliegues, pruebas, documentación, migraciones DB), ¿merece la pena el costo de cambiar a los carriles? ¿O deberíamos quedarnos en Kohana y seguir intentando conseguir las otras herramientas?

¿Alguna sugerencia? ¿Alguien pasó por algo similar? La gerencia ya me dijo que están abiertos para escuchar sobre Rails y que simplemente quieren usar la mejor herramienta posible, sea lo que sea. Nuestro arquitecto principal, sin embargo, necesitará un poco de convencimiento si decido cambiar los marcos en nuestros proyectos más pequeños.

Answer 1

Hay muchos factores que influirán en su decisión.

Si cambia a raíles, tenga en cuenta que llevará un tiempo para que usted y su equipo aprendan el marco/lenguaje y puedan ralentizar fácilmente la adición de funciones por un tiempo. Realmente solo depende de tu equipo, limitaciones de tiempo y muchos otros factores.

Quizás intente uno de los pequeños proyectos con rieles y vea si a usted y su equipo realmente les gustan los rieles (no lo sé).

La respuesta será diferente para cada equipo. Me gustaría tener una reunión de grupo y discutir los pros y los contras de ambas decisiones. Entonces ten un voto

Answer 2

Creo que puede obtener muchas respuestas diferentes dependiendo del tipo de desarrolladores que seamos.

Personalmente, creo que debe apegarse a PHP, pero pasar a Kohana 3. Y luego introducir mejores técnicas de gestión y desarrollo (documentación, pruebas, etc.). Solo mi opinión, realmente no es una solución.

Answer 3

Pasando a los carriles (o cualquier otro idioma), probablemente le costará mucho en al menos una de las siguientes maneras:

1. inversión de tiempo. Todo su equipo tendrá que aprender Rails, mientras continúa trabajando con PHP.
2. Costo del servidor. Deberás tener un conjunto separado de servidores para Rails y PHP.
3. Costo humano. Es posible que algunos de su equipo no quieran cambiar y tendrán que contratar gente nueva.

Mi recomendación es que mire en phpUnderControl y comience a comentar su código. No es necesario que escriba montones de documentación, pero asegúrese de que se comente cada método.

Y, por último, mi opinión completamente parcial es que deberías probar Kohana 3. Incluso si no puede migrar sus aplicaciones existentes, podría ahorrarle algo de frustración con las nuevas aplicaciones.