Ruby on Rails недостатки и предостережения [закрыто]

25

Это не вводный гамбит для избиения RoR - честно!

Я изучаю Ruby и Rails Framework. На первый взгляд, это довольно круто, и это замечательный опыт по сравнению с PHP. (На самом деле, это напоминает мне о более счастливых днях с C # и .NET.)

Однако, углубляясь в это, у меня нет опыта работы с этой платформой или языком, и мне любопытно - каковы текущие недостатки или вещи, которые вы хотели бы знать, когда вы начинали?

(Может быть, это должно быть сделано сообществом вики?)

Мэтти
источник
Я попробовал рельсы один раз и остановился, когда понял, что проектирование сущностей в первую очередь невозможно.
Сокол
5
avdi.org/devblog/2011/08/22/your-code-is-my-hell стоит прочитать. Я бы добавил, что с любым динамически типизированным языком крайне важно иметь 80% или более тестовое покрытие, иначе рефакторинг будет практически невозможен.
Эрик Уилсон
Если сделать ваш вопрос более конкретным и сбалансированным (например, «Переключение с PHP на Ruby on Rails - за и против»), то это избавит вас от необходимости отречься от избиения и от вики в сообществе.
Томас Лэнгстон,
2
@ Томас Но это не мой вопрос! Плюсы и минусы PHP действительно хорошо известны. Профессионалы RoR довольно легко найти. Тем не менее, минусы RoR не так легко обнаружить, как новичка, и я подозреваю, что они будут обнаружены только с многолетним опытом. Обучение на заслуженном опыте других является целью этого. Многие из CW, которые я читал, довольно специфичны по своей природе.
Мэтти

Ответы:

32

Это из опыта обучения, продолжения обучения и написания относительно простого приложения на Rails.

1) Кривая обучения

Rails обманчиво прост. Все учебные пособия, видео и книги демонстрируют, как быстро вы можете получить работающее (хотя и некрасивое) приложение, но на самом деле это просто царапина. Они имеют тенденцию в значительной степени полагаться на генерацию кода и «строительные леса», которые, по общему признанию, являются хорошим инструментом при обучении, но быстро изживают его полезность.

Не заблуждайтесь, Rails сложно освоить. Как только вы пройдете самые основы (подробнее об этом позже), вы будете стремительно бегать в стену, если вам нужно сделать больше, чем чрезвычайно упрощенную функциональность «демо-приложения», которую вы видите рекламируемой. Вы можете получить базовые знания по Ruby во время обучения, но вам нужно быстро освоить Ruby, иначе вы останетесь безучастными (и не очень хорошими DRY), если вам нужно выйти за пределы ограничений Rails.

Rails, как я люблю называть это любовью, рисует программирование чисел . Если вы придерживаетесь 100% соглашений (то есть придерживаетесь линий и используете цвета, которые вам говорят), вы можете быстро и легко создавать достойные приложения. Если и когда вам придется отклониться, Rails может перейти от вашего лучшего друга к вашему злейшему врагу.

2) Когда все, что у тебя есть, это молот ...

Rails очень хорошо делает упрощенные CRUD-приложения. Проблема возникает, когда ваше приложение должно делать больше, чем просто чтение / запись из базы данных. Теперь, для записи, последняя версия Rails, которую я использовал, была 2.3.4, так что с тех пор все могло измениться, но я столкнулся с серьезными проблемами, когда изменились бизнес-требования, поэтому приложение должно было иметь небольшую систему рабочего процесса и интегрироваться с устаревшее PHP-приложение. Соглашение Rails «одна форма, одна модель» прекрасно работает для тривиальных приложений и приложений ввода данных, но не так много, когда вам нужно выполнить логику обработки, или иметь рабочие процессы, или что-то, что не является типичным «Пользователь вводит данные в несколько текстовых полей, нажмите «Отправить». Это может быть сделано, но это ни в коем случае не "легко", или, скорее, не было

Кроме того, Rails не любит хорошо играть с другими приложениями, которые не используют свои предпочтительные методы доступа к данным; если вам приходится взаимодействовать с приложением, у которого нет API в стиле «Web 2.0», вам придется работать с Rails, а не с ним; Я снова говорю из опыта здесь, как это то, что случилось со мной.

3) это ново

Наконец, Rails по-прежнему остается «новым ребенком на блоке» во многих областях. Это не имеет значения для личного использования или для сценариев типа «я думаю, что это круто и я хочу изучать это», но выступаю как человек, который предпочел бы использовать Rails на моей повседневной работе, если вы не находитесь в месте, где находится Rails Широко распространено, может быть очень трудно найти полную занятость как разработчик Rails. Это по-прежнему в значительной степени область "модных, новых стартапов" и не крупный игрок в большинстве мегаполисов. Ваш пробег может варьироваться в этом отношении, но я знаю, что в моем районе (Тампа) Rails практически не существует.

4) Огонь и Движение

Рельсы постоянно меняются. Это и хорошо, и плохо; это хорошо, потому что сообщество развивается и принимает новые концепции. Это плохо, потому что сообщество развивается и принимает новые концепции. Это может быть очень подавляющим для новичка в Rails, потому что, как правило, когда вы сталкиваетесь с проблемой и осматриваетесь, вы увидите, что люди рекомендуют такой-то и такой-то драгоценный камень, чтобы исправить ее, или говорят, что это плохо в любом случае, и вы не должны Если использовать его, вот лучший способ ... и вы получите список дополнительных инструментов для изучения вместе с Rails, чтобы не отставать от Rails cognoscenti. Такие вещи, как Git, и рог изобилия других вещей все плавают вокруг и выдвигаются как «правильный способ сделать вещи» в Rails-Land,BDD/RSpec , Cucumber,Haml/Sassк тому же к Rails, потому что использование стандартного инструментария Rails кажется «неправильным».

Теперь это еще больше усугубляется Rails 3.1, что делает Sass и CoffeeScript всеми вещами по умолчанию, поэтому новичок в Rails должен не только изучать Ruby и Rails, но и Sass (возможно, простой, если вы знаете CSS) и CoffeeScript (не безумно сложно, но, безусловно, достаточно отличается от исходного JavaScript) как минимум, чтобы начать, плюс можно предположить, Git. Даже без учета RSpec и друзей, а также дюжины или более драгоценных камней, которые вы обычно получите, это 4 разные вещи, которые вы должны выучить, прежде чем вы сможете серьезно начать писать приложения на Rails. Сравните это с языком, таким как C #, Java или даже PHP, где ваши знания HTML / CSS / JavaScript / SQL не изменятся, и вам просто нужно изучить сам язык и, возможно, нюансы инфраструктуры.

Уэйн Молина
источник
3
WRT Rails 3.1 Sass & CoffeeScript - это настройки по умолчанию, которые легко отключить. На самом деле «нормальный» CSS будет просто работать, так как Rails 3.1 использует синтаксис SCSS SASS. Вы можете использовать их, но вы не под принуждением. WRT Git Я думаю, что Линус лучше объясняет, почему вы действительно должны использовать DVCS, как Git, независимо от того, какую платформу вы используете. youtube.com/watch?v=4XpnKHJAok8
Shreyas Satish
О, я согласен, просто говорю, что по умолчанию в Rails часто происходит много шумихи, поэтому новичок будет испытывать давление при его использовании (я знаю, что так и чувствовал)
Уэйн Молина,
3
+1 за # 4 ... если вы покинете Rails на год, когда вы вернетесь, все будут летать на космических кораблях, и вы будете в своей гребной лодке, думая о чем-то вроде? Синтаксис Rails 2 ощущался старым до выхода Rails 3.
jimworm
-1 Хороший пост рельсов, но вы даже не предлагаете альтернативы. «Вложенные формы» - сложная проблема, и Rails, вероятно, решает ее лучше, чем кто-либо другой.
scottschulthess
13

Документация.

Хотя Rails Guides - отличный учебный ресурс, справочник по Rails (и Ruby, как правило) не так прост в навигации. Скажем, вы хотите узнать больше о belongs_toметоде. Хотя он используется в ActiveRecord::Baseподклассах (своих моделях), он документируется не в ActiveRecord::Baseдокументах, а в миксинах, которые импортирует класс. По сути, вы не можете видеть исчерпывающий список всех методов, которые вы можете использовать для объекта в одном месте (кроме случаев, когда вы запускаете irbи проверяете сам объект).

С таким динамическим языком, как Ruby, непросто сказать, откуда берется метод, который вы используете. Это может быть проблемой, особенно для обучающихся программистов, пытающихся понять новый технологический стек.

Младен Ябланович
источник
Это убийца для меня; всякий раз, когда мне нужно отладить некоторый наш код Ruby / Rails, я всегда тратил слишком много времени, пытаясь выяснить, где был определен данный метод; и даже тогда, всегда нужно держать мысль в затылке, что просто потому, что я вижу определение метода, оно могло быть переопределено в другом месте.
Джоев
9

Ruby on Rails имеет значительную кривую обучения. Сначала вы должны изучить странности языка, затем изучить фреймворк, затем изучить Rails Способ выполнения вещей, а затем узнать о многих часто используемых Gems.

Однако, когда вы узнали эти вещи, это происходит невероятно естественно. На самом деле другие структуры начинают ощущаться как бремя.

Rails очень ориентирован на TDD / BDD, так что если нет, то вам нужно изучить еще две вещи, прежде чем стать компетентным программистом Rails. У вас нет компилятора и IDE для резервного копирования, поэтому тестовое покрытие - ваш запасной вариант.

Многие защитники TDD, включая меня, считают это одной из сильных сторон RoR, а также ее проклятием. Как только вы начинаете писать TDD, вы обнаруживаете, что безопасность, обеспечиваемая тестовым покрытием, лучше, чем безопасность, предлагаемая компилятором. Тогда необходимость писать код просто, чтобы угодить компилятору, становится обременительной.

TDD не кажется дополнительной задачей в RoR, это единственный способ работы.

У Rails есть одна серьезная проблема с производительностью: каждый запрос ставится в очередь позади активного в данный момент, в отличие от многопоточности, как это делают большинство фреймворков, или разрешения блокирования событий для освобождения других запросов, как это делают Node.js и Twister. Это означает, что вам нужно написать код, чтобы сократить время отклика, но в большинстве случаев это довольно просто сделать.

Rails также очень хорошо спроектирован, чтобы очень хорошо обрабатывать контент-системы, что, честно говоря, очень много в Интернете. Делать что-то немного более сложное, например, веб-игру или систему электронной коммерции, означает изучение новых драгоценных камней. Вы быстро узнаете, что все драгоценные камни существуют, но чем более непонятна вещь, которую вы хотите сделать, тем сложнее будет найти хорошую документацию.

прецизионный самописец
источник
Что касается проблем с производительностью - я, кажется, вспоминаю, что читал, что многие из них были в основном решены с помощью v1.9 интерпретатора, но я могу быть совершенно неправ. Есть ли способы преодолеть это ограничение производительности?
Мэтти
1
@Matty: как я добавил, код, чтобы сделать время отклика как можно быстрее. Все, что можно оставить бэкэнд-процессу, сделайте это. Но тогда вы должны сделать это с любой структурой - это просто не сделать. Кроме того, jRuby работает по-другому, но у него есть свои проблемы, и мой ответ уже был достаточно длинным.
фунтовые
7

По моему личному опыту, главная головная боль связана с совместимостью .

Когда:

  • есть xразвернутые рельсовые проекты,
  • каждый проект использует yдрагоценные камни.
  • в то время как есть nверсии рельсов,
  • плюс установленные mверсии драгоценных камней,
  • с severalверсиями ruby,
  • на одной коробке Linux в качестве рабочей машины.
  • программист работает на другом ноутбуке для разработки под OS X

Как фрилансер, который не имеет роскошь для обновления / обновления большинства вещей, столкнется много проблем совместимости с выше переменных ... в то время rails, gemsи rubyсохранить изменения / эволюционирует.

ohho
источник
7
Все, что вы упомянули, исправлено с помощью RVM (или rbenv ) и Bundler . Тогда вы можете иметь конкретные версии Ruby и изолированные наборы гемов для каждого проекта.
Эшли Уильямс
Этот ответ (сейчас) совершенно не имеет значения. RVM для управления версиями Ruby, Bundler для управления версиями gem; Capistrano обрабатывает развертывания на производственном сервере, а Figaro заботится о секретах приложений / переменных среды. Я разрабатываю свое приложение на [Cloud9] (c9.io) (веб-IDE), и мой процесс развертывания буквально bundle exec cap production deploy. Capistrano заботится о создании версий приложения на сервере. Как и любой другой фреймворк (например, Node.js), инструменты написаны для решения ваших проблем .
Крис Cirefice
5

Скорость определенно является проблемой. Чрезвычайная гибкость Ruby сопровождается значительным ударом по производительности.

Горизонтальное масштабирование - неочевидная задача, за исключением технологий, специально разработанных для этой задачи, которые обычно компенсируют простоту для хорошего масштабирования.
Если вы можете обрабатывать в 100 раз больше запросов на машину с технологией A, чем с технологией B, использование технологии A стоит рассмотреть, если у вас есть основания полагать, что вы можете обслуживать данные с одного сервера в течение периода времени, позволяющего добавлять распараллеливание потом.
В 2009 стек-поток все еще обслуживался с одного веб-сервера . Конечно, это больше не вариант. Но я полагаю, было хорошо, что они начали с технологии, которая может масштабироваться до большого количества пользователей за один раз, прежде чем им придется беспокоиться о масштабировании.

По сравнению с этим RoR действительно медленный. Время для обработки простых запросов является значительным, и, следовательно, это проблема для многих клиентов (это все можно увидеть в отношении более быстрых альтернатив).

Для неясной ориентации вот несколько цифр, сравнивающих различные другие языки, подходящие для веб-разработки, с Ruby:

  • Идти
  • Clojure
  • JavaScript V8 ( node.js )
  • JRuby (альтернатива, которую нельзя забывать - в зависимости от вашей проблемной области JRuby может быть лучшим или худшим выбором, чтобы получить некоторую скорость из приложения rails)
  • Scala
  • Джава
  • C #

Обратите внимание, что это не означает, что если вы используете Framework X для Java, это будет ровно в 200 раз быстрее, чем RoR. Но разница в скорости, измеренная в этих тестах, оказывает важное влияние на общую производительность вашего приложения.

back2dos
источник
4
Этот ответ говорит только о «скорости» во время выполнения. Ruby (и Rails) оптимизирован для скорости разработки.
Николай Рейшлинг
5
Это не очень хорошее сравнение. Большую часть времени, проводимого в веб-запросах, выполняет ввод-вывод из базы данных. Ссылка на процессорные тесты вводит в заблуждение.
ryeguy
3
@pdr: Многие проблемы Твиттера именно они использовали рубин для всего , даже их серверных процессов , которые были ресурсоемкими. Такие области как статически типизированные языки сияют. Для этого они используют Scala. Я, честно говоря, действительно считаю, что использование RoR намного быстрее с точки зрения времени разработки, чем C # или Java. Я хотел бы использовать его для большинства веб-приложений, а затем использовать C # или Scala для любых фоновых заданий, интенсивно использующих процессор.
ryeguy
3
+1, за действительные баллы. При этом вы можете многое сделать для оптимизации приложений на Rails. Rack предоставляет себя в качестве довольно расширяемой системы, которая обеспечивает большую гибкость в том, как все вызывается. Не говоря уже о том, что Ruby 1.9 быстрее, а JRuby быстрее. Лично я большой поклонник JRuby, возможность смешивать мощь JVM - замечательная победа (просто будьте осторожны с драгоценными камнями, которые используют исключения для управления потоком -> огромные накладные расходы)
Xorlev
2
@Nicolai Reuschling: Какое значение имеет то, что Ruby или RoR «оптимизированы для скорости разработки»? Можете ли вы предоставить проверяемые , количественные данные , как рубин на самом деле обеспечивает более высокую скорость разработки , чем альтернативные (Lift, например)? Все остальное - пустая претензия. Кроме того , этот вопрос был про RoR минусы . Высокая скорость разработки является преимуществом и, следовательно, выходит за рамки этого вопроса. Низкая производительность во время выполнения находится в рамках этого вопроса, потому что это недостаток.
back2dos
3

У Rails есть одна серьезная проблема с производительностью: каждый запрос ставится в очередь позади активного в данный момент, в отличие от многопоточности, как это делают большинство фреймворков, или разрешения блокирования событий для освобождения других запросов, как это делают Node.js и Twister. Это означает, что вам нужно написать код, чтобы сократить время отклика, но в большинстве случаев это довольно просто сделать.

Я думаю, что это очень ошибочно. Вы можете запустить Rails в многопоточном режиме. При работе в многопоточном режиме вы должны использовать только библиотеки ввода-вывода, которые выпускают GIL (например, «mysql2» gem), иначе это становится бессмысленным.

Если вы используете jRuby, то вы можете просто запустить один процесс rails в многопоточном режиме и полностью использовать всю доступную мощность процессора. Однако, если вы используете MRI (Ruby 1.8.x или 1.9.x), вы должны запустить несколько процессов, чтобы полностью использовать ЦП, как и в случае с node.js.

Притик Наик
источник
Уточняющий вопрос - есть ли простой способ найти, какие библиотеки ввода-вывода выпускают GIL?
Мэтти
Я думаю, что лучший способ выяснить это - сравнить
Пратик
Другой пример github.com/brianmario/mysql2/blob/master/benchmark/…
Пратик Наик
Приятно слышать от одного из основных разработчиков! Эта информация не указана ни в одной документации, не так ли? Это немного утомительно (хотя и интересно) начинать тестирование библиотек, чтобы выяснить это.
Мэтти
3
  • В Rails есть много тонкостей, которые скрывают от вас сложность. (Связи ActiveRecord, весь жизненный цикл проверки / сохранения, интерпретация данных запроса на основе предоставленных заголовков) Когда вы только начинаете, это потрясающе. По мере роста вы обнаружите, что начинаете приспосабливать свое приложение к «подходу Rails» к обработке вещей - иногда это хорошо, иногда это безвредно, а иногда это фактически противоречит тому, что вы пытаетесь сделать. Не все таблицы базы данных должны быть смоделированы как объекты, шаг проверки может потребоваться в другом месте и т. Д. Многие программисты Rails избегают борьбы с фреймворком (что обычно разумно), но долгосрочный эффект этого ... вы будет нести привычки Rails с вами в местах, где они не обязательно необходимы.

  • У сообщества есть привычка писать программное обеспечение, которое считается «волшебным» - кэширование библиотек, которые волшебным образом работают! Evented I / O, который волшебным образом делает вас быстрее! Магия магия! В данном случае обычно используется очень привлекательный API для технического решения, в котором отсутствует техническое решение, и вы обмануты очень красивыми примерами того, что эта вещь делает то, что вы намереваетесь, и только позже обнаруживаете, что она охватывает неполное решение. Цикл этого довольно постоянен, и вы научитесь работать с ним, но вам определенно следует ознакомиться с идеей чтения большого и большого количества кода, от которого вы зависите (хорошо!). Я говорю, что магические решения сообщества Rails далеко не так волшебны, как может предположить README.

  • Следствие выше: чем больше вы используете Rails, тем больше вы должны читать его источник. Чем лучше вы понимаете основы, тем счастливее вы будете в долгосрочной перспективе. Не совсем Rails конкретно в этом, но я просто говорю вам из опыта здесь. Имена методов иногда обещают то, чего вы на самом деле не получаете.

  • Грузовой культизм - это проблема с Rails, но это, вероятно, верно для всех сообществ framework / lang. Это кажется более выраженным (для меня) в Rails, и, как таковое, имеет тенденцию давать странный взгляд на код Rails - когда вы работаете над различными проектами Rails, вы заметите определенные тенденции, которые склонны предавать период времени, в котором они были созданы , Как вы можете догадаться из этого заявления, сообщество стремится довольно быстро внедрять новые решения и отвергать старые. Вы действительно должны быть в курсе ваших новостей по Ruby, просто для того, чтобы понять код, с которым вы будете сталкиваться ежедневно.

  • Вообще говоря, я думаю, что проблема параллелизма данных обычно не решается сообществом - когда вы расширяете приложение, когда вы попадаете в точку, где вам нужно защитить данные, откатить физически удаленные изменения и заблокировать доступ к данным, решения становятся немного больше ручной настройки, что делает некоторые из приятных на вид вещей Rails, которые вы делаете, запутанными с техническими потребностями точности. Я полагаю, что Rails не решает всех проблем, которые возникают у вас с веб-приложением, и хотя создатели, конечно, не проповедуют это сообщение, его легко обмануть, думая, что оно подразумевается.

NetShade
источник
2

В зависимости от того, как вы на это смотрите, скорость, с которой меняется Rails, может быть или не быть предостережением для вас. Вещи меняются несколько радикально из года в год, поскольку все больше и больше извлекается из того, что отстой и нуждается в решениях.

Если вы находитесь в активной разработке, вы будете держать руку на пульсе.

Xorlev
источник