Desvantagens e advertências do Ruby on Rails [fechado]


25

Esta não é uma aposta inicial para o RoR bashing - honesto!

Estou aprendendo Ruby e o framework Rails. Prima facie, parece ser bem legal e uma experiência maravilhosa em comparação com o PHP. (Na verdade, isso me lembra dias mais felizes com C # e .NET.)

No entanto, entrando nisso, não tenho experiência com essa estrutura ou linguagem e estou curioso - quais são as desvantagens atuais ou coisas que você gostaria que soubesse quando estava começando?

(Talvez isso deva ser um wiki da comunidade?)


Tentei trilhos uma vez e parei quando percebi que o design da primeira entidade do banco de dados não é facilmente possível.
Falcon

5
vale a pena ler avdi.org/devblog/2011/08/22/your-code-is-my-hell . Eu acrescentaria que, com qualquer linguagem de tipo dinâmico, é extremamente importante ter 80% ou mais de cobertura de teste, ou a refatoração será quase impossível.
Eric Wilson

Efectuar a sua pergunta mais específica e equilibrada (isto é, "Mudar de PHP para Ruby on Rails - Prós e Contras) eliminaria a necessidade de negar-se de contusão eo desejo de wiki comunidade.
Thomas Langston

2
@ Thomas Mas essa não é a minha pergunta! Os prós e contras do PHP são realmente bem conhecidos. Os profissionais do RoR são bastante fáceis de encontrar. No entanto, as desvantagens do RoR não são fáceis de descobrir como um recém-chegado e suspeito que elas só seriam descobertas com muitos anos de experiência. Aprender com a experiência merecida de outras pessoas é o objetivo disso. Muitos dos CWs que li são bastante específicos em sua natureza.
Matty

Respostas:


32

Isso se deve à experiência de aprender, continuar aprendendo e escrevendo um aplicativo relativamente simples no Rails.

1) Curva de Aprendizagem

O Rails é enganosamente simples. Os tutoriais, vídeos e livros demonstram a rapidez com que você pode obter um aplicativo funcional (embora feio), mas isso realmente arranha a superfície. Eles tendem a confiar fortemente na geração e no "andaime" de código, que é uma boa ferramenta para aprender, mas rapidamente sobrevive à sua utilidade.

Não se engane, é difícil dominar o Rails. Depois de passar pelo básico (mais sobre isso mais tarde), você se deparará com uma parede se precisar fazer mais do que a funcionalidade extremamente simplista do "aplicativo de demonstração" que você vê apresentada. Você pode se familiarizar com o conhecimento básico de Ruby enquanto aprende, mas rapidamente precisa buscá-lo ou ficará em seco (e não é o melhor DRY) se precisar sair das restrições do Rails.

O Rails é, como eu gosto de chamá-lo de maneira amorosa, pintar pela programação de números . Se você se apegar 100% às convenções (ou seja, permanecer dentro das linhas e usar as cores que você deve usar), poderá criar aplicativos decentes com rapidez e facilidade. Se e quando você tiver que se desviar, o Rails pode ir do seu melhor amigo ao seu pior inimigo.

2) Quando tudo que você tem é um martelo ...

O Rails faz aplicações CRUD simplistas muito bem. O problema ocorre quando seu aplicativo precisa fazer mais do que apenas ler / gravar em um banco de dados. Agora, para constar, a última versão do Rails que usei foi a 2.3.4, portanto as coisas podem ter mudado desde então, mas me deparei com grandes problemas quando os requisitos de negócios mudavam, de modo que o aplicativo precisava ter um pequeno sistema de fluxo de trabalho incorporado e integrar-se ao um aplicativo PHP herdado. A convenção do Rails de "um formulário, um modelo" funciona bem para aplicativos triviais e aplicativos de entrada de dados, mas não tanto quando você precisa fazer lógica de processamento ou ter fluxos de trabalho ou qualquer coisa que não seja típica "O usuário insere dados no alguns campos de texto, clica em Enviar ". Isso pode ser feito, mas não é de modo algum "fácil", ou melhor, não era '

Além disso, o Rails não gosta de jogar bem com outros aplicativos que não estão usando seus métodos preferidos de acesso a dados; se você precisar fazer interface com um aplicativo que não possui uma API no estilo "Web 2.0", precisará contornar o Rails, e não com ele; Mais uma vez falo por experiência própria, pois foi o que aconteceu comigo.

3) é novo

Por fim, o Rails ainda é o "novo garoto da quadra" em muitas áreas. Isso não importa para uso pessoal ou o tipo de cenário "Acho legal e quero aprender", mas falar como alguém que prefere usar o Rails no meu trabalho diário, se você não estiver em um local onde o Rails está generalizado, pode ser muito difícil encontrar trabalho em tempo integral como desenvolvedor do Rails. Ainda é em grande parte o domínio das "novas e modernas startups" e não é um participante importante na maioria das áreas metropolitanas. Sua milhagem pode variar nesse sentido, mas eu sei que a minha área (Tampa) Rails é essencialmente inexistente.

4) Fogo e Movimento

O Rails está sempre mudando. Isso é bom e ruim; é bom porque a comunidade evolui e adota novos conceitos. É ruim porque a comunidade evolui e abraça novos conceitos. Pode ser muito assustador para um novato do Rails, porque geralmente quando você se deparar com um problema e olhar em volta, verá pessoas recomendando tal e tal joia para corrigi-lo ou dizendo que isso é ruim de qualquer maneira e você não deveria ' Para usá-lo, aqui está uma maneira melhor ... e você acaba tendo uma lista completa de ferramentas adicionais para aprender junto com o Rails e acompanhar os conhecimentos do Rails. Coisas como Git, BDD/RSpec, Cucumber,Haml/Sass, e uma infinidade de outras coisas flutuam e são empurradas como o "caminho certo para fazer as coisas" em Rails-land. Falando por experiência própria, você pode acabar sendo inundado tentando aprender uma dúzia ou mais de tecnologias além do Rails, porque usar o kit de ferramentas padrão do Rails parece "errado".

Agora isso é ainda mais agravado pelo Rails 3.1, tornando o Sass e o CoffeeScript de todas as coisas o padrão, portanto, um novato total do Rails não apenas precisa aprender Ruby e Rails, mas também o Sass (sem dúvida simples, se você conhece CSS) e o CoffeeScript (não muito difícil, mas certamente diferente o suficiente do JavaScript bruto) no mínimo para começar, além disso, pode-se assumir o Git. Mesmo sem considerar o RSpec e os amigos, e as dezenas ou mais gemas com as quais você normalmente termina, são quatro coisas diferentes que você precisa aprender antes de começar a escrever aplicativos Rails a sério. Compare isso com uma linguagem como C #, Java ou PHP, onde o seu conhecimento em HTML / CSS / JavaScript / SQL não vai mudar e você só precisa aprender a própria linguagem e talvez as nuances da estrutura.


3
WRT Rails 3.1 Sass & CoffeeScript são padrões que podem ser facilmente desativados. De fato, o CSS "normal" funcionará porque o Rails 3.1 usa a sintaxe SCSS do SASS. Você poderia usá-los, mas não está sob nenhuma compulsão. WRT Git Acho que Linus explica melhor por que você realmente deve usar um DVCS como Git, independentemente da estrutura usada. youtube.com/watch?v=4XpnKHJAok8
Shreyas Satish

Oh eu concordo, apenas dizendo que o padrão Rails geralmente é sensacionalistas muito para um novato vai se sentir pressionado a usá-lo (eu sei que eu me senti assim)
Wayne Molina

3
+1 em # 4 ... se você deixar o Rails por um ano, quando voltar, todo mundo estará voando em espaçonaves e estará em seu barco a remo pensando em quê? A sintaxe do Rails 2 parecia antiga antes do lançamento do Rails 3.
precisa saber é o seguinte

-1 Bons trilhos batendo no post, mas você nem sugere uma alternativa. "Formulários aninhados" é um problema difícil e o Rails provavelmente o resolve melhor do que ninguém.
scottschulthess

13

Documentação.

Embora os Guias do Rails sejam ótimos recursos de aprendizado, a referência da biblioteca do Rails (e Ruby, geralmente) não é fácil de navegar. Digamos que você queira aprender mais sobre o belongs_tométodo. Embora seja usado nas ActiveRecord::Basesubclasses (modelos de alguém), não está documentado nos ActiveRecord::Basedocumentos, mas em um mix que a classe importa. Essencialmente, você não pode ver uma lista abrangente de todos os métodos que você pode usar em um objeto em um só lugar (exceto quando você inicia irbe verifica o próprio objeto).

Com uma linguagem altamente dinâmica como Ruby, não é fácil dizer de onde vem o método que você está usando. Pode ser um problema, especialmente para aprender programadores que tentam entender uma nova pilha de tecnologia.


Este é um assassino para mim; sempre que preciso depurar parte do nosso código Ruby / Rails, sempre gastei muito tempo tentando descobrir onde um determinado método foi definido; e mesmo assim, sempre tenho que manter a ideia na minha cabeça de que só porque eu consigo ver a definição do método, ela pode ter sido redefinida em outro lugar.
joev

9

O Ruby on Rails tem uma curva de aprendizado significativa. Primeiro você precisa aprender as esquisitices da linguagem, depois aprender o framework, depois aprender a maneira Rails de fazer as coisas, depois aprender sobre as muitas gemas usadas com freqüência.

No entanto, quando você aprendeu essas coisas, elas foram incrivelmente naturais. De fato, outras estruturas começam a parecer um fardo.

O Rails é muito orientado ao TDD / BDD, portanto, se você não for, mais duas coisas que você precisará aprender antes de se tornar um programador competente do Rails. Você não possui um compilador e IDEs para fazer backup de você, portanto, a cobertura do teste é muito sua alternativa.

Muitos defensores do TDD, inclusive eu, considerariam esse um dos pontos fortes do RoR, bem como sua maldição. Depois de começar a escrever TDD, você descobre que a segurança oferecida pela cobertura de teste é melhor que a segurança oferecida por um compilador. Então, ter que escrever o código APENAS para agradar um compilador se torna pesado.

O TDD não parece ser uma tarefa adicional no RoR, é a única maneira de trabalhar.

O Rails tem um sério problema de desempenho: cada solicitação é enfileirada atrás da ativa no momento, em vez de segmentá-las como a maioria das estruturas, ou permitir que eventos de bloqueio liberem outras solicitações, como o Node.js e o Twister. Isso significa que você precisa codificar para acelerar os tempos de resposta, mas isso é bastante fácil de fazer na maioria dos casos.

O Rails também foi projetado para lidar muito bem com sistemas de conteúdo, o que, para ser justo, é uma grande parte da Internet. Fazer algo um pouco mais complicado, como um jogo na web ou um sistema de comércio eletrônico, significa aprender novas jóias. Você aprende rapidamente que todas as jóias estão por aí, mas quanto mais obscura a coisa que você quer fazer, mais difícil será encontrar uma boa documentação.


Quanto aos problemas de desempenho - lembro-me de ler que muitos deles foram amplamente resolvidos com a v1.9 do intérprete, mas eu poderia estar completamente errado. Existem maneiras de superar essa limitação de desempenho?
Matty

1
@ Matty: Como adicionei, codifique para tornar os tempos de resposta o mais rápido possível. Qualquer coisa que possa ser deixada em um processo de back-end, faça-o. Mas você deve fazer isso com qualquer estrutura - é fácil não fazer isso. Além disso, o jRuby é encadeado de maneira diferente, mas ele vem com seus próprios problemas e minha resposta já foi longa.
Pd 29/08

7

Na minha experiência pessoal, a principal dor de cabeça está relacionada à compatibilidade .

Quando:

  • existem xprojetos rails implantados,
  • cada projeto usa ygemas.
  • enquanto existem nversões de trilhos,
  • além de mversões de gemas instaladas,
  • com severalversões de rubi,
  • em uma única caixa Linux como máquina de produção.
  • o programador trabalha em outro notebook de desenvolvimento OS X.

Como freelancer, que não tem o luxo de atualização / upgrade a maioria das coisas, vai enfrentar uma série de problemas de compatibilidade de variáveis acima ... enquanto rails, gemse rubyficar mudando / evolução.


7
Tudo o que você mencionou foi corrigido usando o RVM (ou rbenv ) e o Bundler . Você pode ter versões específicas do Ruby e conjuntos isolados de gemas para cada projeto.
Ashley Williams

Esta resposta é (agora) totalmente irrelevante. RVM para gerenciar versão Ruby, Bundler para lidar com versão gem; Capistrano para lidar com implantações no servidor de produção e o Figaro cuida dos segredos dos aplicativos / variáveis ​​de ambiente. Desenvolvo meu aplicativo no [Cloud9] (c9.io) (um IDE da web) e meu processo de implantação é literalmente bundle exec cap production deploy. Capistrano cuida da versão do aplicativo no servidor. Como qualquer outra estrutura que sai (por exemplo, Node.js), as ferramentas são escritas para resolver seus problemas .
Chris Cirefice

5

Velocidade definitivamente é um problema. A extrema flexibilidade do Ruby vem com um impacto significativo no desempenho.

Escalar horizontalmente é uma tarefa não óbvia, exceto para as tecnologias projetadas especificamente para essa tarefa, que geralmente trocam a simplicidade por uma escala adequada.
Se você pode gerenciar 100 vezes mais solicitações por máquina com a tecnologia A do que com a tecnologia B, vale a pena considerar o uso da tecnologia A se você tiver motivos para acreditar que pode servir seus dados em um único servidor por um período que permita adicionar paralelização depois.
Em 2009, o stackoverflow ainda era servido em um servidor web . Claro que isso não é mais uma opção. Mas suponho que foi bom que eles tenham começado com uma tecnologia que pudesse escalar muitos usuários em uma única instância, antes que eles precisassem se preocupar com a expansão.

Comparado a isso, o RoR é realmente lento. O tempo para lidar com solicitações simples é significativo e, portanto, é um problema para lidar com muitos clientes (tudo isso pode ser visto em relação a alternativas mais rápidas).

Por uma vaga orientação, aqui estão alguns números, comparando vários outros idiomas adequados para o desenvolvimento da Web com o Ruby:

  • Vai
  • Clojure
  • JavaScript V8 ( node.js )
  • JRuby (uma alternativa a não ser esquecida - dependendo da sua área problemática, o JRuby pode ser uma opção melhor ou pior para obter alguma velocidade em um aplicativo de trilhos)
  • Scala
  • Java
  • C #

Observe que isso não significa que, se você usar o framework X para Java, ele será exatamente 200 vezes mais rápido que o RoR. Mas a diferença de velocidade medida nesses benchmarks tem um impacto importante no desempenho geral do seu aplicativo.


4
Esta resposta fala apenas sobre "velocidade" em tempo de execução. Ruby (e Rails) é otimizado para velocidade de desenvolvimento.
Nicolai Reuschling

5
Esta não é uma boa comparação. A maior parte do tempo gasto em uma solicitação da Web realiza E / S no banco de dados. Vincular a benchmarks com uso intensivo de CPU é enganoso.
ryeguy

3
@pdr: Muitos dos problemas do twitter eram que eles usavam ruby ​​para tudo , até mesmo para os processos de back-end que eram intensivos em CPU. Áreas como essa são as línguas de tipo estaticamente brilham. Eles usam Scala para isso agora. Sinceramente, acredito sinceramente que o uso do RoR é muito mais rápido em termos de tempo de desenvolvimento do que o C # ou Java. Eu o usaria na maior parte do aplicativo Web e, em seguida, usaria C # ou Scala para qualquer trabalho em segundo plano intensivo da CPU.
ryeguy

3
+1, para pontos válidos. Dito isto, você pode fazer muito para otimizar os aplicativos Rails. O rack se presta a ser um sistema bastante extensível que permite muita flexibilidade na forma como tudo é chamado. Sem mencionar, o Ruby 1.9 é mais rápido, o JRuby é mais rápido. Eu, pessoalmente, sou um grande fã do JRuby, sendo capaz de misturar o poder do JVM é uma vitória maravilhosa (só tome cuidado de gemas que usam exceções para controle de fluxo -> sobrecarga enorme)
Xorlev

2
@Nicolai Reuschling: Qual o valor do Ruby ou RoR sendo "otimizado para a velocidade de desenvolvimento"? Você pode fornecer dados quantitativos e verificáveis como o Ruby realmente oferece maior velocidade de desenvolvimento do que as alternativas (Lift, por exemplo)? Qualquer outra coisa é apenas uma reivindicação nula. Além disso, essa pergunta era sobre desvantagens de RoR . A alta velocidade de desenvolvimento é uma vantagem e, portanto, está fora do escopo desta questão. O desempenho ruim do tempo de execução está dentro do escopo desta pergunta, porque é uma desvantagem.
Aug2

3

O Rails tem um sério problema de desempenho: cada solicitação é enfileirada atrás da ativa no momento, em vez de segmentá-las como a maioria das estruturas, ou permitir que eventos de bloqueio liberem outras solicitações, como o Node.js e o Twister. Isso significa que você precisa codificar para acelerar os tempos de resposta, mas isso é bastante fácil de fazer na maioria dos casos.

Eu acho que isso é muito errado. Você pode executar o Rails no modo multithread. Ao executar no modo multithread, você deve usar apenas bibliotecas IO que liberam o GIL (por exemplo, gem 'mysql2'), caso contrário ele se torna meio inútil.

Se você estiver usando o jRuby, poderá executar um único processo de trilhos no modo multithread e utilizar totalmente toda a energia da CPU disponível. No entanto, se você usa MRI (Ruby 1.8.x ou 1.9.x), é necessário executar vários processos para utilizar totalmente as CPUs, como também o node.js.


Uma pergunta de esclarecimento aqui - existe uma maneira fácil de descobrir quais bibliotecas de E / S lançam o GIL?
Matty

Eu acho que a melhor maneira de descobrir isso é benchmark gist.github.com/35d4769d8c8c0dfafc56
Pratik Naik


É bom ouvir de um dos principais desenvolvedores! Esta informação não está listada em nenhuma documentação, não é? É um pouco tedioso (embora seja uma atividade interessante) começar a testar as bibliotecas para descobrir isso.
Matty

3
  • O Rails possui muitas sutilezas que escondem a complexidade de você. (Associações do ActiveRecord, todo o ciclo de vida de validação / salvamento, interpretação dos dados da solicitação com base nos cabeçalhos fornecidos) Quando você está apenas começando, isso é incrível. À medida que cresce, você descobre que começa a ajustar seu aplicativo à "maneira Rails" de lidar com as coisas - às vezes isso é bom, às vezes é inofensivo e às vezes é realmente contra-intuitivo para o que você está tentando fazer. Nem todas as tabelas de banco de dados devem ser modeladas como objetos, talvez uma etapa de validação ocorra em outro lugar etc. Muitos programadores de Rails evitam não combater o framework (o que geralmente é sensato), mas o efeito a longo prazo disso é ... você levará consigo os hábitos do Rails para lugares onde eles não são necessariamente necessários.

  • A comunidade tem o hábito de escrever um software chamado de "mágica" - armazenando em cache as bibliotecas que funcionam magicamente! E / S registrada que magicamente o torna mais rápido! Magia mágica! O que geralmente acontece aqui é que uma API muito atraente é fornecida para uma solução técnica que está faltando, e você é enganado pelos exemplos muito bonitos de que a coisa faz o que você pretende e só depois descobre que ela cobre uma solução incompleta. O ciclo disso é bastante constante e você aprende a segui-lo, mas definitivamente deve se familiarizar com a ideia de ler muitos e muitos códigos dos quais você depende (uma coisa boa!). As soluções mágicas da comunidade Rails não são tão mágicas quanto o README pode sugerir, estou dizendo.

  • Corolário acima: Quanto mais você usa o Rails, mais deve ler sua fonte. Quanto melhor você entender as estruturas internas da estrutura, mais feliz será a longo prazo. Não é realmente o Rails específico nisso, mas estou falando apenas da experiência aqui. Às vezes, nomes de métodos prometem algo que você realmente não está recebendo.

  • O cultismo de carga é um problema com o Rails, mas isso provavelmente é verdade com todas as comunidades framework / lang. Parece mais pronunciado (para mim) no Rails e, como tal, tende a dar uma aparência geracional estranha ao código do Rails - ao trabalhar em diferentes projetos do Rails, você notará certas tendências que tendem a trair o período de tempo em que foram criados . Como você pode adivinhar a partir dessa afirmação, a comunidade tende a avançar muito rapidamente ao adotar novas soluções e reprovar as antigas. Você realmente deve estar em dia com as notícias do Ruby, apenas para entender parte do código que você experimenta diariamente.

  • De um modo geral, acho que o problema da simultaneidade de dados geralmente não é bem tratado pela comunidade - à medida que você cresce um aplicativo, quando chega ao ponto em que precisa compartilhar dados, reverter alterações fisicamente remotas e bloquear o acesso aos dados, as soluções se tornam um pouco mais ajustado à mão, o que faz com que algumas das coisas bonitas do Rails que você faz se confundam com as necessidades técnicas de precisão. O Rails não resolve todos os problemas que você terá com um aplicativo da web, acho que estou dizendo, e enquanto os criadores certamente não pregam essa mensagem, é fácil ser enganado ao pensar que está implícito.


2

Dependendo de como você olha para ele, a velocidade com que o Rails muda pode ou não ser uma advertência para você. As coisas mudam de maneira um tanto radical de ano para ano, à medida que mais coisas surgem do que é ruim e precisa de soluções.

No entanto, se você estiver em desenvolvimento ativo, terá o dedo no pulso disso.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.