Rails-Entwicklung: Kodierungskonventionen und bewährte Praktiken

Was steckt in einem Namen?

Ein guter Name beantwortet wichtige Fragen. Was beinhaltet er? Was bedeutet er? Wie kann ich es verwenden?
Welche Rolle spielt sie?
Benennen Sie Ihre Methoden immer nach ihrem Verhalten und nicht nach ihrer Implementierung.
Bedenken Sie,

Kodierung

Anhand des obigen Methodennamens können wir vorhersagen, dass sie 2-3 Datenbankoperationen durchführen wird, aber
wenn ich im Geschäftsmodell arbeite, warum sollte mich das etwas angehen?
Durch die Benennung von Methoden auf der Grundlage ihrer Geschäftsrolle kann die Methode umbenannt werden in,

Rails-Codierung

Strukturelle Benennung

Eine weitere gängige Strategie besteht darin, Dinge nach ihrer Rolle im Programm zu benennen. Es ist die Eingabe oder die Ausgabe. Es ist die wiederkehrende Phrase oder der mittlere Satz. Betrachten Sie den Code zum Zählen von Differenzen zwischen zwei Punkten;

Hier sind die Argumente erstens und zweitens ziemlich vage, wenn man bedenkt, dass wir nicht einmal sicher sind, ob die Reihenfolge eine Rolle spielt. In diesem Zusammenhang spielt sie keine Rolle.
Ich kann dann meinen Code wie folgt umstrukturieren;

Schienen

Daraus können wir schließen, dass der erste Schritt darin bestand, das Problem auf Englisch zu beschreiben. Bei der Berechnung des Abstands zwischen zwei Strängen geht es um die Anzahl der Mutationen, die zwischen den beiden Strängen auftreten.

Refaktorierung

Das Umstellen von Code ist im Allgemeinen ziemlich trivial. Der knifflige Teil besteht darin, zu wissen, wo man anfangen soll, und zu erkennen, dass man es tun kann. Ein Teil der Überwindung dieser Hürde besteht darin, es einfach ein paar Mal zu tun. Suchen Sie eine Bedingung, und erstellen Sie für jeden ihrer Blöcke ein Objekt, dessen einzige Aufgabe es ist, diese Aufgabe zu erfüllen.

Beim Refactoring geht es darum, einen Codeschnipsel zu erkennen, der bekanntermaßen problematische Merkmale aufweist, und eine Änderung vorzunehmen, von der bekannt ist, dass sie diese Kategorie von Problemen behebt.
Dieses problematische Muster wird als Code Smell bezeichnet: "Code Smell ist ein oberflächlicher Hinweis, der in der Regel auf ein tieferes Problem im System hinweist." - Martin Fowler
Es ist nie eine schlechte Idee, klein anzufangen. Wenn man den Code auf Mikroebene refaktorisieren kann, dann wird er, wenn alles zusammenkommt, zu einem refaktorisierten Code.
Betrachten Sie zum Beispiel zwei Codeschnipsel,

Summe                        alt

Worin besteht die Ähnlichkeit der obigen Codestücke? Beide haben jede Schleife, und wenn wir versuchen, ihren Code zu finden riecht,

  • Eine Schleife mit einer temporären Variablen.
  • Eine Schleife mit einer verschachtelten Bedingung.

Versuchen wir, sie zu refaktorisieren

Die erste Schleife hat nur eine temporäre Variable, die mit 'inject' fixiert werden kann

Zahlen

Hier gibt es zwei temporäre Variablen und eine verschachtelte Schleife. Da wir versuchen, sie in eine Rangfolge zu bringen, sollte sort_by funktionieren! Der Code kann noch weiter verfeinert werden, da wir versuchen, den Maximalwert zu finden, können wir hier direkt die max_by-Funktion verwenden,

Nummer

Allgemeine Praktiken

  • Wie wäre es, wenn wir eine Reihe von Regeln aufstellen, die wir beim Kodieren befolgen und die später unseren Aufwand beim Refactoring verringern.
    Der grundlegendste und wichtigste Punkt ist die FORMATIERUNG. Es klingt wie das Offensichtlichste und Einfachste, was man tun kann, aber es ist sehr wichtig, den Code richtig zu formatieren. Im Hinblick auf die Lesbarkeit des Codes, das Verständnis für künftige Referenzen und auch bei der Lösung von Konflikten, die beim Zusammenführen von zwei verschiedenen Zweigen auftreten.
  • Wenn Sie eine Wenn-Bedingung mit mehreren Unterbedingungen schreiben, versuchen Sie immer, diese so anzuordnen, dass der geringste Aufwand entsteht. Zum Beispiel,

Schienen

  • Wenn Sie einen großen Teil der Logik haben, der sich um eine einzige Funktion dreht, sollten Sie versuchen, diesen in mehrere kleinere Methoden aufzuteilen. Das erhöht die Wiederverwendbarkeit und macht es einem neuen Entwickler leicht, den Code zu verstehen. Anstatt alles in eine einzige Methode zu schreiben und ihr das Aussehen einer komplexen Logik zu geben, unterteilen Sie sie in kleinere, lesbare Methodenabschnitte.
  • Kommentieren Sie Ihren magischen Code. Ruby bietet eine Vielzahl von Metaprogrammiermethoden, die den Aufwand reduzieren und zeitsparend sind. Aber sie sind nicht immer so einfach zu verstehen, wenn man auf sie zurückgreifen will. Es ist immer eine gute Idee, entsprechende Kommentare hinzuzufügen, so dass es für Sie einfacher wird, den Anschluss wiederzufinden, wenn Sie später zurückkommen, um einen Blick darauf zu werfen.
  • Verwenden Sie before_filter, anstatt sich im Controller zu wiederholen.
  • Verwenden Sie Modell-Callbacks, um zu vermeiden, dass zu viel Code in Controllern für die Aktionen geschrieben wird, die sich um die grundlegenden CRUD-Operationen drehen.
  • FORMATIEREN: Es gibt einige Perlen, die Ihnen das Leben sehr erleichtern: awesome_print; pretty print; rubocop.
  • Befolgen Sie stets die Praxis der Codeüberprüfung in Git. Code, der von einem Entwickler geschrieben wurde, sollte von anderen Teammitgliedern überprüft werden, bevor er mit den Hauptzweigen zusammengeführt wird, da dies dazu beiträgt, mögliche Fehler oder unerwartete Ergebnisse auszuschließen. Es hilft auch dabei, dass jedes Mitglied informiert und auf dem Laufenden ist, woran sein Kollege arbeitet.
  • Anweisungen, die über 80 Zeichen hinausgehen, sollten in weitere Zeilen aufgeteilt werden, damit bei der Anzeige des Codes in anderen Medien wie GitHub keine Bildlaufleiste erscheint.
  • Wenn Sie Code in Ihr Repository übertragen, sagt mir git diff, was Sie getan haben, und Ihre Übertragungsnachricht sollte sagen, warum Sie das getan haben.
  • OPTIMIEREN SIE NICHT nach Leistung - OPTIMIEREN SIE NACH KLARHEIT DES CODES
  • Unit-Tests sind immer eine gute Idee, um sicherzustellen, dass die Funktionalität so funktioniert, wie Sie es erwartet haben.Help by Aspect: Rails generiert standardmäßig einen Helper für jeden Controller. Eliminieren Sie diese und versuchen Sie, Helfer zu verwenden, die aspektorientiert sind wie ; -> link_helper -> menu_helper
  • Gemäß der MVC-Konvention sollten Aufrufe an die Datenbank aus der View-Schicht vermieden werden. Verschieben Sie diesen Teil Ihres Codes in die Controller, um die Trennung der Anliegen zu gewährleisten.
  • Reduzieren Sie die Datenbankaufrufe. Wenn eine häufig besuchte Seite mehr als ein paar Aufrufe an die DB auslöst, lohnt es sich, ein wenig Zeit zu investieren, um die Anzahl der Aufrufe auf ein paar wenige zu reduzieren. In vielen Fällen ist dies nur eine Frage der Verwendung von .includes() oder .joins().
  • Es wird zu einer mühsamen Aufgabe, Ihre Modellstruktur von Zeit zu Zeit zu überprüfen. Als Ausweg können Sie Ihre Modellstruktur am Anfang der Datei als Referenz einfügen.

Ich hoffe, das hat geholfen! Ich melde mich ab, Niyanta

Speichern

Speichern

Speichern

Speichern

Speichern

Speichern

Abonnieren Sie die neuesten Updates

zusammenhängende Posts

Hinterlasse einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

de_DEGerman