Які недоліки RoR? [зачинено]

Наразі я намагаюся вирішити, яку мову на серверній основі вивчити та використовувати для веб-розробки, і хоча порівняно легко отримати інформацію про те, чому х, у або z - це добре, важче розібрати недоліки кожного їх.

Зокрема, мені цікаво, які недоліки є у навчанні та / або використанні Ruby on Rails на відміну від будь-якої іншої мови / основи.

Якщо говорити з досвіду: Мінус полягає в тому, що ви занадто сильно покладаєтесь на рамки Rails . Це чудова і чудова річ, якщо ви коли-небудь пишете прості програми GreenUD CRUD, які прямо потрапляють у "солодке місце" Rails; Ваша продуктивність зросте. Однак, коли вам доведеться щось робити за межами цього приємного місця - взаємодіяти з існуючою базою даних, поговорити з іншим додатком, у якому не визначено JSON або XML API, реалізуйте складний робочий процес, Rails стане вашим ворогом. це єМожна робити ці речі з Рейками, але це йде "проти зерна", тому ви в основному самостійно розбираєте, як це зробити, оскільки громада зазвичай просто відповідає "Не робіть цього, це не Рейки спосіб "- це призводить до втрати продуктивності або дуже безладного коду, оскільки ви, в основному, повинні зламати рамки Rails.

Також є невимовний мінус: все інше буде здаватися некрасивим і неприємним. Після того, як ви скуштували приємний, солодкий нектар з Рейлів (добре, тут євангелізуючи лише трохи ...), все інше заграє. Повернутися з Rails назад до PHP, або ASP.NET WebForms, або Java - це як ходити по нігтям після нігтів по пишному саду; Ви не побачите інших мов / рамок у такому ж світлі, і, хоча ви все ще зможете їх цінувати, ви будете таємно довго шукати любовних обіймів Рейла.

Що стосується вашої першої мови на сервері, я думаю, що з RoR може виникнути кілька проблем:

1. Ви не просто вивчаєте мову, ви вивчаєте рамки. Я б точно зайняв деякий час, щоб пограти з простим старим рубіном, перш ніж стрибнути в рейки.

2. Оскільки це рамка і «самовпевнений» у цьому, я відчуваю, що це дасть вам дуже обмежений обсяг того, що все відбувається в рамках.

В цілому Ruby on Rails може стати гарною відправною точкою для прокатки м'яча, але ви можете багато чого дізнатися про розробку веб-сторінок, яку ви можете пропустити, надто покладаючись на єдину рамку.

Я кілька разів намагався засвоїти RoR, і моя найбільша проблема - це завжди намагатися змусити пакунки працювати правильно і документацію. Проблема з документацією полягає в тому, що вона завжди здається застарілою (або дуже базовою). Я отримав основи з сайту, але поза тим, що все здавалося таким датним (навіть книга, яку я купив і в кінцевому підсумку повернулася). Ще одна річ, яка може бути недоліком, - це залежність, яку мають деякі бібліотеки, і те, як вони можуть конфліктувати з іншою, як це заявив Бен Коу .

Щось, про що я думав пізніше, і замість того, щоб зробити коментар, я просто відредагую свою відповідь, це така: RoR має шанс зруйнувати Рубі для вас. Я знаю, коли я спробував це, змусило мене думати, що "Рубі дурна". Потім через кілька місяців я вирішив віддати Рубі і полюбив мову, це було те, що змусило мене ненавидіти мову. Я не дуже в цьому справлявся, але коли я це зробив, мені дуже сподобалася Сінатра . Я думаю, що я отримав радість, що більшість людей виходять із РР із Сінатри.

Якщо це ваша перша мова на стороні сервера, це так само добре, як і будь-яка. Що потрібно зробити, це зосередитись на одному, і після того, як ти відчуєш, що ти це опанував, вивчи інших та зроби власні висновки.

Я щодня працюю з RoR та ASP.NET, але, як не дивно, я віддаю перевагу світу ASP.NET, але це має більше спільного з особистою філософією, ніж це стосується мови чи самої архітектури. (Я трохи фрік-контроль, і я особисто тяжію до сильно набраних мов).

Незважаючи на те, я кажу, давай. RoR - це чудове середовище для роботи, але перш ніж стрибнути прямо в Rails, будьте зручні з Рубі як мовою. Крім веб-речей, Ruby - це дуже класна мова сценаріїв, якщо вам потрібно управляти полем * nix і може заощадити на вашому часі.

Оскільки той, хто нещодавно вивчив Rails (як хобі - ніколи не використовував його для розвитку комерційних класів) і вже працював у JEE та ASP.NET, відповідь Wayne M звучав дуже правдиво.

У будь-якому випадку, у цього є тонка сторона, про яку ще ніхто не згадував, але яка мене трохи заважала Rails - сильна залежність від умовності щодо конфігурації .

По суті, якщо ви звикли до "Find In Files" -орієнтованої версії з новою базою коду, CoC, швидше за все, буде дратувати вас при спробі забрати Rails. Це чудово підходить для простих зелених полів CRUD, які робляться саме шляхом Rails (як каже Уейн М), але для чогось більш унікального і складного буде важко розібратися, що відбувається, якщо ви спробуєте розробити потік шляхом пошуку матеріал у файли, щоб побачити, як сантехніка підключена.

Хоча я думаю, ця проблема, ймовірно, не буде такою поганою, як тільки у вас буде набагато більше досвіду роботи з Rails. Я точно можу побачити, що це проблема для когось із веб-розробки Oldskool Java / .NET, який звик до дуже багатослівного потоку конфігурації - і звик покладатися на те, щоб побачити все, що десь написано.

У мене найбільша проблема, коли я вивчаю свій перший X (у вашому випадку X - це веб-мова / фреймворк на стороні сервера), це те, що, як тільки я бачу інші проблеми, я одразу хочу почати застосовувати X, навіть коли це може бути не найкращим варіантом. Я став краще в цьому, але це все ще сильна тенденція.

Ruby on Rails - хороший вибір для початку - є хороша спільнота, багато документації та хороші підручники. Але не забудьте пам’ятати про альтернативи, особливо якщо ви почнете робити більше веб-розробок. RoR може бути непосильним для деяких проблем, неадекватним рішенням для інших та найкращим вибором для іншого набору. Знайте, що це сильні, слабкі сторони та як користуватися інструментом.

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

Інша річ - придбати книги. Підручники в Інтернеті не враховують мого досвіду; вони також залишають багато місця відкритим для відволікання. Коли у вас є книга, видавці повинні переконатися, що вона надає цінність, оскільки вони втратять гроші, якщо отримають погані відгуки. Витративши трохи грошей, ви заощадите багато часу.

Я, чесно кажучи, не можу зрозуміти тих, хто поетично віє про те, що таке прогулянка по саду Рубі-на-Рейки. Я прийшов до цього як досвідчений розробник ASP.NET-MVC, Java, PHP, Python - і виявив, що це найжахливіший витрачальник часу! 90 відсотків відповідей в Інтернеті в Google неправильні або неповні. Чому? Чи змінилося так сильно щороку? Або це нікому не байдуже, щоб змусити код насправді працювати? На це знадобилося величезна кількість часу, щоб просто робити прості речі; далеко, набагато більше, ніж знадобиться, наприклад, у C # / ASP.NET-MVC. Це, звичайно, ніколи не забирало мене так довго, щоб вивчити мої оригінальні технології. Звичайно, ROR короткий. Якщо це для вас важливо. Але мені рідко було зрозуміло, як створити код, який би виконав завдання. Особисто я хотів би набрати на клавіатурі протягом 20 секунд, щоб написати код, який точно працює, зрозуміло, і ви можете слідувати за ним, а не вводити короткий код Ruby протягом 2 секунд, але це ніколи не працює, поки я не буду всю ніч шукати якийсь спосіб насправді змусити його працювати. Це жахлива, смердюча купа додо. Чому? Хіба що відкритий код (як у вільному) коді не дає стимулів зробити його інструментом якості? Забагато дітей-скриптів, які завантажують у нього редакції та модулі та погану документацію? Не знаю. Але коли мені нарешті вдалося уникнути першого проекту Ruby-Rails, я поклявся, що більше ніколи не вступлюся в цей безлад! не створює жодних стимулів зробити його якісним інструментом? Забагато дітей-скриптів, які завантажують у нього редакції та модулі та погану документацію? Не знаю. Але коли мені нарешті вдалося уникнути першого проекту Ruby-Rails, я поклявся, що більше ніколи не вступлюся в цей безлад! не створює жодних стимулів зробити його якісним інструментом? Забагато дітей-скриптів, які завантажують у нього редакції та модулі та погану документацію? Не знаю. Але коли мені нарешті вдалося уникнути першого проекту Ruby-Rails, я поклявся, що більше ніколи не вступлюся в цей безлад!

Я пропоную вам ознайомитись з індексами, які оцінюють перевагу різних мов / сценаріїв. Ось посилання, яке може виявитися корисним: популярні професійно використовувані веб-мови.

Це показує відносну популярність веб-мов на основі пошуку в Інтернеті оголошень про роботу.

Я погоджуюся з деякими з вищезазначених відповідей щодо RoR, я розробляю програми з RoR протягом останніх двох років. Це дійсно добре з простими програмами, операції CRUD (Створення, читання, оновлення та видалення) працює дуже добре, є благом для розробки простих додатків, але також є і обмеженнями. Хоча багато дорогоцінних каменів пропонує різні переваги та простоту використання, в основному це. Якщо вийти з коробки, ви отримаєте всі додатки.

Якщо ви велика команда, яка працює над програмою, що використовує RoR, працювати з делегацією може бути важко.