10 Cele mai frecvente greșeli pe rubin pe șine sunt cel mai bun tutorial, studioul lui Michail Kechinov

Top 10 cele mai frecvente greșeli pe Ruby on Rails: cel mai bun tutorial hands-on

Ruby on Rails (sau pur și simplu "Rails") este un sistem popular open source bazat pe limbajul de programare Ruby, care urmărește simplificarea și raționalizarea procesului de dezvoltare web.







Rails este construit pe principiul acordului de configurare. Pur și simplu, acest lucru înseamnă că, în mod implicit, Rails presupune că dezvoltatorii profesioniști vor urma cele mai bune practici standard (cum ar fi numele, structura codului etc.) și dacă o vor face, totul va funcționa "automat și în mod magic" , fără a fi nevoie să clarificăm ceva. O astfel de paradigmă are avantajele sale, dar nu a fost fără capcane. În special, "magia" care apare în spatele scenei poate uneori să ducă la glitches, confuzii și probleme precum "ce naiba se întâmplă?". Și pot exista consecințe nedorite în domeniul securității și productivității.

În consecință, în timp ce Rails este ușor de folosit, este de asemenea ușor să câștigi probleme cu el. Acest tutorial va examina cele mai populare 10 probleme, vă va spune cum să le evitați și să identificați motivele care le provoacă.

10 Cele mai frecvente greșeli pe rubin pe șine sunt cel mai bun tutorial, studioul lui Michail Kechinov

Eroare 1. Prea multă logică în controler

Rails este construit pe baza arhitecturii MVC. În comunitatea Rails, vorbim despre un model gros și un controler subțire, dar în ultima vreme am văzut mai multe aplicații pe Rails care au încălcat acest principiu. La urma urmei, este atât de ușor să puneți toată logica vizualizării (care este locul în ajutor) sau modelul logic în controlerul propriu-zis.

Problema este că obiectul controlerului va începe să încalce principiul unei taxe unice, făcând modificările viitoare ale codului dificile și predispuse la erori. În general, aici sunt tipurile de logică care pot fi în controlerul dvs.:

În timp ce acest lucru încă încalcă principiul unei taxe unice, acesta este un fel de minim pe care le solicită cadrul rails de la operator.

Eroare 2. Prea multă logică în vedere

ERB, motorul de tip șablon "în cutie", care deschide oportunități extraordinare de a crea pagini cu conținut variat. Cu toate acestea, dacă nu sunteți atent, puteți obține în cele din urmă un fișier mare, care va amesteca codul HTML și Ruby, care va fi dificil de gestionat și care va fi dificil de întreținut. De asemenea, acest lucru poate duce la un număr mare de repetări care vor cauza încălcarea principiilor DRY (nu vă repetați).


Bine ai venit,
<% if current_user %>
<%= current_user.name %>
<% else %>
musafir
<% end %>

Cel mai bun mod de a face față unei astfel: asigurați-vă că obiectul returnat de current_user selectată întotdeauna, indiferent dacă cineva este conectat sau nu, și că îndeplinește metodele utilizate în prezentarea într-un mod rezonabil (denumit uneori nul). De exemplu, puteți defini current_user ajutor în app / controlere / application_controller astfel:

cere "ostruct"
helper_method: current_user

def curent_user
@current_user || = User.find sesiune [: user_id] dacă sesiunea [: user_id]
dacă @current_user
@current_user
altfel
OpenStruct.new (nume: 'Guest')
capăt
capăt

Acest lucru ar înlocui codul de prezentare anterior cu o singură linie:

Bine ai venit, <%= current_user.name -%>

Câteva recomandări suplimentare pentru Rails:

  • Utilizați șabloane de prezentare și metode comune pentru a încapsula lucruri repetate pe paginile dvs.
  • Utilizați decoratori, cum ar fi bijuteria Draper pentru a încapsula logica de prezentare într-un obiect Ruby. Apoi puteți adăuga metode la acest obiect pentru a reprezenta operații logice care altfel ar fi în interiorul codului de vizualizare.

Eroare 3. Prea multă logică în model

Având în vedere recomandările care spun că pentru a minimiza logica în opiniile și controlorii, ultimul loc în MVC, unde trebuie să punem toată logica - este modelul, nu?

Mulți dezvoltatori Rails fac de fapt această greșeală și, în cele din urmă, clasele lor de modele în ActiveRecord care conduc la fișierele Mongo - nu numai că încalcă principiul unei taxe unice, dar sunt, de asemenea, un coșmar pentru suport tehnic.

Această funcționalitate, ca generarea de e-mail de notificare, un apel la servicii externe, conversie de date către alte formate, și altele asemenea nu face folosind ActiveRecord model, al cărui scop - de a face ceva mai mult decât căutarea și stocarea datelor în baza de date.

Dar dacă o astfel de logică nu ar trebui să fie stocată în vizualizare, în controler și model, atunci unde?

Să vorbim despre "obiecte simple vechi Ruby" (POROs). Cu un cadru cuprinzător, cum ar fi Rails, dezvoltatorii neexperimentați deseori nu doresc să își creeze propriile clase în afara cadrului. Cu toate acestea, luând de multe ori logica modelului în interiorul POROs este ceea ce medicul prescris pentru a evita complicarea modelelor. Cu PORO, puteți încadra lucruri precum notificările prin e-mail sau interacțiunile API în propriile clase, mai degrabă decât să le stocați în interiorul modelului ActiveRecord.

Deci, pe baza celor de mai sus, singura logică care poate rămâne în modelul dvs. este:

  • Configurarea ActiveRecord (de exemplu, interconectare și validare).
  • Metode simple de mutație pentru încapsularea actualizărilor unei părți a parametrilor și salvarea acestora în baza de date.
  • Matrice de acces care ascund informațiile interne ale modelului (metoda full_name, care combină câmpurile first_name și last_name în baza de date).
  • Interogări complexe (mai complexe decât găsirea). În general, nu ar trebui să utilizați această metodă sau altă metodă de a construi o coadă în afara clasei modelului în sine.

Greșeală 4. Dump din clasele auxiliare comune

Această eroare este un fel de consecință a erorii 3. După cum sa menționat deja, structura Rails pune accent pe componentele numite (cum ar fi modelul, vizualizarea și controlerul) ca bază a MVC. Există definiții bune ale tipurilor de entități care aparțin clasei fiecăruia dintre aceste componente, dar uneori avem nevoie de metode care nu se încadrează în niciuna dintre cele trei.







Generatoarele din Rail creează un director helper și o nouă clasă de ajutor. Este din ce în ce mai tentant să începeți să creați funcționalități pe care nici un model, nici spectatorul și nici controlerul nu le vor avea deloc.

Eroare 5. Utilizarea prea multor pietre

Ruby on Rails este susținută de un bogat ecosistem de pietre prețioase, care împreună oferă practic orice ocazie pe care numai un dezvoltator o poate gândi. Acest lucru este foarte convenabil pentru crearea rapidă a aplicațiilor complexe, dar am văzut și multe aplicații în care numărul de pietre a fost disproporționat de mare în comparație cu funcționalitatea oferită.

Acest lucru duce la mai multe probleme cu Rails. Abuzul de hems face ca dimensiunile proceselor Rails să fie mai mult decât este necesar. Acest lucru poate încetini productivitatea producției. În plus față de dezamăgirea utilizatorului, aceasta poate duce la necesitatea unei mai mari memorii de server, ceea ce va crește costurile de operare. De asemenea, este nevoie de mai mult timp pentru a lansa o astfel de aplicație, care încetinește procesul de dezvoltare și face testarea automată lentă (și, de regulă, astfel de teste nu sunt executate frecvent).

Rețineți că fiecare bijuterie pe care o conectați la aplicație, la rândul său, depinde de celelalte pietre prețioase, iar acestea sunt de la alții și așa mai departe. Adăugarea pietrelor poate avea un efect comun. De exemplu, adăugarea unui heml rails_admin va adăuga mai mult de 11 pietre, care este cu 10% mai mare decât configurația de bază a Rails.

La momentul acestei scrieri, noua distribuție Rails 4.1.0 a inclus 43 de pietre în fișierul Gemfile.lock. Acest lucru este în mod clar mai mult decât este inclus în Gemfile și reprezintă toate pietrele pe care setul Rails standard le adaugă ca dependențe.

Eroare 6. Ignorarea fișierelor jurnal

În timp ce majoritatea dezvoltatorilor Rails sunt conștienți de disponibilitatea fișierelor istorice implicite în timpul dezvoltării, ele nu acordă multă atenție informațiilor din aceste fișiere. Deși multe aplicații se bazează pe instrumente de monitorizare a jurnalului, cum ar fi Honeybadger sau New Relic pe producție, este de asemenea important să urmăriți jurnalele dvs. în timpul procesului de dezvoltare și testare a aplicației.

Așa cum am menționat în această lecție, cadrul Rails face o mulțime de "magie", mai ales în cadrul modelelor. Folosirea asociațiilor face foarte ușoară construirea de relații între mese și derivarea totului în vizualizări. Toate codurile SQL sunt generate automat. Dar cum știți că SQL-ul generat este eficient?

Un exemplu cu care veți lucra adesea este problema de interogare N + 1. În timp ce problema este rezolvată, singura modalitate de a afla cauza apariției acesteia este de a examina interogările SQL din jurnalele dvs.

Active Record in Rails vă permite să reduceți în mod semnificativ numărul de solicitări, permițându-vă să specificați în prealabil toate linkurile care vor fi descărcate. Aceasta se face prin apelarea metodei include (sau preload) în obiectul Arel (ActiveRecord :: Relation). C include - ActiveRecord asigură că toate linkurile specificate sunt încărcate cu numărul minim de solicitări, de exemplu:

Soluția la problema N + 1, care în realitate nu poate fi decât un exemplu al nenumăratelor ineficiențe care trăiesc "sub capota" aplicației dvs., dacă nu acordați o atenție deosebită. Concluzia din acest punct este că trebuie să verificați dezvoltarea și testarea jurnalului în timpul dezvoltării - pentru a verifica (și elimina) ineficiențele din codul care construiește interogări.

Log Review este o modalitate bună de a localiza codul ineficient și a le repara înainte ca aplicația să intre în producție. În caz contrar, nu puteți fi siguri de performanța sistemului până când începe să "trăiască" - probabil că baza de date cu care ați lucrat în procesul de dezvoltare și testare va fi mult mai mică decât ceea ce va fi pe producție . Dacă faceți o nouă aplicație, chiar dacă baza dvs. de date de producție este inițial mică și totul funcționează bine la început, atunci va crește și problemele descrise în acest exemplu vor face sistemul să funcționeze mai încet și încet.
Dacă găsiți că jurnalele dvs. sunt înfundate cu o grămadă de informații inutile, le puteți șterge.

Eroare 7. Lipsa testelor automate

Implicit, Ruby on Rails oferă oportunități ample pentru testarea automată. Multe dintre șine dezvoltatorii scrie teste foarte sofisticate folosind TDD și stil BDD, precum și cu ajutorul unor cadre de testare mai puternice gemah furnizate (rspec și castravete).

Deși este ușor să adăugați teste automate la cererea dvs., am fost destul de surprins când m-am întâmplat să mă înscriu în proiecte în care nu a fost literalmente nici un singur test scris (sau cel puțin foarte puțin). Deși se poate argumenta despre ceea ce ar trebui să fie testele cuprinzătoare, este clar că cel puțin unele teste automate ar trebui să fie prezente în fiecare aplicație.

O regulă generală: trebuie să existe cel puțin un text de integrare la nivel înalt pentru fiecare acțiune a controlorilor dvs. La un moment dat, în viitor, alți dezvoltatori vor dori să se extindă sau să modifice codul sau proapgredit versiunea Ruby on Rails, și testul-cadru le va permite să se asigure că funcționalitatea de bază a aplicației se execută. Un avantaj suplimentar este că aceasta oferă dezvoltatorilor viitori o înțelegere clară a setului complet de funcționalități ale aplicațiilor.

Eroare 8. Blocarea accesului la servicii externe

Serviciile terță parte în serviciile Rails sunt, de obicei, foarte ușor de integrat într-o aplicație care utilizează pietre care conțin API-ul lor. Dar ce se întâmplă dacă serviciul dvs. extern începe să se prăbușească sau să funcționeze foarte încet?

Pentru a evita blocarea acestor solicitări, în loc să le accesați direct în aplicație, trebuie să le puneți în fundal, dacă este posibil. Unele pietre populare:

În cazurile în care este imposibil sau imposibil să se transfere de prelucrare în fundal, trebuie să vă asigurați că aplicația este destul de bun mâner erori și eșecuri - în cazul în care serviciul extern „este“ sau se confruntă cu probleme. De asemenea, trebuie să testați aplicația fără servicii externe (eventual prin eliminarea serverul care rulează aplicația de la rețea) pentru a vă asigura că acest lucru nu duce la consecințe nedorite.

Eroare 9. Se căsătorește cu migrațiile existente în baza de date

Mecanismul de migrare a bazei de date în Rails vă permite să creați comenzi care să adauge sau să elimine automat tabele și rânduri. Deoarece fișierele care conțin migrațiile sunt numite în ordine, le puteți reda de la bun început pentru a aduce o bază de date goală la același tip cu baza de date a producției. Deci, este o modalitate excelentă de a gestiona modificări granulare în schema bazei de date a aplicației dvs. pentru a evita problemele cu Rails.

Cu toate că acest lucru funcționează bine la începutul proiectului, timpul trece, procesul de creare a bazei de date poate dura ceva timp, și, uneori, migrația este pierdut, introdusă în ordine greșită sau preluate din alte șine aplicații care utilizează același server.

Rails creează o vedere a schiței dvs. curente în fișierul db / schema.rb (implicit), care este de obicei actualizat când începe migrarea. Fișierul schema.rb poate fi generat chiar și atunci când nu există migrații curente prin rularea rake db: schema: dump. O greșeală obișnuită este verificarea noii migrări în depozitul sursă, dar nu actualizați fișierul schema.rb.

Când migrațiile durează prea mult, dezvoltatorii nu ar trebui să se teamă să elibereze vechiul director de migrare, să elimine schema nouă și să continue cu aceasta. Configurarea unui nou mediu de dezvoltare ar necesita a face rake db: schema: load, mai degrabă decât rake db: migrate, pe care majoritatea dezvoltatorilor se bazează.

Unele dintre aceste aspecte sunt acoperite și în manualul Rails.

Eroare 10: Verificarea informațiilor confidențiale din depozitul de cod sursă

Cadrul Rails facilitează crearea de aplicații sigure care protejează împotriva multor tipuri de atacuri. Ceva se realizează cu ajutorul unui jeton secret, care vă permite să accesați sesiunea browserului. Chiar dacă acest jeton este stocat în config / secrets.yml. iar acest fișier citește tokenul dintr-un mediu diferit de serverele de producție - în cea mai recentă versiune de Rails, tokenul este inclus în config / initializers / secret_token.rb. Acest fișier este adesea inclus în mod eronat în depozit împreună cu restul aplicației. Dacă se întâmplă acest lucru, cel care primește acces la depozit va avea acces la utilizatorii aplicației.

Prin urmare, trebuie să vă asigurați că fișierul dvs. de configurare din depozit (de exemplu, gitignore pentru utilizatorii git) exclude fișierul cu jeton. Apoi, serverele dvs. de produse își pot ridica tokenul dintr-un mediu diferit de acestea sau dintr-un mecanism, cum ar fi cel furnizat de dotec gem.

Rails este un cadru puternic care ascunde multe detalii imparțiale necesare pentru a construi o aplicație fiabilă. Deși aplicațiile Rails sunt mult mai rapide, dezvoltatorii ar trebui să acorde atenție potențialelor erori în cod și design, pentru a se asigura că aplicația lor este ușor de extensibil și ușor de întreținut.

Dezvoltatorii ar trebui, de asemenea, să fie conștienți de probleme care pot face ca aplicațiile lor să fie mai lente, mai puțin fiabile sau mai puțin sigure. Este important să învățați elementele de bază ale cadrului și să vă asigurați că înțelegeți pe deplin arhitectura, designul, codul - pe tot parcursul procesului de dezvoltare. Aceasta va face o aplicație de înaltă calitate cu performanțe ridicate.







Trimiteți-le prietenilor: