Fehlerhafter Rails-Code: Die 10 häufigsten Fehler, die Rails-Entwickler machen

Ruby on Rails („Rails“) ist ein beliebtes Open-Source-Framework, das auf der Programmiersprache Ruby basiert und darauf abzielt, den Entwicklungsprozess von Webanwendungen zu vereinfachen und zu rationalisieren.

Rails basiert auf dem Prinzip Konvention über Konfiguration. Einfach ausgedrückt bedeutet dies, dass Rails standardmäßig davon ausgeht, dass seine erfahrenen Entwickler „Standard“-Best-Practice-Konventionen (für Dinge wie Benennung, Codestruktur usw.) befolgen, und wenn Sie dies tun, werden die Dinge für Sie „automatisch“ funktionieren -magically“, ohne dass Sie diese Details angeben müssen. Während dieses Paradigma seine Vorteile hat, ist es auch nicht ohne Fallstricke. Vor allem die „Magie“, die hinter den Kulissen des Frameworks passiert, kann manchmal zu Headfakes, Verwirrung und „Was zum Teufel ist los?“ führen. Arten von Problemen. Es kann auch unerwünschte Auswirkungen auf Sicherheit und Leistung haben.

Dementsprechend ist Rails zwar einfach zu bedienen, aber auch nicht schwer zu missbrauchen. Dieses Tutorial befasst sich mit 10 häufigen Rails-Problemen, einschließlich ihrer Vermeidung und der Probleme, die sie verursachen.

Häufiger Fehler Nr. 1: Zu viel Logik in den Controller stecken

Rails basiert auf einer MVC-Architektur. In der Rails-Community sprechen wir schon seit einiger Zeit über Fat Model, Skinny Controller, aber einige neuere Rails-Anwendungen, die ich geerbt habe, haben gegen dieses Prinzip verstoßen. Es ist allzu einfach, Ansichtslogik (die besser in einem Helfer untergebracht ist) oder Domänen-/Modelllogik in den Controller zu verschieben.

Das Problem besteht darin, dass das Controller-Objekt beginnt, gegen das Prinzip der Einzelverantwortung zu verstoßen, was zukünftige Änderungen an der Codebasis schwierig und fehleranfällig macht. Im Allgemeinen sind die einzigen Arten von Logik, die Sie in Ihrem Controller haben sollten, die folgenden:

• Sitzungs- und Cookie-Handhabung. Dies kann auch die Authentifizierung/Autorisierung oder jede zusätzliche Cookie-Verarbeitung umfassen, die Sie durchführen müssen.
• Modellauswahl. Logik zum Finden des richtigen Modellobjekts anhand der von der Anforderung übergebenen Parameter. Idealerweise sollte dies ein Aufruf einer einzelnen find-Methode sein, die eine Instanzvariable festlegt, die später zum Rendern der Antwort verwendet wird.
• Parameterverwaltung anfordern. Anforderungsparameter sammeln und eine geeignete Modellmethode aufrufen, um sie beizubehalten.
• Rendern/Umleiten. Rendern des Ergebnisses (HTML, XML, JSON usw.) oder Umleiten, je nach Bedarf.

Während dies immer noch die Grenzen des Prinzips der Einzelverantwortung überschreitet, ist es so etwas wie das absolute Minimum, das das Rails-Framework von uns im Controller verlangt.

Häufiger Fehler Nr. 2: Zu viel Logik in die Ansicht einbauen

Die sofort einsatzbereite Rails-Template-Engine ERB ist eine großartige Möglichkeit, Seiten mit variablem Inhalt zu erstellen. Wenn Sie jedoch nicht aufpassen, können Sie bald mit einer großen Datei enden, die eine Mischung aus HTML- und Ruby-Code ist, die schwierig zu verwalten und zu warten ist. Dies ist auch ein Bereich, der zu vielen Wiederholungen führen kann, was zu Verletzungen der DRY-Prinzipien (Don't Repeat Yourself) führt.

Dies kann sich auf verschiedene Weise äußern. Einer ist der übermäßige Gebrauch von bedingter Logik in Ansichten. Betrachten Sie als einfaches Beispiel einen Fall, in dem wir eine Methode current_user zur Verfügung haben, die den aktuell angemeldeten Benutzer zurückgibt. Häufig kommt es in Ansichtsdateien zu bedingten Logikstrukturen wie dieser:

 <h3> Welcome, <% if current_user %> <%= current_user.name %> <% else %> Guest <% end %> </h3>

Ein besserer Weg, so etwas zu handhaben, besteht darin, sicherzustellen, dass das von current_user zurückgegebene Objekt immer gesetzt ist, unabhängig davon, ob jemand angemeldet ist oder nicht, und dass es die in der Ansicht verwendeten Methoden auf angemessene Weise beantwortet (manchmal als null bezeichnet Objekt). Beispielsweise könnten Sie den current_user Hilfsdienst in app/controllers/application_controller wie folgt definieren:

 require 'ostruct' helper_method :current_user def current_user @current_user ||= User.find session[:user_id] if session[:user_id] if @current_user @current_user else OpenStruct.new(name: 'Guest') end end

Dies würde es Ihnen dann ermöglichen, das vorherige Ansichtscodebeispiel durch diese eine einfache Codezeile zu ersetzen:

 <h3>Welcome, <%= current_user.name -%></h3>

Einige weitere empfohlene Best Practices für Rails:

• Verwenden Sie Ansichtslayouts und Partials angemessen, um Dinge zu kapseln, die sich auf Ihren Seiten wiederholen.
• Verwenden Sie Presenter/Decorators wie das Draper-Gem, um die View-Building-Logik in einem Ruby-Objekt zu kapseln. Sie können diesem Objekt dann Methoden hinzufügen, um logische Operationen auszuführen, die Sie andernfalls möglicherweise in Ihren Ansichtscode eingefügt hätten.

Häufiger Fehler Nr. 3: Zu viel Logik in das Modell einbauen

Angesichts der Anleitung zur Minimierung der Logik in Ansichten und Controllern wäre der einzige Platz, der in einer MVC-Architektur übrig bleibt, um all diese Logik unterzubringen, die Modelle, richtig?

Nicht ganz.

Viele Rails-Entwickler machen tatsächlich diesen Fehler und stecken am Ende alles in ihre ActiveRecord -Modellklassen, was zu Mongo-Dateien führt, die nicht nur gegen das Prinzip der Einzelverantwortung verstoßen, sondern auch ein Albtraum für die Wartung sind.

Funktionen wie das Generieren von E-Mail-Benachrichtigungen, die Anbindung an externe Dienste, die Konvertierung in andere Datenformate und dergleichen haben nicht viel mit der Kernaufgabe eines ActiveRecord -Modells zu tun, das kaum mehr tun sollte, als Daten in einer Datenbank zu finden und zu speichern.

Wenn also die Logik nicht in die Ansichten und nicht in die Controller und nicht in die Modelle aufgenommen werden sollte, wo sollte sie dann hin?

Geben Sie einfache alte Ruby-Objekte (POROs) ein. Bei einem umfassenden Framework wie Rails zögern neuere Entwickler oft, ihre eigenen Klassen außerhalb des Frameworks zu erstellen. Das Verschieben von Logik aus dem Modell in POROs ist jedoch oft genau das, was der Arzt angeordnet hat, um übermäßig komplexe Modelle zu vermeiden. Mit POROs können Sie Dinge wie E-Mail-Benachrichtigungen oder API-Interaktionen in ihre eigenen Klassen kapseln, anstatt sie in ein ActiveRecord -Modell zu stecken.

In Anbetracht dessen sollte im Allgemeinen die einzige Logik, die in Ihrem Modell verbleiben sollte, folgende sein:

• ActiveRecord Konfiguration (d. h. Beziehungen und Validierungen)
• Einfache Mutationsmethoden , um eine Handvoll Attribute zu aktualisieren und in der Datenbank zu speichern
• Greifen Sie auf Wrapper zu, um interne Modellinformationen zu verbergen (z. B. eine full_name Methode, die first_name und last_name Felder in der Datenbank kombiniert)
• Anspruchsvolle Abfragen (dh die komplexer sind als eine einfache find ); Im Allgemeinen sollten Sie niemals die where -Methode oder ähnliche Abfrageerstellungsmethoden außerhalb der Modellklasse selbst verwenden

Häufiger Fehler Nr. 4: Verwenden von generischen Hilfsklassen als Müllhalde

Dieser Fehler ist wirklich eine Folge von Fehler Nr. 3 oben. Wie bereits erwähnt, legt das Rails-Framework den Schwerpunkt auf die benannten Komponenten (dh Model, View und Controller) eines MVC-Frameworks. Es gibt ziemlich gute Definitionen der Dinge, die in die Klassen jeder dieser Komponenten gehören, aber manchmal brauchen wir vielleicht Methoden, die in keine der drei zu passen scheinen.

Rails-Generatoren erstellen bequem ein Hilfsverzeichnis und eine neue Hilfsklasse für jede neue Ressource, die wir erstellen. Es wird jedoch allzu verlockend, jede Funktionalität, die formal nicht in das Modell, die Ansicht oder den Controller passt, in diese Hilfsklassen zu stopfen.

Während Rails sicherlich MVC-zentriert ist, hindert Sie nichts daran, Ihre eigenen Klassentypen zu erstellen und geeignete Verzeichnisse hinzuzufügen, um den Code für diese Klassen zu speichern. Wenn Sie über zusätzliche Funktionalität verfügen, denken Sie darüber nach, welche Methoden gruppiert werden, und finden Sie gute Namen für die Klassen, die diese Methoden enthalten. Die Verwendung eines umfassenden Frameworks wie Rails ist keine Entschuldigung dafür, gute Best Practices für objektorientiertes Design auf der Strecke zu lassen.

Häufiger Fehler Nr. 5: Zu viele Edelsteine ​​verwenden

Ruby und Rails werden von einem reichhaltigen Ökosystem aus Edelsteinen unterstützt, die zusammengenommen so ziemlich jede Fähigkeit bieten, die sich ein Entwickler vorstellen kann. Dies ist großartig, um schnell eine komplexe Anwendung aufzubauen, aber ich habe auch viele aufgeblähte Anwendungen gesehen, bei denen die Anzahl der Edelsteine ​​​​in der Gemfile der Anwendung im Vergleich zur bereitgestellten Funktionalität unverhältnismäßig groß ist.

Dies verursacht mehrere Rails-Probleme. Die übermäßige Verwendung von Edelsteinen macht die Größe eines Rails-Prozesses größer als nötig. Dies kann die Leistung in der Produktion verlangsamen. Neben der Frustration der Benutzer kann dies auch dazu führen, dass größere Serverspeicherkonfigurationen und höhere Betriebskosten erforderlich sind. Außerdem dauert es länger, größere Rails-Anwendungen zu starten, wodurch die Entwicklung langsamer wird und automatisierte Tests länger dauern (und in der Regel werden langsame Tests einfach nicht so oft ausgeführt).

Denken Sie daran, dass jeder Edelstein, den Sie in Ihre Anwendung einbringen, wiederum Abhängigkeiten von anderen Edelsteinen haben kann, und diese wiederum Abhängigkeiten von anderen Edelsteinen haben können und so weiter. Das Hinzufügen anderer Edelsteine ​​​​kann daher einen zusammengesetzten Effekt haben. Wenn Sie beispielsweise das gem rails_admin hinzufügen, werden insgesamt 11 weitere gems hinzugefügt, was einer Steigerung von über 10 % gegenüber der grundlegenden Rails-Installation entspricht.

Zum jetzigen Zeitpunkt enthält eine frische Installation von Rails 4.1.0 43 Gems in der Datei Gemfile.lock . Dies ist offensichtlich mehr als in Gemfile enthalten ist und stellt alle Edelsteine ​​dar, die die Handvoll Standard-Rails-Gems als Abhängigkeiten einbringen.

Überlegen Sie sorgfältig, ob sich der zusätzliche Overhead lohnt, wenn Sie jeden Edelstein hinzufügen. Als Beispiel fügen Entwickler oft beiläufig das Juwel rails_admin hinzu, weil es im Wesentlichen ein nettes Web-Frontend für die Modellstruktur bereitstellt, aber es ist wirklich nicht viel mehr als ein schickes Datenbank-Browsing-Tool. Selbst wenn Ihre Anwendung Admin-Benutzer mit zusätzlichen Rechten erfordert, möchten Sie ihnen wahrscheinlich keinen direkten Datenbankzugriff gewähren, und Sie wären besser bedient, wenn Sie Ihre eigene, schlankere Verwaltungsfunktion entwickeln, als dieses Juwel hinzuzufügen.

Häufiger Fehler Nr. 6: Ignorieren Ihrer Protokolldateien

Während die meisten Rails-Entwickler die während der Entwicklung und Produktion verfügbaren Standardprotokolldateien kennen, schenken sie den Informationen in diesen Dateien oft nicht genügend Aufmerksamkeit. Während viele Anwendungen in der Produktion auf Protokollüberwachungstools wie Honeybadger oder New Relic angewiesen sind, ist es auch wichtig, Ihre Protokolldateien während des gesamten Prozesses der Entwicklung und des Testens Ihrer Anwendung im Auge zu behalten.

Wie bereits in diesem Tutorial erwähnt, macht das Rails-Framework viel „Magie“ für Sie, insbesondere in den Modellen. Das Definieren von Assoziationen in Ihren Modellen macht es sehr einfach, Beziehungen einzuziehen und alles für Ihre Ansichten verfügbar zu machen. Das gesamte SQL, das zum Füllen Ihrer Modellobjekte benötigt wird, wird für Sie generiert. Das ist großartig. Aber woher wissen Sie, dass das generierte SQL effizient ist?

Ein Beispiel, auf das Sie oft stoßen werden, ist das sogenannte N+1-Abfrageproblem. Obwohl das Problem gut verstanden wird, besteht die einzige wirkliche Möglichkeit, es zu beobachten, darin, die SQL-Abfragen in Ihren Protokolldateien zu überprüfen.

Angenommen, Sie haben die folgende Abfrage in einer typischen Bloganwendung, in der Sie alle Kommentare für eine ausgewählte Gruppe von Posts anzeigen:

 def comments_for_top_three_posts posts = Post.limit(3) posts.flat_map do |post| post.comments.to_a end end

Wenn wir uns die Protokolldatei einer Anfrage ansehen, die diese Methode aufruft, sehen wir etwas wie das Folgende, wo eine einzelne Abfrage durchgeführt wird, um die drei Post-Objekte abzurufen, und dann drei weitere Abfragen durchgeführt werden, um die Kommentare jedes dieser Objekte abzurufen:

 Started GET "/posts/some_comments" for 127.0.0.1 at 2014-05-20 20:05:13 -0700 Processing by PostsController#some_comments as HTML Post Load (0.4ms) SELECT "posts".* FROM "posts" LIMIT 3 Comment Load (5.6ms) ELECT "comments".* FROM "comments" WHERE "comments"."post_id" = ? [["post_id", 1]] Comment Load (0.4ms) SELECT "comments".* FROM "comments" WHERE "comments"."post_id" = ? [["post_id", 2]] Comment Load (1.5ms) SELECT "comments".* FROM "comments" WHERE "comments"."post_id" = ? [["post_id", 3]] Rendered posts/some_comments.html.erb within layouts/application (12.5ms) Completed 200 OK in 581ms (Views: 225.8ms | ActiveRecord: 10.0ms)

Die Eager-Loading-Funktion von ActiveRecord in Rails ermöglicht es, die Anzahl der Abfragen erheblich zu reduzieren, indem Sie alle zu ladenden Assoziationen im Voraus angeben können. Dies erfolgt durch Aufrufen der Methode " includes " (oder " preload ") für das zu erstellende Arel-Objekt ( ActiveRecord::Relation ). Mit includes stellt ActiveRecord sicher, dass alle angegebenen Assoziationen mit der minimal möglichen Anzahl von Abfragen geladen werden; z.B:

 def comments_for_top_three_posts posts = Post.includes(:comments).limit(3) posts.flat_map do |post| post.comments.to_a end end

Wenn der obige überarbeitete Code ausgeführt wird, sehen wir in der Protokolldatei, dass alle Kommentare in einer einzigen Abfrage statt in drei gesammelt wurden:

 Started GET "/posts/some_comments" for 127.0.0.1 at 2014-05-20 20:05:18 -0700 Processing by PostsController#some_comments as HTML Post Load (0.5ms) SELECT "posts".* FROM "posts" LIMIT 3 Comment Load (4.4ms) SELECT "comments".* FROM "comments" WHERE"comments "."post_id" IN (1, 2, 3) Rendered posts/some_comments.html.erb within layouts/application (12.2ms) Completed 200 OK in 560ms (Views: 219.3ms | ActiveRecord: 5.0ms)

Viel effizienter.

Diese Lösung des N+1-Problems ist wirklich nur als Beispiel für die Art von Ineffizienzen gedacht, die „unter der Haube“ in Ihrer Anwendung existieren können, wenn Sie nicht ausreichend darauf achten. Das Fazit hier ist, dass Sie Ihre Entwicklungs- und Testprotokolldateien während der Entwicklung überprüfen sollten, um Ineffizienzen im Code, der Ihre Antworten erstellt, zu überprüfen (und zu beheben!).

Das Überprüfen von Protokolldateien ist eine großartige Möglichkeit, um auf Ineffizienzen in Ihrem Code aufmerksam zu werden und diese zu korrigieren, bevor Ihre Anwendung in Produktion geht. Andernfalls werden Sie sich eines resultierenden Rails-Leistungsproblems möglicherweise nicht bewusst, bis Ihr System live geht, da der Datensatz, mit dem Sie in Entwicklung und Test arbeiten, wahrscheinlich viel kleiner ist als in der Produktion. Wenn Sie an einer neuen App arbeiten, kann sogar Ihr Produktionsdatensatz klein anfangen und Ihre App sieht so aus, als würde sie gut laufen. Wenn Ihr Produktionsdatensatz jedoch wächst, führen Rails-Probleme wie dieses dazu, dass Ihre Anwendung immer langsamer ausgeführt wird.

Wenn Sie feststellen, dass Ihre Protokolldateien mit einer Reihe von Informationen verstopft sind, die Sie nicht benötigen, finden Sie hier einige Dinge, die Sie tun können, um sie zu bereinigen (die Techniken dort funktionieren sowohl für Entwicklungs- als auch für Produktionsprotokolle).

Häufiger Fehler Nr. 7: Mangel an automatisierten Tests

Ruby und Rails bieten standardmäßig leistungsstarke automatisierte Testfunktionen. Viele Rails-Entwickler schreiben sehr ausgefeilte Tests mit TDD- und BDD-Stilen und verwenden noch leistungsfähigere Test-Frameworks mit Edelsteinen wie rspec und cucumber.

Obwohl es so einfach ist, automatisierte Tests zu Ihrer Rails-Anwendung hinzuzufügen, war ich sehr unangenehm überrascht, wie viele Projekte ich geerbt oder denen ich beigetreten bin, bei denen buchstäblich keine (oder bestenfalls sehr wenige) Tests vom Vorgänger geschrieben wurden Entwicklungsteam. Während es viele Diskussionen darüber gibt, wie umfassend Ihre Tests sein sollten, ist es ziemlich klar, dass zumindest einige automatisierte Tests für jede Anwendung vorhanden sein sollten.

Als Faustregel gilt, dass für jede Aktion in Ihren Controllern mindestens ein High-Level-Integrationstest geschrieben werden sollte. Irgendwann in der Zukunft werden andere Rails-Entwickler höchstwahrscheinlich den Code erweitern oder modifizieren oder eine Ruby- oder Rails-Version aktualisieren wollen, und dieses Test-Framework wird ihnen eine klare Möglichkeit bieten, die grundlegende Funktionalität der Anwendung zu überprüfen Arbeiten. Ein zusätzlicher Vorteil dieses Ansatzes besteht darin, dass er zukünftigen Entwicklern eine klare Abgrenzung der vollständigen Sammlung von Funktionen bietet, die von der Anwendung bereitgestellt werden.

Häufiger Fehler Nr. 8: Blockieren von Anrufen bei externen Diensten

Drittanbieter von Rails-Diensten machen es normalerweise sehr einfach, ihre Dienste über Gems, die ihre APIs umhüllen, in Ihre Anwendung zu integrieren. Aber was passiert, wenn Ihr externer Dienst ausfällt oder sehr langsam läuft?

Um zu vermeiden, dass diese Aufrufe blockiert werden, sollten Sie diese Dienste, anstatt sie während der normalen Verarbeitung einer Anfrage direkt in Ihrer Rails-Anwendung aufzurufen, nach Möglichkeit in eine Art Job-Warteschlangendienst im Hintergrund verschieben. Einige beliebte Edelsteine, die in Rails-Anwendungen für diesen Zweck verwendet werden, sind:

• Verzögerte Arbeit
• Resque
• Sidekiq

In Fällen, in denen es unpraktisch oder unmöglich ist, die Verarbeitung an eine Hintergrundjobwarteschlange zu delegieren, müssen Sie sicherstellen, dass Ihre Anwendung über ausreichende Fehlerbehandlungs- und Failover-Vorkehrungen für die unvermeidlichen Situationen verfügt, in denen der externe Dienst ausfällt oder Probleme auftreten . Sie sollten Ihre Anwendung auch ohne den externen Dienst testen (indem Sie vielleicht den Server, auf dem sich Ihre Anwendung befindet, aus dem Netzwerk entfernen), um sicherzustellen, dass dies nicht zu unerwarteten Folgen führt.

Häufiger Fehler Nr. 9: Heirat mit bestehenden Datenbankmigrationen

Mit dem Datenbankmigrationsmechanismus von Rails können Sie Anweisungen zum automatischen Hinzufügen und Entfernen von Datenbanktabellen und -zeilen erstellen. Da die Dateien, die diese Migrationen enthalten, sequenziell benannt sind, können Sie sie von Anfang an wiedergeben, um eine leere Datenbank in dasselbe Schema wie die Produktion zu bringen. Dies ist daher eine großartige Möglichkeit, granulare Änderungen am Datenbankschema Ihrer Anwendung zu verwalten und Rails-Probleme zu vermeiden.

Während dies zu Beginn Ihres Projekts sicherlich gut funktioniert, kann der Datenbankerstellungsprozess im Laufe der Zeit eine ganze Weile dauern und manchmal werden Migrationen verlegt, falsch eingefügt oder von anderen Rails-Anwendungen eingeführt, die denselben Datenbankserver verwenden.

Rails erstellt eine Darstellung Ihres aktuellen Schemas in einer Datei namens db/schema.rb (standardmäßig), die normalerweise aktualisiert wird, wenn Datenbankmigrationen ausgeführt werden. Die Datei schema.rb kann sogar generiert werden, wenn keine Migrationen vorhanden sind, indem die Aufgabe rake rake db:schema:dump ausgeführt wird. Ein häufiger Rails-Fehler besteht darin, eine neue Migration in Ihr Quellrepo zu überprüfen, aber nicht die entsprechend aktualisierte schema.rb -Datei.

Wenn Migrationen außer Kontrolle geraten sind und zu lange dauern oder die Datenbank nicht mehr ordnungsgemäß erstellt wird, sollten Entwickler keine Angst haben, das alte Migrationsverzeichnis zu löschen, ein neues Schema zu sichern und von dort aus fortzufahren. Das Einrichten einer neuen Entwicklungsumgebung würde dann ein rake db:schema:load statt des rake db:migrate erfordern, auf das sich die meisten Entwickler verlassen.

Einige dieser Probleme werden auch im Rails Guide behandelt.

Häufiger Fehler Nr. 10: Einchecken vertraulicher Informationen in Quellcode-Repositories

Das Rails-Framework macht es einfach, sichere Anwendungen zu erstellen, die gegen viele Arten von Angriffen unempfindlich sind. Einiges davon wird durch die Verwendung eines geheimen Tokens erreicht, um eine Sitzung mit einem Browser zu sichern. Obwohl dieses Token jetzt in config/secrets.yml gespeichert ist und diese Datei das Token aus einer Umgebungsvariablen für Produktionsserver liest, enthielten frühere Versionen von Rails das Token in config/initializers/secret_token.rb . Diese Datei wird oft fälschlicherweise mit dem Rest Ihrer Anwendung in das Quellcode-Repository eingecheckt, und in diesem Fall kann jeder mit Zugriff auf das Repository jetzt problemlos alle Benutzer Ihrer Anwendung kompromittieren .

Stellen Sie daher sicher, dass Ihre Repository-Konfigurationsdatei (z. B. .gitignore für Git-Benutzer) die Datei mit Ihrem Token ausschließt. Ihre Produktionsserver können ihr Token dann aus einer Umgebungsvariablen oder einem Mechanismus wie dem, den das dotenv-Gem bereitstellt, abrufen.

Zusammenfassung des Tutorials

Rails ist ein leistungsstarkes Framework, das viele hässliche Details verbirgt, die zum Erstellen einer robusten Webanwendung erforderlich sind. Während dies die Entwicklung von Rails-Webanwendungen erheblich beschleunigt, sollten Entwickler auf potenzielle Design- und Codierungsfehler achten, um sicherzustellen, dass ihre Anwendungen leicht erweiterbar und wartbar sind, wenn sie wachsen.

Entwickler müssen sich auch der Probleme bewusst sein, die ihre Anwendungen langsamer, weniger zuverlässig und weniger sicher machen können. Es ist wichtig, das Framework zu studieren und sicherzustellen, dass Sie die Architektur-, Design- und Codierungskompromisse, die Sie während des Entwicklungsprozesses eingehen, vollständig verstehen, um eine qualitativ hochwertige und leistungsstarke Anwendung sicherzustellen.