Ruby on Rails Nachteile und Vorbehalte [geschlossen]

Dies ist kein Eröffnungsgambit für RoR-Bashing - ehrlich!

Ich lerne Ruby und das Rails-Framework. Auf den ersten Blick scheint es ziemlich cool zu sein und eine wunderbare Erfahrung im Vergleich zu PHP. (Tatsächlich erinnert es mich an glücklichere Tage mit C # und .NET.)

Ich habe jedoch keine Erfahrung mit diesem Framework oder dieser Sprache und bin neugierig - was sind die aktuellen Nachteile oder Dinge, die Sie zu Beginn gerne gewusst hätten?

(Vielleicht sollte dies ein Community-Wiki gemacht werden?)

Dies ist aus Erfahrung gelernt, weiter zu lernen und eine relativ einfache Anwendung in Rails zu schreiben.

1) Lernkurve

Rails ist täuschend einfach. Die Tutorials, Videos und Bücher zeigen, wie schnell Sie eine funktionierende (wenn auch hässliche) Anwendung erstellen können, aber diese kratzen wirklich nur die Oberfläche. Sie verlassen sich in der Regel stark auf die Codegenerierung und das "Scaffolding", was zwar ein gutes Werkzeug beim Lernen ist, dessen Nützlichkeit jedoch schnell überlebt.

Machen Sie keinen Fehler, Rails ist schwer zu meistern. Sobald Sie die Grundlagen überwunden haben (dazu später mehr), stoßen Sie kopfüber auf eine Mauer, wenn Sie mehr tun müssen als nur die extrem vereinfachte "Demo-App" -Funktionalität, die Sie ankündigen. Sie können mit Grundkenntnissen in Ruby auskommen, während Sie lernen, aber Sie müssen Ruby schnell erlernen, oder Sie bleiben hoch und trocken (und nicht die gute Art von DRY), wenn Sie die Einschränkungen von Rails überschreiten müssen.

Rails ist, wie ich es liebevoll nenne, Malen durch Zahlenprogrammierung . Wenn Sie sich zu 100% an die Konventionen halten (dh innerhalb der Linien bleiben und die Farben verwenden, die Sie verwenden sollen), können Sie schnell und einfach anständige Anwendungen erstellen. Wenn Sie jedoch abweichen müssen, kann Rails von Ihrem besten Freund zu Ihrem schlimmsten Feind werden.

2) Wenn alles, was Sie haben, ein Hammer ist ...

Rails kann sehr gut vereinfachte CRUD-Anwendungen ausführen. Das Problem tritt auf, wenn Ihre App mehr als nur Lesen / Schreiben aus einer Datenbank ausführen muss. Nun, die letzte Rails-Version, die ich verwendet habe, war 2.3.4, also haben sich die Dinge seitdem möglicherweise geändert, aber ich hatte große Probleme, als sich die Geschäftsanforderungen änderten, sodass in die Anwendung ein kleines Workflow-System eingebaut und integriert werden musste eine ältere PHP-Anwendung. Die Rails-Konvention "One Form, One Model" eignet sich gut für einfache Apps und Dateneingabeanwendungen, jedoch nicht für Anwendungen, bei denen Verarbeitungslogik erforderlich ist, Workflows vorhanden sind oder bei denen der Benutzer keine typischen Daten eingibt ein paar Textfelder, drücke "Submit". Es kann getan werden, aber es ist keineswegs "einfach", oder vielmehr war es nicht

Rails spielt auch nicht gerne gut mit anderen Anwendungen, die nicht die bevorzugten Methoden für den Datenzugriff verwenden. Wenn Sie mit einer Anwendung kommunizieren müssen, die keine API im "Web 2.0" -Stil hat, müssen Sie Rails umgehen, anstatt damit zu arbeiten. Ich spreche hier wieder aus Erfahrung, denn das ist mir passiert.

3) Es ist neu

Schließlich ist Rails in vielen Bereichen immer noch das "neue Kind auf dem Block". Dies spielt keine Rolle für den persönlichen Gebrauch oder für Szenarien wie "Ich denke, es ist cool und möchte es lernen", sondern für jemanden, der Rails bei meiner täglichen Arbeit bevorzugt, wenn Sie sich nicht an einem Ort befinden, an dem Rails ist Weit verbreitet, kann es sehr schwierig sein, eine Vollzeitstelle als Rails-Entwickler zu finden. Es ist immer noch weitgehend die Domäne von "angesagten, neuen Startups" und in den meisten Ballungsräumen kein Hauptakteur. Ihr Kilometerstand kann in dieser Hinsicht variieren, aber ich weiß, dass meine Gebietsschienen (Tampa) im Wesentlichen nicht vorhanden sind.

4) Feuer und Bewegung

Die Schienen ändern sich ständig. Dies ist sowohl eine gute als auch eine schlechte Sache. Es ist gut, weil sich die Community weiterentwickelt und neue Konzepte annimmt. Es ist schlecht, weil sich die Community weiterentwickelt und neue Konzepte annimmt. Es kann für einen Rails-Neuling sehr überwältigend sein, denn normalerweise werden Sie feststellen, wenn Sie auf ein Problem stoßen und sich umsehen, dass entweder Leute das eine oder andere Juwel empfehlen, um es zu beheben, oder Sie sagen, dass dieser Weg sowieso schlecht ist, und Sie sollten es nicht. Wenn Sie es nicht verwenden, haben Sie hier eine bessere Möglichkeit ... und am Ende haben Sie eine Wäscheliste mit zusätzlichen Tools, die Sie zusammen mit Rails lernen können, um mit den Rails-Erkenntnissen Schritt zu halten. Dinge wie Git, BDD/RSpec, Cucumber,Haml/Sassund ein Füllhorn an anderen Dingen schwebt herum und wird als der "richtige Weg, Dinge zu tun" in Rails-Land gedrängt, und wenn man aus Erfahrung spricht, könnte man überfordert sein, ein Dutzend oder mehr Technologien zusätzlich zu Rails zu lernen. weil sich die Verwendung des Standard Rails-Toolkits "falsch" anfühlt.

Dies wird jetzt durch Rails 3.1 noch verstärkt, wodurch Sass und CoffeeScript zum Standard werden. Ein absoluter Rails-Neuling muss also nicht nur Ruby und Rails lernen, sondern auch Sass (wohl einfach, wenn Sie CSS kennen) und CoffeeScript (nicht verrückt schwierig, aber sicher) unterschiedlich genug von rohen JavaScript) auf ein absolutes Minimum zu beginnen, und es kann davon ausgegangen werden Git. Auch ohne RSpec und Freunde und das Dutzend oder mehr Juwelen, mit denen Sie normalerweise enden, müssen Sie vier verschiedene Dinge lernen, bevor Sie ernsthaft mit dem Schreiben von Rails-Anwendungen beginnen können. Vergleichen Sie dies mit einer Sprache wie C # oder Java oder sogar PHP, in der sich Ihre HTML- / CSS- / JavaScript- / SQL-Kenntnisse nicht ändern werden und Sie nur die Sprache selbst und möglicherweise die Framework-Nuancen lernen müssen.

Dokumentation.

Während Rails-Handbücher eine hervorragende Lernressource darstellen, ist die Navigation in der Rails-Bibliothek (und allgemein in Ruby) nicht einfach. Angenommen, Sie möchten mehr über die belongs_toMethode erfahren . Obwohl es für ActiveRecord::BaseUnterklassen (eigene Modelle) verwendet wird, ist es nicht in Dokumenten dokumentiert ActiveRecord::Base, sondern in einem Mixin , das von der Klasse importiert wird. Im Wesentlichen können Sie keine umfassende Liste aller Methoden anzeigen, die Sie an einem Objekt an einem Ort verwenden können (außer wenn Sie irbdas Objekt selbst starten und überprüfen).

Bei einer hochdynamischen Sprache wie Ruby ist es nicht einfach festzustellen, woher eine von Ihnen verwendete Methode stammt. Dies kann ein Problem sein, insbesondere für Programmierer, die versuchen, sich einen Überblick über einen neuen Technologie-Stack zu verschaffen.

Ruby on Rails hat eine signifikante Lernkurve. Zuerst musst du die Kuriositäten der Sprache lernen, dann das Framework, dann die Rails-Methode und dann die vielen häufig verwendeten Gems.

Wenn Sie diese Dinge jedoch gelernt haben, kommt es unglaublich natürlich. Tatsächlich fühlen sich andere Frameworks wie eine Bürde an.

Rails ist sehr TDD / BDD-orientiert. Wenn Sie es nicht sind, müssen Sie zwei weitere Dinge lernen, bevor Sie ein kompetenter Rails-Programmierer werden. Sie haben keinen Compiler und keine IDEs, die Sie sichern könnten. Daher ist die Testabdeckung in hohem Maße Ihr Fallback.

Viele Befürworter von TDD, auch ich, würden dies als eine der Stärken von RoR und dessen Fluch ansehen. Sobald Sie mit dem Schreiben von TDD beginnen, stellen Sie fest, dass die durch die Testabdeckung gebotene Sicherheit besser ist als die durch einen Compiler gebotene Sicherheit. Dann wird das Schreiben von Code NUR, um einen Compiler zufrieden zu stellen, belastend.

TDD fühlt sich in RoR nicht als zusätzliche Aufgabe an, sondern als der einzige Weg, um zu arbeiten.

Rails hat ein schwerwiegendes Leistungsproblem: Jede Anfrage befindet sich in der Warteschlange hinter der derzeit aktiven, anstatt sie wie die meisten Frameworks zu verteilen oder zuzulassen, dass blockierende Ereignisse andere Anfragen freigeben, wie dies bei Node.js und Twister der Fall ist. Das bedeutet, Sie müssen Code eingeben, um die Antwortzeiten zu verkürzen. In den meisten Fällen ist dies jedoch recht einfach.

Rails ist auch sehr darauf ausgelegt, Content-Systeme sehr gut zu handhaben, was fairerweise viel mit dem Internet zu tun hat. Etwas komplizierter zu machen, wie ein Web-Spiel oder ein E-Commerce-System, bedeutet, neue Juwelen zu lernen. Man lernt schnell, dass alle Edelsteine ​​da draußen sind, aber je dunkler die Sache ist, die man machen möchte, desto schwieriger wird es, eine gute Dokumentation zu finden.

Nach meiner persönlichen Erfahrung liegt der Hauptschmerz in der Kompatibilität .

Wann:

• Es sind xSchienenprojekte im Einsatz.
• Jedes Projekt verwendet yEdelsteine.
• während es nVersionen von Schienen gibt,
• Plus- mVersionen von Edelsteinen installiert,
• mit severalVersionen von Rubin,
• auf einer einzigen Linux-Box als Produktionsmaschine.
• Der Programmierer arbeitet an einem anderen OS X-Entwicklungsnotizbuch.

Als Freiberufler, die nicht den Luxus zu aktualisieren hat / die meisten Dinge aktualisieren, wird eine Menge Gesicht Kompatibilitätsprobleme von oben Variablen ... während rails, gemsund rubyändern sich ständig / weiterentwickelt.

Geschwindigkeit ist definitiv ein Problem. Rubys extreme Flexibilität bringt einen deutlichen Leistungseinbruch mit sich.

Horizontales Skalieren ist eine nicht offensichtliche Aufgabe, mit Ausnahme von Technologien, die speziell für diese Aufgabe entwickelt wurden und in der Regel die Einfachheit einer guten Skalierung in Kauf nehmen.
Wenn Sie mit Technologie A 100-mal so viele Anforderungen pro Computer verarbeiten können wie mit Technologie B, ist die Verwendung von Technologie A eine Überlegung wert, wenn Sie Grund zur Annahme haben, dass Sie Ihre Daten für einen Zeitraum von einem einzelnen Server aus bereitstellen können, der Ihnen das Hinzufügen von Daten ermöglicht Parallelisierung danach.
Im Jahr 2009 wurde stackoverflow noch von einem Webserver aus bedient . Dies ist natürlich keine Option mehr. Aber ich nehme an, es war gut, dass sie mit einer Technologie angefangen haben, mit der sich viele Benutzer auf einer einzelnen Instanz skalieren lassen, bevor sie sich um die Skalierung kümmern mussten.

Im Vergleich dazu ist RoR sehr langsam. Der Zeitaufwand für die Bearbeitung einfacher Anforderungen ist erheblich und daher ist die Bearbeitung vieler Clients problematisch (dies ist alles in Bezug auf schnellere Alternativen zu sehen).

Der vagen Orientierung halber hier einige Zahlen, die verschiedene andere für die Webentwicklung geeignete Sprachen mit Ruby vergleichen:

• Gehen
• Clojure
• JavaScript V8 ( node.js )
• JRuby (eine nicht zu vergessende Alternative - abhängig von Ihrem Problembereich kann JRuby eine bessere oder schlechtere Wahl sein, um etwas Geschwindigkeit aus einer Rails-App herauszuholen)
• Scala
• Java
• C #

Beachten Sie, dass dies nicht bedeutet, dass Framework X für Java genau 200-mal schneller ist als RoR. Der in diesen Benchmarks gemessene Geschwindigkeitsunterschied hat jedoch einen wichtigen Einfluss auf die Gesamtleistung Ihrer App.

Rails hat ein schwerwiegendes Leistungsproblem: Jede Anfrage befindet sich in der Warteschlange hinter der derzeit aktiven, anstatt sie wie die meisten Frameworks zu verteilen oder zuzulassen, dass blockierende Ereignisse andere Anfragen freigeben, wie dies bei Node.js und Twister der Fall ist. Das bedeutet, Sie müssen Code eingeben, um die Antwortzeiten zu verkürzen. In den meisten Fällen ist dies jedoch recht einfach.

Ich denke, das ist sehr falsch. Sie können Rails im Multithread-Modus ausführen. Wenn Sie im Multithread-Modus arbeiten, sollten Sie nur E / A-Bibliotheken verwenden, die die GIL-Datei freigeben (z. B. 'mysql2' gem), da sie sonst irgendwie sinnlos wird.

Wenn Sie jRuby verwenden, können Sie einfach einen Single-Rails-Prozess im Multithread-Modus ausführen und die gesamte verfügbare CPU-Leistung nutzen. Wenn Sie sich jedoch in MRT (Ruby 1.8.x oder 1.9.x) befinden, müssen Sie mehrere Prozesse ausführen, um die CPUs voll auszunutzen, was auch bei node.js der Fall ist.

• Rails hat viele Feinheiten, die die Komplexität vor Ihnen verbergen. (ActiveRecord-Verknüpfungen, der gesamte Validierungs- / Speicherlebenszyklus, die Interpretation von Anforderungsdaten basierend auf bereitgestellten Headern) Wenn Sie gerade erst anfangen, ist dies fantastisch. Wenn Sie wachsen, werden Sie feststellen, dass Sie beginnen, Ihre App an die Art und Weise anzupassen, wie Sie mit den Dingen umgehen. Manchmal ist dies gut, manchmal ist es harmlos, und manchmal widerspricht es tatsächlich der Intuition, die Sie zu tun versuchen. Nicht alle Datenbanktabellen sollten als Objekte modelliert werden. Möglicherweise muss ein Validierungsschritt an einer anderen Stelle durchgeführt werden. Viele Rails-Programmierer meiden es, das Framework nicht zu bekämpfen (was normalerweise sinnvoll ist), aber der langfristige Effekt davon liegt bei Ihnen wird die Gewohnheiten von Rails an Orte mitnehmen, an denen sie nicht unbedingt erforderlich sind.

• Die Community hat die Angewohnheit, Software zu schreiben, die als "Magie" bezeichnet wird - Libs zwischenspeichern, die auf magische Weise funktionieren! Evented I / O, das Sie magisch schneller macht! Magie Magie! In der Regel wird hier eine sehr attraktive API für eine fehlende technische Lösung bereitgestellt, und Sie werden von den sehr hübschen Beispielen getäuscht, dass das Ding das tut, was Sie beabsichtigen, und erst später feststellen, dass es eine unvollständige Lösung abdeckt. Der Zyklus ist ziemlich konstant, und Sie lernen, damit zu rollen, aber Sie sollten sich auf jeden Fall mit der Idee vertraut machen, sehr viel Code zu lesen, von dem Sie abhängen (eine gute Sache!). Rails Community Magic-Lösungen sind bei weitem nicht so magisch, wie es die README-Datei vermuten lässt.

• Fazit: Je öfter Sie Rails verwenden, desto mehr sollten Sie dessen Quelle lesen. Je besser Sie die internen Rahmenbedingungen verstehen, desto glücklicher werden Sie langfristig sein. Nicht wirklich Rails-spezifisch, aber ich erzähle Ihnen nur aus Erfahrung hier. Methodennamen versprechen manchmal etwas, das Sie nicht wirklich bekommen.

• Frachtkultismus ist ein Problem mit Rails, aber das trifft wahrscheinlich auf alle Framework / Lang-Communities zu. Es scheint (für mich) in Rails ausgeprägter zu sein und verleiht dem Rails-Code daher tendenziell einen seltsamen generativen Look. Wenn Sie an verschiedenen Rails-Projekten arbeiten, werden Sie bestimmte Tendenzen bemerken, die tendenziell den Zeitraum verraten, in dem sie erstellt wurden . Wie Sie aus dieser Aussage ersehen können, tendiert die Community dazu, neue Lösungen schnell zu übernehmen und alte zu verwerfen. Sie sollten sich wirklich über Ihre Ruby-Nachrichten auf dem Laufenden halten, nur um einen Teil des Codes zu verstehen, den Sie täglich erleben werden.

• Generell denke ich, dass das Problem der Datengleichzeitigkeit von der Community in der Regel nicht gut angesprochen wird. Wenn Sie eine App erweitern und den Punkt erreichen, an dem Sie Daten speichern, physisch entfernte Änderungen rückgängig machen und den Zugriff auf Daten sperren müssen, werden die Lösungen ein bisschen mehr Handarbeit, wodurch einige der gut aussehenden Rails-Dinge, die Sie tun, mit den technischen Notwendigkeiten der Genauigkeit durcheinander gebracht werden. Rails löst nicht jedes Problem, das Sie mit einer Web-App haben, und obwohl die Macher diese Botschaft mit Sicherheit nicht predigen, ist es leicht zu glauben, dass sie impliziert ist.

Je nachdem, wie Sie es sehen, kann die Geschwindigkeit, mit der sich Rails ändert, ein Nachteil für Sie sein oder auch nicht. Die Dinge ändern sich von Jahr zu Jahr ein wenig radikal.

Wenn Sie sich in der aktiven Entwicklung befinden, sind Sie jedoch immer am Puls der Zeit.