Какой (если есть) технический долг я беру на себя с Ruby on Rails?

Question

Я большой поклонник ruby ​​на рельсах, и он, похоже, включает в себя многие из "лучших хитов" методов программирования веб-приложений. В частности, соглашение о конфигурации - большая победа.

Однако у меня также есть ощущение, что некоторые из удобств, которые я получаю, достигаются за счет технического долга , который необходимо будет погасить в будущем. Дело не в том, что я считаю ROR быстрым и грязным, так как я думаю, что во многих случаях он включает в себя множество лучших практик и хороших опций по умолчанию. Тем не менее, мне кажется, что некоторые вещи просто еще не охватываются (в частности, в фреймворке почти нет прямой поддержки безопасности, а плагины, которые я видел, имеют переменное качество).

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

Answer 1

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

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

Answer 2

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

Помимо проблем безопасности, еще одной большой проблемой является РАЗВЕРТКА на общих хостах. PHP процветает в среде общего хостинга, но Rails все еще отстает.

Конечно, большинство профессиональных разработчиков на Rails знают, что их приложениям нужны хорошо настроенные серверы для производства, и они, очевидно, будут развертываться на хостах, специфичных для Rails.

Чтобы Rails продолжил успешную работу, основная команда должна решить эту проблему, особенно с появлением Rails 3.0 (Merb + Rails) ..

Пример этого прост: у меня есть учетная запись bluehost, и я заметил значок Rails в моей cpanel. Я говорил с поддержкой bluehost, и они сказали, что это более или менее фиктивный значок, и что он не работает должным образом.

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

Answer 3

Я читаю Развертывание Rails-приложений и очень рекомендую ответить на ваши вопросы.

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

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

30-страничная глава об общих хостах содержит советы по квотированию памяти, такие как использование нескольких учетных записей (если возможно) с одним приложением Rails на учетную запись. Он также предупреждает о том, что популярные библиотеки, такие как RMagick, могут подтолкнуть ваш объем памяти к точке, где ваши процессы будут убиты (например, ограничение в 100 МБ, которое периодически предлагается некоторыми хостами).

Answer 4

При любом уровне абстракции вы платите немного - обобщенные методы работают не так быстро, как специфичные для чего-то, созданного специально для вашей цели. К счастью, у вас все в порядке, чтобы измениться. Не нравятся планы запросов, которые исходят из методов динамического поиска? написать свой собственный, хорошо идти.

Кто-то из вышеперечисленных сказал: «Оборудование дешевле, чем разработчики». Я бы добавил «при достаточно малом количестве оборудования»

Answer 5

Исходя из моего опыта, на сегодняшний день самые большие сборы, которые вы в конечном итоге оплачиваете с помощью RoR:

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

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

Answer 6

В статье, на которую вы ссылаетесь, технический долг определяется как

[] возможные последствия Архитектура программного обеспечения slapdash и поспешная разработка программного обеспечения

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

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

Мой совет всем, кто адаптирует Rails:

• использовать TDD для всех ваших разработок
• проверить качество любого плагина вы используете, читая его тесты. Если они не ясны и полны, избегайте плагин
• читать "Рельсы" Рецепты »и« Продвинутые рельсы » Рецепты »(Advanced Rails Recipes имеет хороший рецепт для добавления аутентификация в режиме RESTful)
• будьте готовы платить за оборудование для масштабирования вашего сайта (оборудование дешевле, чем время разработки)