¿Ruby on Rails es bueno para proyectos a gran escala?

Estoy trabajando en una presentación sobre RoR. Se ve bien, excepto que no puedo encontrar nada para la sección "Problemas". Parece que no hay ninguno. :)¿Ruby on Rails es bueno para proyectos a gran escala?

Particularmente Estoy interesado en:

¿Qué problemas están allí con facilidad de mantenimiento/gestión cuando varios desarrolladores están involucrados en el proyecto RoR a gran escala?
¿Qué consideraciones específicas existen para los desarrolladores en tales proyectos a gran escala que usan lenguajes tipados dinámicamente frente a lenguajes tipados estáticamente?
¿Por qué RoR podría no ser adecuado para proyectos a gran escala?

No pude encontrar nada en esta búsqueda en Internet. Me gustaría escuchar tus pensamientos sobre estos puntos?

Gracias, Arkadiy

Fuente

2011-01-07 arkadiy

Estoy bastante seguro de la calidad del código y la aplicabilidad marco depende más de la gestión de equipos y otras herramientas que en el lenguaje y el marco. no se puede citar cualquier cosa, desde la parte superior de la cabeza en el momento –

http://stackoverflow.com/questions/14823/is-ruby-on-rails-ready-for-the-enterprise y http: //www.infoq. com/articles/changing-the-present-case-stud – Zabba

http://www.canrailsscale.com/. ¡Amo a Rails realmente! –

Estoy seguro de que se puede encontrar mucho de esto en la red, pero estoy feliz de hacerlo.

Maintainable: Ruby and Rails se trata de crear un código más fácil de mantener a costa de un poco de rendimiento. Es por eso que Ruby es un lenguaje dinámico en primer lugar. En lo que respecta a desarrolladores/equipos, Rails es ideal para crear y mantener código que sea fácil de comprender y mantener.
dinámico vs estática: Desde la perspectiva de un equipo de desarrollo, lenguajes estáticos tienen la ventaja de ser muy explícito. No hay magia para confundir a los nuevos desarrolladores, y debería haber poco trabajo en términos de perseguir fantasmas (en teoría, de todos modos). Esa ventaja es superada rápidamente por la capacidad de un lenguaje dinámico para realmente aprovechar el OOP y comenzar a desarrollarse rápidamente.
apropiado: No puedo pensar en ninguna buena razón. Está basado en pruebas, probado y extremadamente bien diseñado. Fue hecho para hacer el trabajo, por lo que no me sorprende que este sea el caso. :)

Fuente

2011-01-07 09:35:37 coreyward

Hay dos lados de la moneda rieles. Por un lado, tiene poderosas herramientas a su disposición, lo que le permite desarrollarse rápidamente de manera adecuada. Por otro lado, existen las llamadas mejores prácticas de la comunidad de rieles convencionales, que en realidad son una receta para desastres, como modelos de grasa, etc. Al final, todo se reduce a su propia cultura y métodos que darán como resultado un proyecto sostenible. . –

Menciona mantenimiento. Y durante años la comunidad de Rails apuesta por "controladores delgados, modelos gordos", un mantra a la mitad de la derecha. Hay más ejemplos como ese. No estoy criticando nada, solo mencionando las trampas comunes que encontré en mi viaje con Rails. Hay muchas aplicaciones de nivel 'empresarial' escritas con Rails, y todo se reduce a que los desarrolladores creen código que se pueda mantener al final. –

Para escalabilidad, si Twitter puede doIT así que creo que puede hacerlo también.

Y Mantenibilidad, como en cualquier otro lenguaje de programación, necesita utilizar algún tipo de control de versiones, svn o git.

Fuente

2011-01-07 07:45:38 Edmhs

backend de Twitter ya no está en los carriles. Están corriendo en Scala. Así es como pueden hacerlo. – picardo

Twitter usar Scala y RoR;) http://www.artima.com/scalazine/articles/twitter_on_scala.html – Sinetris

La mayoría del equipo de desarrolladores de RoR trabaja en MAC en mi experiencia. Usando git o svn para control de versiones. La mayoría usa TextMate o Komodo. Especial con Komodo Pro puede usarlo bien en equipos. Un buen cliente SVN hay Versiones

Yo no trabajé en equipos más grandes y luego 5 desarrolladores, que no es a gran escala Creo :) Pero el marco en sí es mucho más fácil de manejar como la mayoría de los otros que tengo visto. Usado principalmente en Scrum-Teams, pero si tienes una buena organización, no veo ninguna desventaja al usar RoR en equipos grandes.

Las herramientas de documentación de código son prácticas, dividir los modelos, controladores y vistas en diferentes secciones para los miembros del equipo no debería ser un gran problema y la configuración de servidores de prueba con builts nocturnos es muy fácil.

Utilizamos RoR en entornos Linux y Windows y tenemos una muy buena experiencia productiva. Técnico es tan escalable como otros marcos grandes, con sql_sessions y mem_cache puede configurar fácilmente una granja de servidores para ejecutarlo para miles o millones de usuarios.

So imho: Es capaz para cualquier tamaño de equipo.

Fuente

2011-01-07 07:56:16 YvesR

¿Ruby on Rails es bueno para proyectos a gran escala?

Respuesta

Cuestiones relacionadas