Ruby on Rails ('Rails') είναι ένα δημοφιλές πλαίσιο ανοιχτού κώδικα, βασισμένο στο Ρουμπίνι γλώσσα προγραμματισμού που προσπαθεί να απλοποιήσει και να βελτιώσει τη διαδικασία ανάπτυξης εφαρμογών ιστού.
Οι ράγες βασίζονται στην αρχή του σύμβαση σχετικά με τη διαμόρφωση . Με απλά λόγια, αυτό σημαίνει ότι, από προεπιλογή, το Rails υποθέτει ότι είναι ειδικοί προγραμματιστές θα ακολουθήσει τις «τυπικές» συμβάσεις βέλτιστης πρακτικής (για πράγματα όπως ονομασία, δομή κώδικα κ.ο.κ.) και, αν το κάνετε, τα πράγματα θα λειτουργήσουν για εσάς «αυτόματα-μαγικά» χωρίς να χρειάζεται να προσδιορίσετε αυτές τις λεπτομέρειες. Ενώ αυτό το παράδειγμα έχει τα πλεονεκτήματά του, δεν είναι επίσης χωρίς τις παγίδες του. Ειδικότερα, η «μαγεία» που συμβαίνει πίσω από τα παρασκήνια στο πλαίσιο μπορεί μερικές φορές να οδηγήσει σε headfakes, σύγχυση και «τι συμβαίνει;» τύποι προβλημάτων. Μπορεί επίσης να έχει ανεπιθύμητες επιπτώσεις όσον αφορά την ασφάλεια και την απόδοση.
Κατά συνέπεια, ενώ το Rails είναι εύκολο στη χρήση, δεν είναι επίσης δύσκολο να γίνει κακή χρήση. Αυτό το σεμινάριο εξετάζει 10 κοινά προβλήματα Rails, συμπεριλαμβανομένου του τρόπου αποφυγής τους και των προβλημάτων που προκαλούν.
Οι ράγες βασίζονται σε ένα Αρχιτεκτονική MVC . Στην κοινότητα Rails, μιλάμε μοντέλο λίπους, κοκαλιάρικο ελεγκτή για λίγο τώρα, αλλά αρκετές πρόσφατες εφαρμογές Rails που έχω κληρονομήσει παραβίασαν αυτήν την αρχή. Είναι πολύ εύκολο να μετακινήσετε τη λογική προβολής (η οποία στεγάζεται καλύτερα σε βοηθό) ή λογική τομέα / μοντέλου, στον ελεγκτή.
Το πρόβλημα είναι ότι το αντικείμενο του ελεγκτή θα αρχίσει να παραβιάζει το αρχή της ενιαίας ευθύνης κάνοντας τις μελλοντικές αλλαγές στη βάση κώδικα δύσκολη και επιρρεπείς σε σφάλματα. Γενικά, το μόνο οι τύποι λογικής που πρέπει να έχετε στον ελεγκτή σας είναι:
Ενώ αυτό εξακολουθεί να ωθεί τα όρια της αρχής της ενιαίας ευθύνης, είναι το ελάχιστο ελάχιστο που το πλαίσιο Rails απαιτεί να έχουμε στον ελεγκτή.
Ο κινητήρας templating Rails εκτός κουτιού, ERB , είναι ένας πολύ καλός τρόπος για τη δημιουργία σελίδων με μεταβλητό περιεχόμενο. Ωστόσο, εάν δεν είστε προσεκτικοί, μπορείτε σύντομα να καταλήξετε σε ένα μεγάλο αρχείο που είναι ένας συνδυασμός κώδικα HTML και Ruby που μπορεί να είναι δύσκολο να διαχειριστείτε και να συντηρήσετε. Αυτός είναι επίσης ένας τομέας που μπορεί να οδηγήσει σε πολλές επαναλήψεις, που οδηγούν σε παραβιάσεις ΞΗΡΟΣ (μην επαναλάβετε τον εαυτό σας) αρχές.
Αυτό μπορεί να εκδηλωθεί με διάφορους τρόπους. Το ένα είναι η υπερβολική χρήση της υπό όρους λογικής στις προβολές. Ως απλό παράδειγμα, σκεφτείτε μια περίπτωση όπου έχουμε current_user διαθέσιμη μέθοδος που επιστρέφει τον τρέχοντα συνδεδεμένο χρήστη. Συχνά, θα καταλήξουν να υπάρχουν υπό όρους λογικές δομές όπως σε αρχεία προβολής:
Welcome, Guest
Ένας καλύτερος τρόπος για να χειριστείτε κάτι τέτοιο είναι να βεβαιωθείτε ότι το αντικείμενο επέστρεψε από current_user είναι πάντα ορίστε, εάν κάποιος είναι συνδεδεμένος ή όχι, και ότι απαντά στις μεθόδους που χρησιμοποιούνται στην προβολή με λογικό τρόπο (μερικές φορές αναφέρεται ως μηδενικό αντικείμενο). Για παράδειγμα, μπορείτε να ορίσετε το current_user βοηθός στο app/controllers/application_controller σαν αυτό:
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 Αυτό θα σας δώσει τη δυνατότητα να αντικαταστήσετε το προηγούμενο παράδειγμα κώδικα προβολής με αυτήν την απλή γραμμή κώδικα:
Welcome,
Μερικές επιπλέον προτεινόμενες βέλτιστες πρακτικές Rails:
Δεδομένης της καθοδήγησης για ελαχιστοποίηση της λογικής στις προβολές και τους ελεγκτές, το μόνο μέρος που απομένει σε ένα Αρχιτεκτονική MVC για να βάλετε όλη αυτή τη λογική στα μοντέλα, σωστά;
Λοιπόν, όχι αρκετά.
Πολλά Προγραμματιστές σιδηροτροχιών πραγματικά κάνουν αυτό το λάθος και καταλήγουν να κολλάνε τα πάντα στο ActiveRecord μοντέλα τάξεων που οδηγούν σε αρχεία mongo που δεν παραβιάζουν μόνο την αρχή της ενιαίας ευθύνης, αλλά είναι επίσης εφιάλτης συντήρησης.
Η λειτουργικότητα όπως η δημιουργία ειδοποιήσεων μέσω email, η διασύνδεση με εξωτερικές υπηρεσίες, η μετατροπή σε άλλες μορφές δεδομένων και παρόμοια δεν έχουν να κάνουν με την βασική ευθύνη ενός ActiveRecord μοντέλο που θα έπρεπε να κάνει κάτι περισσότερο από το να βρει και να διατηρήσει δεδομένα σε μια βάση δεδομένων.
Επομένως, εάν η λογική δεν πρέπει να πηγαίνει στις προβολές και δεν πρέπει να πηγαίνει στα χειριστήρια και δεν πρέπει να πηγαίνει στα μοντέλα, τότε λοιπόν, πού πρέπει να πάει;
Εισαγω απλά παλιά αντικείμενα Ruby (PORO). Με ένα ολοκληρωμένο πλαίσιο όπως το Rails, οι νεότεροι προγραμματιστές συχνά διστάζουν να δημιουργήσουν τις δικές τους τάξεις εκτός του πλαισίου. Ωστόσο, η μεταφορά λογικής από το μοντέλο σε POROs είναι συχνά ακριβώς αυτό που ο γιατρός διέταξε να αποφύγει υπερβολικά περίπλοκα μοντέλα. Με τα PORO, μπορείτε να ενσωματώσετε πράγματα όπως ειδοποιήσεις μέσω email ή αλληλεπιδράσεις API στις δικές τους τάξεις, αντί να τις κολλήσετε σε μια ActiveRecord μοντέλο.
c Corporation s εταιρική διαφορά
Έτσι, έχοντας κατά νου, γενικά, η μόνη λογική που πρέπει να παραμείνει στο μοντέλο σας είναι:
ActiveRecord διαμόρφωση (δηλαδή, σχέσεις και επικυρώσεις)full_name που συνδυάζει πεδία first_name και last_name στη βάση δεδομένων)find) · Σε γενικές γραμμές, δεν πρέπει ποτέ να χρησιμοποιείτε το where μέθοδος ή άλλες μεθόδους δημιουργίας ερωτημάτων όπως αυτή, εκτός της ίδιας της κλάσης μοντέλουΑυτό το λάθος είναι πραγματικά ένα συμπτωματικό στο λάθος # 3 παραπάνω. Όπως συζητήθηκε, το πλαίσιο Rails δίνει έμφαση στα ονόματα των συστατικών (δηλαδή, μοντέλο, προβολή και ελεγκτής) ενός πλαισίου MVC. Υπάρχουν αρκετά καλοί ορισμοί για τα είδη των πραγμάτων που ανήκουν στις τάξεις καθενός από αυτά τα συστατικά, αλλά μερικές φορές ίσως χρειαζόμαστε μεθόδους που δεν φαίνεται να ταιριάζουν σε κανένα από τα τρία.
Οι γεννήτριες σιδηροτροχιών δημιουργούν εύκολα έναν κατάλογο βοηθών και μια νέα τάξη βοηθών για κάθε νέο πόρο που δημιουργούμε. Γίνεται πολύ δελεαστικό, ωστόσο, να αρχίσετε να γεμίζετε οποιαδήποτε λειτουργικότητα που δεν ταιριάζει επίσημα στο μοντέλο, την προβολή ή τον ελεγκτή σε αυτές τις τάξεις βοηθού.
Ενώ το Rails είναι σίγουρα επικεντρωμένο στο MVC, τίποτα δεν σας εμποδίζει να δημιουργήσετε τους δικούς σας τύπους τάξεων και να προσθέσετε κατάλληλους καταλόγους για να διατηρήσετε τον κώδικα για αυτές τις τάξεις. Όταν έχετε επιπλέον λειτουργικότητα, σκεφτείτε ποιες μεθόδους ομαδοποιούνται και βρείτε καλά ονόματα για τις τάξεις που διαθέτουν αυτές τις μεθόδους. Η χρήση ενός περιεκτικού πλαισίου, όπως το Rails, δεν αποτελεί δικαιολογία για να αφήσετε τις καλές πρακτικές με αντικειμενοστρεφή σχεδίαση να παραμείνουν.
Το Ruby και το Rails υποστηρίζονται από ένα πλούσιο οικοσύστημα πολύτιμων λίθων που παρέχουν συλλογικά σχεδόν κάθε ικανότητα που μπορεί να σκεφτεί ένας προγραμματιστής. Αυτό είναι υπέροχο για τη γρήγορη δημιουργία μιας σύνθετης εφαρμογής, αλλά έχω δει επίσης πολλές φουσκωμένες εφαρμογές όπου ο αριθμός των πολύτιμων λίθων στην εφαρμογή Gemfile είναι δυσανάλογα μεγάλο σε σύγκριση με την παρεχόμενη λειτουργικότητα.
Αυτό προκαλεί πολλά προβλήματα Rails. Η υπερβολική χρήση πολύτιμων λίθων καθιστά το μέγεθος μιας διαδικασίας Rails μεγαλύτερο από ό, τι πρέπει. Αυτό μπορεί να επιβραδύνει την απόδοση στην παραγωγή. Εκτός από την απογοήτευση των χρηστών, αυτό μπορεί επίσης να οδηγήσει στην ανάγκη μεγαλύτερης διαμόρφωσης μνήμης διακομιστή και αυξημένου κόστους λειτουργίας. Χρειάζεται επίσης περισσότερο χρόνο για να ξεκινήσετε μεγαλύτερες εφαρμογές Rails, γεγονός που καθιστά την ανάπτυξη πιο αργή και καθιστά τις αυτοματοποιημένες δοκιμές περισσότερο χρόνο (και κατά κανόνα, οι αργές δοκιμές απλά δεν εκτελούνται τόσο συχνά).
Λάβετε υπόψη ότι κάθε στολίδι που φέρνετε στην αίτησή σας μπορεί με τη σειρά του να εξαρτάται από άλλους πολύτιμους λίθους και αυτά μπορεί με τη σειρά του να εξαρτάται από άλλους πολύτιμους λίθους και ούτω καθεξής. Η προσθήκη άλλων πολύτιμων λίθων μπορεί επομένως να έχει ένα σύνθετο αποτέλεσμα. Για παράδειγμα, η προσθήκη του rails_admin Το gem θα φέρει συνολικά 11 επιπλέον πολύτιμους λίθους συνολικά, πάνω από 10% αύξηση από την βασική εγκατάσταση Rails.
Από αυτήν τη γραφή, μια νέα εγκατάσταση Rails 4.1.0 περιλαμβάνει 43 πολύτιμους λίθους στο Gemfile.lock αρχείο. Αυτό είναι προφανώς περισσότερο από ό, τι περιλαμβάνεται στο Gemfile και αντιπροσωπεύει όλους τους πολύτιμους λίθους που φέρνουν οι χούφτες των τυπικών πολύτιμων λίθων ως εξαρτήσεις.
Εξετάστε προσεκτικά αν η επιπλέον επιβάρυνση αξίζει τον κόπο καθώς προσθέτετε κάθε στολίδι. Για παράδειγμα, οι προγραμματιστές συχνά προσθέτουν άνετα το rails_admin πολύτιμος λίθος επειδή παρέχει ουσιαστικά μια ωραία διεπαφή ιστού στη δομή του μοντέλου, αλλά στην πραγματικότητα δεν είναι κάτι περισσότερο από ένα φανταστικό εργαλείο περιήγησης βάσεων δεδομένων. Ακόμα κι αν η εφαρμογή σας απαιτεί χρήστες διαχειριστή με πρόσθετα προνόμια, πιθανώς δεν θέλετε να τους δώσετε πρόσβαση σε ακατέργαστη βάση δεδομένων και θα σας εξυπηρετούσαν καλύτερα αναπτύσσοντας τη δική σας πιο βελτιωμένη λειτουργία διαχείρισης παρά με την προσθήκη αυτού του πολύτιμου λίθου.
Ενώ οι περισσότεροι προγραμματιστές Rails γνωρίζουν τα προεπιλεγμένα αρχεία καταγραφής που είναι διαθέσιμα κατά την ανάπτυξη και την παραγωγή, συχνά δεν δίνουν αρκετή προσοχή στις πληροφορίες σε αυτά τα αρχεία. Ενώ πολλές εφαρμογές βασίζονται σε εργαλεία παρακολούθησης καταγραφής όπως Ασβός του μελιού ή Νέο λείψανο στην παραγωγή, είναι επίσης σημαντικό να παρακολουθείτε τα αρχεία καταγραφής σας καθ 'όλη τη διαδικασία ανάπτυξης και δοκιμής της εφαρμογής σας.
Όπως αναφέρθηκε προηγουμένως σε αυτό το σεμινάριο, το πλαίσιο Rails κάνει πολλά «μαγικά» για εσάς, ειδικά στα μοντέλα. Ο καθορισμός συσχετίσεων στα μοντέλα σας καθιστά πολύ εύκολο να κάνετε σχέσεις και να έχετε όλα όσα είναι διαθέσιμα στις απόψεις σας. Όλη η SQL που απαιτείται για τη συμπλήρωση των αντικειμένων του μοντέλου σας δημιουργείται για εσάς. Αυτό είναι υπέροχο. Αλλά πώς ξέρετε ότι η SQL που δημιουργείται είναι αποτελεσματική;
Ένα παράδειγμα στο οποίο θα συναντήσετε συχνά ονομάζεται το Πρόβλημα ερωτήματος N + 1 . Ενώ το πρόβλημα είναι καλά κατανοητό, ο μόνος πραγματικός τρόπος να παρατηρηθεί ότι συμβαίνει είναι να ελέγξετε τα ερωτήματα SQL στα αρχεία καταγραφής σας.
Ας πούμε για παράδειγμα ότι έχετε το ακόλουθο ερώτημα σε μια τυπική εφαρμογή ιστολογίου όπου θα εμφανίζετε όλα τα σχόλια για ένα επιλεγμένο σύνολο δημοσιεύσεων:
def comments_for_top_three_posts posts = Post.limit(3) posts.flat_map do |post| post.comments.to_a end end Όταν εξετάζουμε το αρχείο καταγραφής ενός αιτήματος που καλεί αυτήν τη μέθοδο, θα δούμε κάτι σαν το ακόλουθο, όπου γίνεται ένα μεμονωμένο ερώτημα για τη λήψη των τριών αντικειμένων ανάρτησης και στη συνέχεια γίνονται τρία ακόμη ερωτήματα για να λάβετε τα σχόλια κάθε αντικειμένου:
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) ActiveRecord ανυπόμονη φόρτωση Η ικανότητα στο Rails επιτρέπει τη σημαντική μείωση του αριθμού των ερωτημάτων επιτρέποντάς σας να καθορίσετε εκ των προτέρων όλες οι συσχετίσεις που πρόκειται να φορτωθούν. Αυτό γίνεται καλώντας το includes (ή preload) μέθοδος στο αντικείμενο Arel (ActiveRecord::Relation) που δημιουργείται. Με includes, ActiveRecord διασφαλίζει ότι όλες οι καθορισμένες συσχετίσεις φορτώνονται χρησιμοποιώντας τον ελάχιστο δυνατό αριθμό ερωτημάτων. π.χ.:
def comments_for_top_three_posts posts = Post.includes(:comments).limit(3) posts.flat_map do |post| post.comments.to_a end end Όταν εκτελείται ο παραπάνω αναθεωρημένος κώδικας, βλέπουμε στο αρχείο καταγραφής ότι όλα τα σχόλια συλλέχθηκαν σε ένα μόνο ερώτημα αντί για τρία:
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) Πολύ πιο αποτελεσματική.
Αυτή η λύση στο πρόβλημα N + 1 εννοείται μόνο ως παράδειγμα του είδους των ανεπαρκειών που μπορεί να υπάρχουν «κάτω από την κουκούλα» στην εφαρμογή σας εάν δεν δίνετε επαρκή προσοχή. Το takeaway εδώ είναι ότι θα πρέπει να ελέγχετε την ανάπτυξη και να δοκιμάζετε τα αρχεία καταγραφής κατά την ανάπτυξη για να ελέγχετε (και να αντιμετωπίζετε!) Τις ανεπάρκειες στον κώδικα που δημιουργεί τις απαντήσεις σας.
Μερικές από τις πιο κοινές οδηγίες που εκδίδονται από τοποθεσίες web κατά το σχεδιασμό ενός ασφαλούς κωδικού πρόσβασης περιλαμβάνουν:
Ο έλεγχος των αρχείων καταγραφής είναι ένας πολύ καλός τρόπος για να ανατρέξετε στις ανεπάρκειες στον κώδικά σας και να τα διορθώσετε πριν από την έναρξη της εφαρμογής σας. Διαφορετικά, ενδέχεται να μην γνωρίζετε ένα προκύπτον πρόβλημα απόδοσης Rails έως ότου τεθεί σε λειτουργία το σύστημά σας, καθώς το σύνολο δεδομένων με το οποίο εργάζεστε κατά την ανάπτυξη και τη δοκιμή είναι πιθανό να είναι πολύ μικρότερο από ό, τι στην παραγωγή. Εάν εργάζεστε σε μια νέα εφαρμογή, ακόμη και το σύνολο δεδομένων παραγωγής σας μπορεί να ξεκινά πολύ μικρό και η εφαρμογή σας θα φαίνεται ότι λειτουργεί καλά. Ωστόσο, καθώς αυξάνεται το σύνολο δεδομένων παραγωγής σας, προβλήματα Rails όπως αυτό θα κάνουν την εφαρμογή σας να λειτουργεί πιο αργή και πιο αργή.
Εάν διαπιστώσετε ότι τα αρχεία καταγραφής σας είναι βουλωμένα με πολλές πληροφορίες που δεν χρειάζεστε εδώ είναι μερικά πράγματα που μπορείτε να κάνετε για να τα καθαρίσετε (οι τεχνικές εκεί λειτουργούν για ανάπτυξη καθώς και αρχεία καταγραφής παραγωγής).
Οι Ruby και Rails παρέχουν ισχυρές αυτοματοποιημένες δυνατότητες δοκιμής από προεπιλογή. Πολλοί προγραμματιστές Rails γράφουν πολύ εξελιγμένες δοκιμές χρησιμοποιώντας Στυλ TDD και BDD και χρησιμοποιήστε ακόμη πιο ισχυρά δοκιμαστικά πλαίσια με πολύτιμους λίθους rspec και αγγούρι .
Παρά το πόσο εύκολο είναι να προσθέσετε αυτοματοποιημένες δοκιμές στην εφαρμογή σας στο Rails, ωστόσο, με εξέπληξε πολύ δυσάρεστα το πόσα έργα έχω κληρονομήσει ή συμμετάσχει όπου υπήρχαν κυριολεκτικά όχι δοκιμές που γράφτηκαν (ή στην καλύτερη περίπτωση, πολύ λίγα) από την προηγούμενη ομάδα ανάπτυξης. Αν και υπάρχει πολλή συζήτηση σχετικά με το πόσο περιεκτική θα πρέπει να είναι η δοκιμή σας, είναι αρκετά σαφές ότι τουλάχιστον μερικοί θα πρέπει να υπάρχουν αυτοματοποιημένες δοκιμές για κάθε εφαρμογή.
Κατά γενικό κανόνα, θα πρέπει να υπάρχει τουλάχιστον ένα τεστ ολοκλήρωσης υψηλού επιπέδου για κάθε ενέργεια στους ελεγκτές σας. Σε κάποιο σημείο στο μέλλον, άλλοι προγραμματιστές Rails πιθανότατα θα θέλουν να επεκτείνουν ή να τροποποιήσουν τον κώδικα ή να αναβαθμίσουν μια έκδοση Ruby ή Rails και αυτό το πλαίσιο δοκιμών θα τους παρέχει έναν σαφή τρόπο επαλήθευσης ότι η βασική λειτουργικότητα της εφαρμογής είναι εργαζόμενος. Ένα πρόσθετο πλεονέκτημα αυτής της προσέγγισης είναι ότι παρέχει στους μελλοντικούς προγραμματιστές μια σαφή περιγραφή της πλήρους συλλογής λειτουργιών που παρέχονται από την εφαρμογή.
Οι τρίτοι πάροχοι υπηρεσιών Rails κάνουν συνήθως πολύ εύκολο να ενσωματώσουν τις υπηρεσίες τους στην εφαρμογή σας μέσω πολύτιμων λίθων που τυλίγουν τα API τους. Αλλά τι συμβαίνει εάν η εξωτερική σας υπηρεσία έχει διακοπή λειτουργίας ή αρχίσει να λειτουργεί πολύ αργά;
Για να αποφύγετε τον αποκλεισμό αυτών των κλήσεων, αντί να καλείτε αυτές τις υπηρεσίες απευθείας στην εφαρμογή Rails κατά τη διάρκεια της κανονικής διεκπεραίωσης ενός αιτήματος, θα πρέπει να τις μετακινήσετε σε κάποιο είδος υπηρεσίας ουράς στο παρασκήνιο όπου αυτό είναι εφικτό. Μερικοί δημοφιλείς πολύτιμοι λίθοι που χρησιμοποιούνται σε εφαρμογές Rails για το σκοπό αυτό περιλαμβάνουν:
Σε περιπτώσεις όπου δεν είναι πρακτικό ή ανέφικτο να μεταβιβάσετε την επεξεργασία σε μια ουρά εργασίας στο παρασκήνιο, τότε θα πρέπει να βεβαιωθείτε ότι η εφαρμογή σας διαθέτει επαρκείς ρυθμίσεις χειρισμού σφαλμάτων και αποτυχίας για εκείνες τις αναπόφευκτες καταστάσεις όταν η εξωτερική υπηρεσία τερματίζεται ή αντιμετωπίζει προβλήματα . Θα πρέπει επίσης να δοκιμάσετε την εφαρμογή σας χωρίς την εξωτερική υπηρεσία (ίσως καταργώντας τον διακομιστή στον οποίο βρίσκεται η εφαρμογή σας από το δίκτυο) για να βεβαιωθείτε ότι δεν οδηγεί σε απρόβλεπτες συνέπειες.
Ράγες μηχανισμός μετεγκατάστασης βάσης δεδομένων σας επιτρέπει να δημιουργήσετε οδηγίες για αυτόματη προσθήκη και κατάργηση πινάκων και σειρών βάσης δεδομένων. Δεδομένου ότι τα αρχεία που περιέχουν αυτές τις μετακινήσεις ονομάζονται με διαδοχικό τρόπο, μπορείτε να τα αναπαράγετε από την αρχή του χρόνου για να φέρετε μια κενή βάση δεδομένων στο ίδιο σχήμα με την παραγωγή. Αυτός είναι επομένως ένας πολύ καλός τρόπος για τη διαχείριση λεπτομερών αλλαγών στο σχήμα βάσης δεδομένων της εφαρμογής σας και για την αποφυγή προβλημάτων Rails.
Ενώ αυτό σίγουρα λειτουργεί καλά στην αρχή του έργου σας, καθώς περνάει ο χρόνος, η διαδικασία δημιουργίας βάσης δεδομένων μπορεί να διαρκέσει αρκετά και μερικές φορές οι μετεγκαταστάσεις γίνονται εσφαλμένες, εισάγονται εκτός λειτουργίας ή εισάγονται από άλλες εφαρμογές Rails χρησιμοποιώντας τον ίδιο διακομιστή βάσης δεδομένων.
Το Rails δημιουργεί μια αναπαράσταση του τρέχοντος σχήματος σε ένα αρχείο που ονομάζεται db/schema.rb (από προεπιλογή) η οποία συνήθως ενημερώνεται όταν εκτελούνται μετεγκαταστάσεις βάσης δεδομένων. Το schema.rb Το αρχείο μπορεί να δημιουργηθεί ακόμη και όταν δεν υπάρχουν μετεγκαταστάσεις εκτελώντας το rake db:schema:dump έργο. Ένα συνηθισμένο λάθος Rails είναι να ελέγξετε μια νέα μετεγκατάσταση στο repo πηγής σας, αλλά όχι το αντίστοιχα ενημερωμένο schema.rb αρχείο.
Όταν οι μετεγκαταστάσεις έχουν ξεπεραστεί και χρειάζονται πολύ χρόνο για να εκτελεστούν ή δεν δημιουργούν πλέον σωστά τη βάση δεδομένων, οι προγραμματιστές δεν πρέπει να φοβούνται να διαγράψουν τον παλιό κατάλογο μετεγκαταστάσεων, να απορρίψουν ένα νέο σχήμα και να συνεχίσουν από εκεί. Η δημιουργία ενός νέου περιβάλλοντος ανάπτυξης θα απαιτούσε ένα rake db:schema:load αντί για το rake db:migrate στο οποίο βασίζονται οι περισσότεροι προγραμματιστές.
Μερικά από αυτά συζητούνται θέματα στον οδηγό ράγες επίσης.
Το πλαίσιο Rails διευκολύνει τη δημιουργία ασφαλών εφαρμογών που είναι αδιαπέραστες από πολλούς τύπους επιθέσεων. Ορισμένα από αυτά επιτυγχάνονται με τη χρήση μυστικού διακριτικού για την εξασφάλιση μιας περιόδου σύνδεσης με ένα πρόγραμμα περιήγησης. Παρόλο που αυτό το διακριτικό είναι πλέον αποθηκευμένο στο config/secrets.yml και αυτό το αρχείο διαβάζει το διακριτικό από μια μεταβλητή περιβάλλοντος για διακομιστές παραγωγής, οι προηγούμενες εκδόσεις του Rails περιελάμβαναν το διακριτικό στο config/initializers/secret_token.rb. Αυτό το αρχείο ελέγχεται κατά λάθος στο αποθετήριο πηγαίου κώδικα με την υπόλοιπη εφαρμογή σας και, όταν συμβαίνει αυτό, οποιοσδήποτε έχει πρόσβαση στο αποθετήριο μπορεί πλέον να θέσει σε κίνδυνο όλους τους χρήστες της εφαρμογής σας .
Επομένως, πρέπει να βεβαιωθείτε ότι το αρχείο διαμόρφωσης του αποθετηρίου σας (π.χ. .gitignore για πηγαίνω χρήστες) εξαιρεί το αρχείο με το διακριτικό σας. Οι διακομιστές παραγωγής σας μπορούν στη συνέχεια να παραλάβουν το διακριτικό τους από μια μεταβλητή περιβάλλοντος ή από έναν μηχανισμό όπως αυτός που dotenv στολίδι παρέχει.
Το Rails είναι ένα ισχυρό πλαίσιο που κρύβει πολλές από τις άσχημες λεπτομέρειες που απαιτούνται για την κατασκευή ενός ισχυρή διαδικτυακή εφαρμογή . Αν και αυτό καθιστά την ανάπτυξη εφαρμογών ιστού Rails πολύ πιο γρήγορη, οι προγραμματιστές θα πρέπει να δώσουν προσοχή στο πιθανό σφάλμα σχεδιασμού και κωδικοποίησης, για να βεβαιωθούν ότι οι εφαρμογές τους είναι εύκολα επεκτάσιμες και διατηρήσιμες καθώς μεγαλώνουν.
Οι προγραμματιστές πρέπει επίσης να γνωρίζουν θέματα που μπορούν να κάνουν τις εφαρμογές τους πιο αργές, λιγότερο αξιόπιστες και λιγότερο ασφαλείς. Είναι σημαντικό να μελετήσετε το πλαίσιο και να βεβαιωθείτε ότι έχετε κατανοήσει πλήρως τις αντισταθμίσεις αρχιτεκτονικού, σχεδιασμού και κωδικοποίησης που κάνετε κατά τη διαδικασία ανάπτυξης, για να διασφαλίσετε μια εφαρμογή υψηλής ποιότητας και υψηλής απόδοσης.
Σχετίζεται με: Ποια είναι τα οφέλη του Ruby on Rails; Μετά από δύο δεκαετίες προγραμματισμού, χρησιμοποιώ Rails
