Ruby on Rails downsides e avvertimenti [chiuso]

Questo deriva dall'esperienza, dall'apprendimento, dalla continua conoscenza e dalla scrittura di un'applicazione relativamente semplice in Rails.

1) Curva di apprendimento

Rails è apparentemente semplice. Le esercitazioni, i video e i libri dimostrano quanto velocemente puoi ottenere un'applicazione funzionante (se brutta), ma questi in realtà graffiano la superficie. Tendono a fare molto affidamento sulla generazione di codice e sul "ponteggio", che è certamente un buon strumento per l'apprendimento, ma sopravvive rapidamente alla sua utilità.

Non commettere errori, Rails è difficile da padroneggiare. Una volta superati i principi di base (ne parleremo più avanti) correrai a capofitto in un muro se devi fare qualcosa di più della semplicistica "demo app" che vedi reclamizzata. Puoi acquisire una conoscenza di base di Ruby durante l'apprendimento, ma devi recuperare rapidamente Ruby o ti verrà lasciato a bocca asciutta (e non il buon tipo di DRY ) se devi uscire dai limiti di Rails .

Rails è, come mi piace chiamarlo in modo amorevole, paint by numbers programming . Se vi attenete al 100% alle convenzioni (ovvero rimanete all'interno delle linee e utilizzate i colori che vi viene consigliato di utilizzare) potete realizzare applicazioni decenti in modo rapido e semplice. Se e quando devi invece deviare, Rails può passare dal tuo migliore amico al tuo peggior nemico.

2) Quando tutto quello che hai è un martello ...

Rails fa semplicistiche applicazioni CRUD molto bene. Il problema si presenta quando la tua app deve fare molto di più che leggere / scrivere da un database. Ora, per la cronaca, l'ultima versione di Rails che ho usato era 2.3.4, quindi le cose potrebbero essere cambiate da allora, ma mi sono imbattuto in principali problemi quando i requisiti aziendali sono cambiati, quindi l'applicazione doveva avere un piccolo sistema di flusso di lavoro integrato e integrato con un'applicazione legacy PHP. La convenzione Rails di "una forma, un modello" funziona bene per applicazioni banali e applicazioni di data entry, ma non tanto quando è necessario fare logica di elaborazione, o avere flussi di lavoro, o qualsiasi cosa che non sia la tipica "L'utente inserisce i dati in alcuni campi di testo, tocca Invia "tipo di cosa. È possibile essere fatto, ma non è affatto "facile", o piuttosto non è stato quando ho usato Rails per l'ultima volta.

Inoltre, a Rails non piace giocare bene con altre applicazioni che non usano i suoi metodi preferiti di accesso ai dati; se devi interfacciare con un'applicazione che non ha un'API in stile "Web 2.0", devi lavorare su Rails invece che con essa; di nuovo parlo per esperienza qui come questo è quello che mi è successo.

3) È nuovo

Infine, Rails è ancora il "nuovo ragazzo sul blocco" in molte aree. Questo non importa per uso personale o tipo "Penso che sia bello e voglia di imparare" scenari, ma parlando come qualcuno che preferirebbe usare Rails nel mio lavoro diurno, se non si è in una posizione in cui Rails è molto diffuso, può essere molto difficile trovare lavoro a tempo pieno come sviluppatore di Rails. È ancora in gran parte il dominio di "hip, nuove start-up" e non un giocatore importante nella maggior parte delle aree metropolitane. Il tuo chilometraggio può variare a questo proposito, ma so che la mia area (Tampa) Rails è essenzialmente inesistente.

4) Fuoco e movimento

Le guide sono in continua evoluzione. Questa è una cosa buona e una cattiva; è buono perché la comunità si evolve e abbraccia nuovi concetti. È male perché la comunità si evolve e abbraccia nuovi concetti. Può essere molto travolgente per un principiante di Rails perché di solito quando incontri un problema e ti guardi intorno, vedrai le persone raccomandare questo tipo di gemma per risolverlo o dire che comunque è male e non dovresti Usalo, ecco un modo migliore ... e finisci per avere una lista di strumenti aggiuntivi da imparare insieme a Rails per stare al passo con i cognoscenti Rails. Cose come Git , BDD/RSpec , Cucumber , Haml/Sass , e una cornucopia di altre cose tutte fluttuano intorno e vengono spinte come il "modo giusto di fare le cose" in Rails-land, e parlando per esperienza puoi finiscono per essere sommersi cercando di imparare una dozzina o più di tecnologie in aggiunta a Rails, perché usare il kit di strumenti standard di Rails sembra "sbagliato".

Questo è ulteriormente aggravato da Rails 3.1 che rende Sass e CoffeeScript di default, quindi un principiante di Rails non solo deve imparare Ruby e Rails ma Sass (probabilmente semplice se conosci CSS) e CoffeeScript (non pazzo difficile ma sicuramente abbastanza diverso da JavaScript grezzo) al minimo indispensabile per iniziare, in più si può presumere Git. Anche senza tener conto di RSpec e degli amici, e della dozzina o più gemme che tipicamente farai, è 4 cose diverse che devi imparare prima di poter seriamente iniziare a scrivere applicazioni Rails. Confronta questo con un linguaggio come C #, o Java, o anche PHP dove la tua conoscenza HTML / CSS / JavaScript / SQL non cambierà e devi solo imparare la lingua stessa e forse le sfumature del framework.

Documentazione.

Mentre le Guide per i rails sono una grande risorsa di apprendimento, il riferimento alle librerie Rails (e Ruby, in generale) non è facile da navigare. Di ', vuoi saperne di più sul metodo belongs_to . Sebbene sia utilizzato su sottoclassi ActiveRecord::Base (i propri modelli), non è documentato in ActiveRecord::Base documenti , ma in un mixin che la classe importa. In sostanza, non è possibile visualizzare un elenco completo di tutti i metodi che è possibile utilizzare su un oggetto in un'unica posizione (tranne quando si attiva irb e si verifica l'oggetto stesso).

Con un linguaggio altamente dinamico come Ruby, non è semplice dire da dove proviene un metodo che stai utilizzando. Può essere un problema, specialmente per l'apprendimento dei programmatori che cercano di afferrare un nuovo stack tecnologico.

Ruby on Rails ha una curva di apprendimento significativa. Per prima cosa devi imparare le stranezze della lingua, poi apprendere la struttura, quindi imparare il modo di fare le rotaie, quindi conoscere le molte gemme comunemente usate.

Tuttavia, quando hai imparato queste cose, è incredibilmente naturale. In effetti altri quadri cominciano a sentirsi come un peso.

Rails è molto orientato al TDD / BDD, quindi se non lo sei, allora devi imparare altre due cose prima di diventare un programmatore Rails competente. Non hai un compilatore e IDE per il backup, quindi la copertura del test è la tua riserva.

Molti sostenitori del TDD, me compreso, considererebbero questo uno dei punti di forza di RoR, così come la sua maledizione. Una volta che inizi a scrivere TDD, scopri che la sicurezza offerta dalla copertura del test è migliore della sicurezza offerta da un compilatore. Quindi dover scrivere il codice JUST per compiacere un compilatore diventa gravoso.

Il TDD non sembra un compito aggiuntivo in RoR, sembra l'unico modo per funzionare.

Le rotaie hanno un serio problema di prestazioni: ogni richiesta è in coda dietro quella attualmente attiva, anziché avviarle come fa la maggior parte dei framework o consentire agli eventi di blocco di liberare altre richieste come fanno Node.js e Twister. Ciò significa che devi codificare per rendere i tempi di risposta rapidi, ma è abbastanza facile da fare nella maggior parte dei casi.

Rails è anche progettato per gestire i sistemi di contenuti molto bene, che in tutta onestà è molto internet. Fare qualcosa di un po 'più complicato, come un gioco web o un sistema di e-commerce, significa imparare nuove gemme. Impari velocemente che tutte le gemme sono là fuori, ma più oscura la cosa che vuoi fare, più difficile sarà trovare una buona documentazione.

Nella mia esperienza personale, il mal di testa maggiore è intorno a compatibilità .

Quando:

• ci sono x progetti di rotaie distribuiti,
• ogni progetto utilizza y gems.
• mentre ci sono n versioni di rotaie,
• più m versioni di gems installate,
• con several versioni di ruby,
• su una singola macchina Linux come macchina di produzione.
• il programmatore funziona su un altro notebook di sviluppo OS X.

Come libero professionista, che non ha il lusso di aggiornare / aggiornare la maggior parte delle cose, dovrà affrontare molti problemi di compatibilità dalle variabili precedenti ... mentre rails , gems e ruby continua a cambiare / evolvere.

La velocità è sicuramente un problema. L'estrema flessibilità di Ruby si accompagna a un notevole calo delle prestazioni.

Il ridimensionamento orizzontale è un compito non ovvio, fatta eccezione per le tecnologie progettate specificamente per quell'attività, che di solito compensano la semplicità per adattarsi bene.
Se puoi gestire fino a 100 volte più richieste per macchina con tecnologia A che con tecnologia B, la tecnologia A è degna di considerazione se hai motivo di credere che puoi servire i tuoi dati da un singolo server per un intervallo di tempo che ti permetta di aggiungere parallelizzazione in seguito.
Nel 2009 lo stackoverflow era ancora pubblicato da un server web . Ovviamente questa non è più un'opzione. Ma suppongo che fosse positivo che iniziassero con una tecnologia che poteva scalare fino a un sacco di utenti su una singola istanza, prima che dovessero preoccuparsi di ridimensionare.

In confronto a ciò, RoR è molto lento. Il tempo di gestire richieste semplici è significativo e quindi è un problema gestire molti client (questo è tutto da vedere in relazione a alternative più veloci).

Per motivi di orientamento vago, qui ci sono alcuni numeri, confrontando varie altre lingue adatte per lo sviluppo web a Ruby:

• Vai
• Clojure
• JavaScript V8 (node.js )
• JRuby (un'alternativa da non dimenticare - a seconda sulla tua area problematica JRuby potrebbe essere una scelta migliore o peggiore per ottenere una certa velocità dall'app di un binario)
• Scala
• Java
• C #

Si noti che questo non significa che se si utilizza framework X per Java sarà esattamente 200 volte più veloce di RoR. Ma la differenza di velocità misurata in questi benchmark ha un impatto importante sulle prestazioni generali della tua app.

Rails has one serious performance problem: each request is queued up behind the currently active one, as opposed to threading them as most frameworks do or allowing blocking events to free other requests as the like of Node.js and Twister do. This means you have to code to make response times fast, but that's quite easy to do in most cases.

Penso che questo sia molto fuorviante. Puoi eseguire Rails in modalità multithread. Quando si esegue in modalità multithread, è necessario utilizzare solo librerie IO che rilasciano GIL (ad esempio, gemma 'mysql2') altrimenti diventa una sorta di inutile.

Se si utilizza jRuby, è possibile eseguire un processo a barre singole in modalità multithread e utilizzare completamente tutta la potenza disponibile della CPU. Tuttavia, se si utilizza la risonanza magnetica (Ruby 1.8.xo 1.9.x), è necessario eseguire più processi per utilizzare completamente le CPU, come nel caso di node.js.

• Rails ha molte sottigliezze che nascondono la tua complessità. (Associazioni ActiveRecord, l'intero ciclo di vita di validazione / risparmio, interpretazione dei dati delle richieste in base alle intestazioni fornite) Quando si sta appena iniziando, questo è fantastico. Man mano che cresci, scoprirai di iniziare ad adattare la tua app al modo "Rails" di gestire le cose - a volte questo è buono, a volte questo è innocuo, ea volte è in realtà contro-intuitivo a ciò che stai cercando di fare. Non tutte le tabelle del database dovrebbero essere modellate come oggetti, un passaggio di validazione potrebbe aver bisogno di accadere altrove, ecc. Molti programmatori di Rails evitano di combattere il framework (che di solito è saggio), ma l'effetto a lungo termine di questo è ... tu porterà le abitudini di Rails con te in luoghi dove non sono necessariamente richiesti.

• La comunità ha l'abitudine di scrivere software che viene etichettato come "magico" - librerie di cache che funzionano magicamente! Event I / O che ti rende magicamente più veloce! Magia magica! Ciò che solitamente accade qui è che viene fornita un'API molto attraente per una soluzione tecnica che è carente, e vieni ingannato dagli esempi molto carini che la cosa fa ciò che intendete e solo successivamente scoprirà che copre una soluzione incompleta. Il ciclo di questo è abbastanza costante, e impari a giocarci, ma dovresti sicuramente avere familiarità con l'idea di leggere un sacco di codice da cui dipendi (una buona cosa!). Le soluzioni magiche della community di Rails non sono così magiche come può suggerire il README,

• Corollario a sopra: più usi Rails, più dovresti leggere la sua fonte. Quanto meglio comprendi le strutture interne, tanto più felice sarai a lungo termine. Non proprio Rails specifico in questo, ma ti sto solo raccontando dall'esperienza qui. I nomi dei metodi a volte promettono qualcosa che in realtà non stai ricevendo.

• Il culto del carico è un problema con Rails, ma probabilmente è vero con tutte le comunità framework / lang. Sembra più pronunciato (per me) in Rails, e come tale tende a dare uno strano aspetto generazionale al codice Rails - mentre lavori su diversi progetti Rails, noterai certe tendenze che tendono a tradire il periodo di tempo in cui sono state create . Come si può intuire da questa affermazione, la comunità tende a muoversi abbastanza velocemente nell'adottare nuove soluzioni e deprecare quelle vecchie. Dovresti essere davvero al top delle tue notizie su Ruby, solo per capire parte del codice che sperimenterai quotidianamente.

• In generale, penso che la questione della concorrenza dei dati non venga affrontata dalla comunità in modo soddisfacente: quando sviluppi un'app, quando raggiungi il punto in cui devi ritagliare i dati, esegui il rollback delle modifiche fisicamente remote e blocca l'accesso per i dati, le soluzioni diventano un po 'più sintonizzate a mano, il che rende alcune delle cose Rails di bell'aspetto che si fanno confuse con le necessità tecniche dell'accuratezza. Rails non risolve tutti i problemi che avrai con una web app, suppongo lo stia dicendo, e mentre i creatori non predicano certamente quel messaggio, è facile lasciarsi ingannare nel pensare che sia implicito.

A seconda di come la si guarda, la velocità con cui le modifiche di Rails possono essere o non essere un avvertimento per te. Le cose cambiano in modo un po 'radicale da un anno all'altro, mentre più viene fuori da ciò che fa schifo e ha bisogno di soluzioni.

Se sei in sviluppo attivo, avrai comunque il polso dell'impulso.