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

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?)

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.

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.

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.

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.

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.

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.

• 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.

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.