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

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

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

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

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

Это из опыта обучения, продолжения обучения и написания относительно простого приложения на 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 не изменятся, и вам просто нужно изучить сам язык и, возможно, нюансы инфраструктуры.

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

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

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

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

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

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

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

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

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

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

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

Когда:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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