Ruby on Rails est peut-être le framework de développement web le plus apprécié. Il y a des tas de raisons à cela, mais chaque cadre, même le meilleur de son genre, a ses inconvénients. Je voudrais connaître les problèmes les plus courants que vous rencontrez lorsque vous développez des applications Ruby on Rails et les problèmes avec lesquels vous avez souvent des problèmes.Ruby on Rails Inconvénients
Comme toute technologie, il y a une courbe d'apprentissage. Mais en tant que cadre relativement nouveau, DHH et al, ont pu «se tenir sur les épaules des géants» (prédécesseurs) et ont produit un grand cadre.
J'ai été très heureux de choisir Rails comme cadre de travail pour mon commerce.
Inconvénients? Pas autant de bibliothèques que d'anciens frameworks tels que Java et Perl. - Mais il y a des façons de contourner ce problème. Par exemple, appelez ces bibliothèques à partir de Rails ou portez-les.
La performance est généralement mentionnée dans la catégorie des inconvénients, mais le matériel moins cher et les améliorations apportées aux versions ultérieures des rails en ont tenu compte. Pareil avec "stabilité".
Les mises à jour fréquentes de la structure rendent difficile la mise à jour de votre application - les mises à niveau peuvent se faire dans des endroits obscurs. MonkeyPatching - peut causer de sérieux problèmes pour toute personne qui doit maintenir une grande base de code sur une longue période de temps. Performance/Puissance - Facile à prendre soi-même dans le pied avec des requêtes de base de données consommatrices de mémoire en utilisant des itérateurs Ruby avec ActiveRecord.
Mais je vais le prendre sur Java ou PHP un jour
Je ne suis pas ravie de l'utilisation de Rails de variables globales pour tout. Les classes de modèles trouvent la connexion à la base de données via une variable globale (ActiveRecord::Base.connection), la classe Rails est un point d'accès global pour des choses comme l'enregistreur, l'environnement actuel, pour la mise en cache, etc. ActionMailer fait des variables globales de vos expéditeurs, et etc., etc. Rails est construit autour de l'utilisation de variables globales, de sorte que, quoi que vous fassiez, à n'importe quel niveau de l'application, vous pouvez toujours atteindre une variable globale.
Cela rend les tests moche. Si Rails était construit sur Java, cela rendrait les tests vraiment très difficiles, mais comme c'est Ruby, ça devient moche. Les tests doivent éliminer un grand nombre de contextes globaux afin de fonctionner de manière isolée, ce qui peut facilement rendre les tests absurdes. Il n'est pas rare de voir cinq ou dix lignes de code qui remplacent différentes variables globales, suivies d'une ou deux lignes de test. Ce n'est pas que cinq ou dix lignes de configuration pour un test sont un problème, mais sans lire le code sous test, vous ne pouvez pas facilement voir quel impact l'état global aura, et comment il est important. Cela rend de nombreux tests inutilement laids. Je trouve un peu ironique que la communauté Rails soit le plus expérimenté de tous ceux dont j'ai fait partie. Après avoir dit que je ne échangerais pas Rails pour tout ce qui est actuellement disponible. La vitesse à laquelle vous pouvez faire avancer les choses, et le grand nombre de plugins et de gemmes qui supprime tout le travail fastidieux me souffle tous les jours.
Pour les applications multithreads, les threads Ruby sont appelés des threads verts, qui ne sont pas des threads de niveau OS. Cela ne peut pas fournir de véritable multithreading.