Ruby on Rails inconvénients et mises en garde [fermé]

Ce n'est pas un pari d'ouverture pour dénigrer RoR - honnête!

J'apprends Ruby et le framework Rails. À première vue, il semble être assez cool et une expérience merveilleuse par rapport à PHP. (En fait, cela me rappelle des jours plus heureux avec C # et .NET.)

Cependant, dans ce domaine, je n'ai aucune expérience de ce cadre ou de ce langage, et je suis curieux - quels sont les inconvénients actuels ou les choses que vous souhaiteriez savoir au début?

(Peut-être que cela devrait être un wiki communautaire?)

Cela vient de l'expérience d'apprentissage, de la poursuite de l'apprentissage et de l'écriture d'une application relativement simple dans Rails.

1) Courbe d'apprentissage

Rails est d'une simplicité trompeuse. Les tutoriels, vidéos et livres montrent tous à quelle vitesse vous pouvez obtenir une application fonctionnelle (si moche), mais ceux-ci ne font qu'effleurer la surface. Ils ont tendance à dépendre fortement de la génération de code et de «l'échafaudage», qui est certes un bon outil lors de l'apprentissage mais qui survit rapidement à son utilité.

Ne vous y trompez pas, Rails est difficile à maîtriser. Une fois que vous aurez dépassé les bases (plus à ce sujet plus tard), vous courrez tête baissée dans un mur si vous devez faire plus que la fonctionnalité "d'application de démonstration" extrêmement simpliste que vous voyez vanté. Vous pouvez vous débrouiller avec une connaissance de base de Ruby tout en apprenant, mais vous devez rapidement prendre Ruby ou vous serez laissé haut et sec (et pas le bon type de DRY) si vous devez aller en dehors des contraintes de Rails.

Rails est, comme j'aime l'appeler d'une manière aimante, la peinture par programmation numérique . Si vous respectez à 100% les conventions (c'est-à-dire que vous respectez les lignes et utilisez les couleurs qu'on vous dit d'utiliser), vous pouvez faire des applications décentes rapidement et facilement. Si et quand vous devez vous écarter, Rails peut passer de votre meilleur ami à votre pire ennemi.

2) Quand tout ce que vous avez est un marteau ...

Rails fait très bien les applications CRUD simplistes. Le problème survient lorsque votre application doit faire plus que lire / écrire à partir d'une base de données. Maintenant, pour mémoire, la dernière version de Rails que j'ai utilisée était la 2.3.4, donc les choses ont peut-être changé depuis, mais j'ai rencontré des problèmes majeurs lorsque les besoins de l'entreprise ont changé, de sorte que l'application devait avoir un petit système de workflow intégré et s'intégrer avec une ancienne application PHP. La convention Rails de "un formulaire, un modèle" fonctionne bien pour les applications triviales et les applications de saisie de données, mais pas tant lorsque vous devez faire une logique de traitement, ou avoir des flux de travail, ou tout ce qui n'est pas typique "L'utilisateur entre des données dans quelques champs de texte, frappe Soumettre "type de chose. Cela peut être fait, mais ce n'est en aucun cas «facile», ou plutôt ce n'était pas

De plus, Rails n'aime pas bien jouer avec d'autres applications qui n'utilisent pas ses méthodes préférées d'accès aux données; si vous devez vous interfacer avec une application qui n'a pas d'API de style "Web 2.0", vous devez contourner Rails au lieu de l'utiliser; encore une fois, je parle d'expérience ici car c'est ce qui m'est arrivé.

3) C'est nouveau

Enfin, Rails est toujours le "petit nouveau sur le bloc" dans de nombreux domaines. Cela n'a pas d'importance pour un usage personnel ou des scénarios de type "Je pense que c'est cool et je veux l'apprendre", mais parler comme quelqu'un qui préférerait utiliser Rails à mon travail de jour, si vous n'êtes pas dans un endroit où Rails est répandu, il peut être très difficile de trouver du travail à temps plein en tant que développeur Rails. C'est encore largement le domaine des «hip, nouvelles startups» et pas un acteur majeur dans la plupart des zones métropolitaines. Votre kilométrage peut varier à cet égard, mais je sais que ma région (Tampa) Rails est essentiellement inexistante.

4) Feu et mouvement

Rails est en constante évolution. C'est à la fois une bonne et une mauvaise chose; c'est bien parce que la communauté évolue et embrasse de nouveaux concepts. C'est mauvais parce que la communauté évolue et embrasse de nouveaux concepts. Cela peut être très accablant pour un débutant Rails parce que généralement lorsque vous rencontrez un problème et regardez autour de vous, vous verrez soit des gens recommander tel ou tel bijou pour le résoudre, soit dire que cette façon est mauvaise de toute façon et vous ne devriez pas '' t l'utiliser, voici une meilleure façon ... et vous vous retrouvez avec une liste de blanchisserie d'outils supplémentaires à apprendre avec Rails pour suivre les cognoscenti Rails. Des choses comme Git, BDD/RSpec, Cucumber,Haml/Sass, et une corne d'abondance d'autres choses flottent et sont considérées comme la "bonne façon de faire les choses" dans Rails-land, et en parlant d'expérience, vous pourriez finir par être submergé en essayant d'apprendre une douzaine de technologies ou plus en plus de Rails, car l'utilisation de la boîte à outils Rails standard semble "incorrecte".

Cela est maintenant encore plus compliqué par Rails 3.1, qui fait de Sass et CoffeeScript de toutes choses la valeur par défaut, donc un débutant total de Rails doit non seulement apprendre Ruby and Rails mais Sass (sans doute simple si vous connaissez CSS) et CoffeeScript (pas très difficile mais certainement suffisamment différent de JavaScript brut) au minimum pour commencer, et on peut supposer Git. Même sans prendre en compte RSpec et ses amis, et la douzaine de gemmes ou plus que vous finirez généralement, c'est 4 choses différentes que vous devez apprendre avant de pouvoir sérieusement commencer à écrire des applications Rails. Comparez cela à un langage comme C #, ou Java, ou même PHP où votre connaissance HTML / CSS / JavaScript / SQL ne va pas changer et vous n'avez qu'à apprendre le langage lui-même et peut-être les nuances du framework.

Documentation.

Bien que les guides Rails soient d'excellentes ressources d'apprentissage, la référence de bibliothèque Rails (et Ruby, en général) n'est pas facile à parcourir. Dites, vous voulez en savoir plus sur la belongs_tométhode. Bien qu'il soit utilisé sur des ActiveRecord::Basesous-classes (ses modèles), il n'est pas documenté dans les ActiveRecord::Basedocuments, mais dans un mixin que la classe importe. Essentiellement, vous ne pouvez pas voir une liste complète de toutes les méthodes que vous pouvez utiliser sur un objet en un seul endroit (sauf lorsque vous lancez irbet vérifiez l'objet lui-même).

Avec un langage très dynamique comme Ruby, il n'est pas simple de dire d'où vient une méthode que vous utilisez. Cela peut être un problème, en particulier pour les programmeurs en apprentissage qui tentent de saisir une nouvelle pile technologique.

Ruby on Rails a une courbe d'apprentissage importante. Vous devez d'abord apprendre les bizarreries de la langue, puis apprendre le cadre, puis apprendre la façon de faire des Rails, puis en apprendre davantage sur les nombreuses gemmes couramment utilisées.

Cependant, lorsque vous avez appris ces choses, cela vient incroyablement naturellement. En fait, d'autres cadres commencent à ressembler à un fardeau.

Rails est très orienté TDD / BDD, donc si vous ne l'êtes pas, c'est deux autres choses que vous devrez apprendre avant de devenir un programmeur Rails compétent. Vous n'avez pas de compilateur et d'IDE pour vous soutenir, donc la couverture des tests est vraiment votre solution de rechange.

De nombreux partisans du TDD, dont moi-même, considéreraient cette force du RoR ainsi que sa malédiction. Une fois que vous commencez à écrire TDD, vous constatez que la sécurité offerte par la couverture de test est meilleure que la sécurité offerte par un compilateur. Ensuite, avoir à écrire du code JUST pour plaire à un compilateur devient un fardeau.

TDD ne se sent pas comme une tâche supplémentaire dans RoR, c'est comme la seule façon de travailler.

Rails a un sérieux problème de performances: chaque requête est mise en file d'attente derrière la requête actuellement active, au lieu de les enfiler comme le font la plupart des frameworks ou de permettre aux événements de blocage de libérer d'autres requêtes comme le font Node.js et Twister. Cela signifie que vous devez coder pour accélérer les temps de réponse, mais c'est assez facile à faire dans la plupart des cas.

Rails est également très bien conçu pour gérer très bien les systèmes de contenu, ce qui, en toute justice, concerne beaucoup d'Internet. Faire quelque chose d'un peu plus compliqué, comme un jeu Web ou un système de commerce électronique, signifie apprendre de nouvelles gemmes. Vous apprenez rapidement que toutes les gemmes sont là, mais plus la chose que vous voulez faire est obscure, plus il sera difficile de trouver une bonne documentation.

Dans mon expérience personnelle, le principal mal de tête concerne la compatibilité .

Quand:

• il y a des xprojets de rails déployés,
• chaque projet utilise des ygemmes.
• alors qu'il existe des nversions de rails,
• plus m versions de gemmes installées,
• avec several versions de rubis,
• sur une seule boîte Linux comme machine de production.
• le programmeur travaille sur un autre ordinateur portable de développement OS X.

En tant que travailleur indépendant, qui n'a pas le luxe de mise à jour / mise à niveau la plupart des choses, fera face à beaucoup de problèmes de compatibilité de variables ci - dessus ... tout rails, gemset rubycontinuer à changer / évolution.

La vitesse est définitivement un problème. L'extrême flexibilité de Ruby s'accompagne d'un impact significatif sur les performances.

La mise à l'échelle horizontale n'est pas une tâche évidente, à l'exception des technologies spécialement conçues pour cette tâche, qui compromis généralement la simplicité pour bien évoluer.
Si vous pouvez traiter 100 fois plus de demandes par machine avec la technologie A qu'avec la technologie B, l'utilisation de la technologie A vaut la peine d'être considérée si vous avez des raisons de croire que vous pouvez servir vos données à partir d'un seul serveur pendant un laps de temps qui vous permet d'ajouter parallélisation par la suite.
En 2009, stackoverflow était toujours servi à partir d' un serveur Web . Bien sûr, ce n'est plus une option. Mais je suppose que c'était bien qu'ils aient commencé avec une technologie, qui pouvait s'étendre à beaucoup d'utilisateurs sur une seule instance, avant d'avoir à se soucier de la mise à l'échelle.

Par rapport à cela, RoR est vraiment lent. Le temps de traitement des requêtes simples est important et c'est donc un problème pour gérer de nombreux clients (tout cela doit être vu par rapport à des alternatives plus rapides).

Dans un souci d'orientation vague, voici quelques chiffres, comparant divers autres langages adaptés au développement web à Ruby:

• Aller
• Clojure
• JavaScript V8 ( node.js )
• JRuby (une alternative à ne pas oublier - en fonction de votre problème, JRuby peut être un meilleur ou un pire choix pour tirer un peu de vitesse d'une application de rails)
• Scala
• Java
• C #

Notez que cela ne signifie pas que si vous utilisez le framework X pour Java, il sera exactement 200 fois plus rapide que RoR. Mais la différence de vitesse mesurée dans ces benchmarks a un impact important sur les performances globales de votre application.

Rails a un sérieux problème de performances: chaque requête est mise en file d'attente derrière la requête actuellement active, au lieu de les enfiler comme le font la plupart des frameworks ou de permettre aux événements de blocage de libérer d'autres requêtes comme le font Node.js et Twister. Cela signifie que vous devez coder pour accélérer les temps de réponse, mais c'est assez facile à faire dans la plupart des cas.

Je pense que c'est très erroné. Vous pouvez exécuter Rails en mode multithread. Lorsque vous exécutez en mode multithread, vous ne devez utiliser que des bibliothèques d'E / S qui libèrent le GIL (par exemple, la gemme 'mysql2'), sinon cela devient en quelque sorte inutile.

Si vous utilisez jRuby, vous pouvez simplement exécuter un processus à rails uniques en mode multithread et utiliser pleinement toute la puissance CPU disponible. Cependant, si vous êtes en IRM (Ruby 1.8.x ou 1.9.x), vous devez exécuter plusieurs processus afin d'utiliser pleinement les CPU, ce qui est également le cas avec node.js.

• Rails a beaucoup de subtilités qui vous cachent la complexité. (Associations ActiveRecord, l'ensemble du cycle de vie de validation / sauvegarde, l'interprétation des données de demande sur la base des en-têtes fournis) Lorsque vous débutez, c'est génial. Au fur et à mesure que vous grandissez, vous constaterez que vous commencez à adapter votre application à la "manière Rails" de gérer les choses - parfois c'est bon, parfois cela est inoffensif, et parfois c'est en fait contre-intuitif à la chose que vous essayez de faire. Toutes les tables de base de données ne doivent pas être modélisées en tant qu'objets, une étape de validation peut devoir se produire ailleurs, etc. Beaucoup de programmeurs Rails évitent de ne pas lutter contre le framework (ce qui est généralement sage), mais l'effet à long terme de ceci est ... vous emportera les habitudes de Rails avec vous dans des endroits où elles ne sont pas nécessairement nécessaires.

• La communauté a l'habitude d'écrire des logiciels qui sont présentés comme «magiques» - des bibliothèques de mise en cache qui fonctionnent comme par magie! E / S événementielles qui vous rendent magiquement plus rapide! Magie magique! Ce qui est généralement le cas ici, c'est qu'une API très attrayante est fournie pour une solution technique qui fait défaut, et vous êtes dupé par les très jolis exemples que la chose fait ce que vous avez l'intention, et que vous découvrirez plus tard qu'elle couvre une solution incomplète. Le cycle de ceci est assez constant, et vous apprenez à rouler avec, mais vous devriez certainement vous familiariser avec l'idée de lire beaucoup et beaucoup de code dont vous dépendez (une bonne chose!). Les solutions de magie communautaire Rails ne sont pas aussi magiques que le README peut le suggérer, dis-je.

• Corollaire ci-dessus: plus vous utilisez Rails, plus vous devriez lire sa source. Mieux vous comprenez le cadre interne, plus vous serez heureux à long terme. Pas vraiment Rails spécifique dans ce domaine, mais je vous dis simplement par expérience ici. Les noms de méthode promettent parfois quelque chose que vous n'obtenez pas réellement.

• Le culte du fret est un problème avec Rails, mais c'est probablement vrai avec toutes les communautés framework / lang. Il semble plus prononcé (pour moi) dans Rails, et en tant que tel tend à donner un aspect générationnel étrange au code Rails - lorsque vous travaillez sur différents projets Rails, vous remarquerez certaines tendances qui tendent à trahir la période de temps pendant laquelle ils ont été créés . Comme vous pouvez le deviner à partir de cette déclaration, la communauté a tendance à adopter assez rapidement de nouvelles solutions et à déconseiller les anciennes. Vous devriez vraiment être au courant de votre actualité Ruby, juste pour comprendre une partie du code que vous expérimenterez quotidiennement.

• De manière générale, je pense que le problème de la simultanéité des données n'est généralement pas bien traité par la communauté - lorsque vous développez une application, lorsque vous atteignez le point où vous devez partager des données, annuler des modifications physiquement à distance et verrouiller l'accès aux données, les solutions deviennent un peu plus réglé à la main, ce qui rend certaines des belles choses Rails que vous obtenez tout brouillées avec les nécessités techniques de la précision. Rails ne résout pas tous les problèmes que vous rencontrez avec une application Web, je suppose que je le dis, et bien que les créateurs ne prêchent certainement pas ce message, il est facile d'être dupe de penser qu'il est implicite.

Selon la façon dont vous le regardez, la vitesse à laquelle Rails change peut ou non être une mise en garde pour vous. Les choses changent quelque peu radicalement d'année en année, car de plus en plus de ce qui craint et a besoin de solutions.

Si vous êtes en développement actif, vous aurez cependant le doigt sur le pouls.