Wady i zastrzeżenia Ruby on Rails [zamknięte]


25

To nie jest otwierająca gra dla walenia w RoR - szczerze!

Uczę się frameworka Ruby and the Rails. Na pierwszy rzut oka wydaje się to całkiem fajne i wspaniałe doświadczenie w porównaniu do PHP. (W rzeczywistości przypomina mi to szczęśliwsze dni z C # i .NET.)

Jednak wchodząc w to, nie mam doświadczenia z tym frameworkiem lub językiem i jestem ciekawy - jakie są obecne wady lub rzeczy, które chciałbyś, żebyś wiedział, kiedy zacząłeś?

(Może powinna to być wiki społeczności?)


Próbowałem raz na szynach i przestałem, gdy zdałem sobie sprawę, że projektowanie encji na bazie pierwszej bazy danych nie jest łatwe.
Falcon

5
warto przeczytać avdi.org/devblog/2011/08/22/your-code-is-my-hell . Dodałbym, że przy każdym dynamicznie pisanym języku niezwykle ważne jest posiadanie 80% lub więcej pokrycia testowego, w przeciwnym razie refaktoryzacja będzie prawie niemożliwa.
Eric Wilson

Uszczegółowienie twojego pytania (np. „Przejście z PHP na Ruby on Rails - plusy i minusy) usunęłyby potrzebę rezygnacji z bicia i chęci stworzenia wiki społeczności.
Thomas Langston

2
@Thomas Ale to nie moje pytanie! Plusy i minusy PHP są naprawdę dobrze znane. Zalety RoR są dość łatwe do znalezienia. Jednak wady RoR nie są łatwe do odkrycia jako nowicjusz i podejrzewam, że zostaną odkryte dopiero po wielu latach doświadczenia. Uczenie się na zasłużonym doświadczeniu innych jest celem tego. Wiele CW, które przeczytałem, ma dość specyficzny charakter.
Matty,

Odpowiedzi:


32

Wynika to z uczenia się przez doświadczenie, ciągłego uczenia się i pisania stosunkowo prostej aplikacji w Railsach.

1) Krzywa uczenia się

Szyny są zwodniczo proste. Wszystkie samouczki, filmy i książki pokazują, jak szybko można uzyskać działającą (choć brzydką) aplikację, ale tak naprawdę po prostu drapią powierzchnię. Zwykle polegają głównie na generowaniu kodu i „rusztowaniu”, co wprawdzie jest dobrym narzędziem do nauki, ale szybko przestaje być przydatne.

Nie popełnij błędu, Rails jest trudny do opanowania. Gdy przejdziesz przez podstawy (więcej o tym później), wybiegniesz na ścianę, jeśli chcesz zrobić coś więcej niż bardzo uproszczoną funkcjonalność „aplikacji demo”, którą widzisz. Możesz uczyć się z podstawową znajomością języka Ruby podczas nauki, ale szybko musisz go podnieść, bo w przeciwnym razie pozostaniesz wysoki i suchy (i nie jest to dobry rodzaj DRY), jeśli chcesz wyjść poza ograniczenia Rails.

Rails to, jak lubię to nazywać w sposób kochający, programowanie według numerów . Jeśli trzymasz się w 100% konwencji (tj. Trzymasz się linii i używasz kolorów, o których kazanie ci chodzi), możesz szybko i łatwo tworzyć przyzwoite aplikacje. Jeśli i kiedy musisz zboczyć, Railsy mogą przejść od twojego najlepszego przyjaciela do najgorszego wroga.

2) Gdy wszystko, co masz, to młotek ...

Railsy bardzo dobrze radzą sobie z uproszczonymi aplikacjami CRUD. Problem pojawia się, gdy aplikacja musi robić coś więcej niż tylko odczyt / zapis z bazy danych. Teraz, dla przypomnienia, ostatnią wersją Railsa, której użyłem, było 2.3.4, więc od tego czasu mogły się zmienić, ale napotkałem poważne problemy, gdy zmieniły się wymagania biznesowe, więc aplikacja musiała mieć wbudowany mały system przepływu pracy i zintegrować się z starsza aplikacja PHP. Konwencja Rails „jedna forma, jeden model” działa dobrze w przypadku trywialnych aplikacji i aplikacji do wprowadzania danych, ale nie tak bardzo, gdy trzeba wykonać logikę przetwarzania, mieć przepływy pracy lub cokolwiek innego niż typowy „Użytkownik wprowadza dane do kilka pól tekstowych, trafienia Prześlij „rzecz”. To może być zrobione, ale to bynajmniej nie „Easy”, czy raczej to nie było”

Ponadto Rails nie lubi dobrze grać z innymi aplikacjami, które nie używają jego preferowanych metod dostępu do danych; jeśli musisz połączyć się z aplikacją, która nie ma interfejsu API w stylu „Web 2.0”, musisz obejść Railsy zamiast tego; znowu mówię z doświadczenia tutaj, ponieważ tak się ze mną stało.

3) Jest nowy

Wreszcie, Rails wciąż jest „nowym dzieckiem na bloku” w wielu obszarach. Nie ma to znaczenia dla użytku osobistego lub scenariuszy typu „Myślę, że to fajne i chcę się tego nauczyć”, ale mówienie jako ktoś, kto wolałby używać Railsów w mojej codziennej pracy, jeśli nie jesteś w miejscu, w którym Rails jest rozpowszechnione, może być bardzo trudno znaleźć pracę w pełnym wymiarze godzin jako programista Railsów. Nadal jest w dużej mierze domeną „modnych, nowych startupów” i nie jest znaczącym graczem w większości obszarów metropolitalnych. Twój przebieg może być różny pod tym względem, ale wiem, że moja okolica (Tampa) Szyny w zasadzie nie istnieje.

4) Ogień i ruch

Szyny ciągle się zmieniają. Jest to zarówno dobra, jak i zła rzecz; to dobrze, ponieważ społeczność ewoluuje i obejmuje nowe koncepcje. Jest źle, ponieważ społeczność ewoluuje i obejmuje nowe koncepcje. Dla początkującego Railsów może to być bardzo przytłaczające, ponieważ zazwyczaj, gdy napotkasz problem i rozejrzysz się, zobaczysz albo osoby polecające taki i taki klejnot, aby to naprawić, albo mówiące, że i tak jest źle i nie powinieneś użyj go, oto lepszy sposób ... i w końcu masz listę prania dodatkowych narzędzi do nauki wraz z Railsami, aby nadążyć za cognoscenti Railsów. Rzeczy takie jak Git, BDD/RSpec, Cucumber,Haml/Sass, a róg obfitości innych rzeczy unosi się wokół i zostaje popchnięty jako „właściwy sposób robienia rzeczy” w Rails-land, a mówiąc z doświadczenia możesz zostać zalany próbą nauczenia się kilkunastu lub więcej technologii oprócz Railsów, ponieważ używanie standardowego zestawu narzędzi Railsów wydaje się „złe”.

Jest to jeszcze bardziej skomplikowane przez Rails 3.1, dzięki czemu Sass i CoffeeScript wszystkich rzeczy są domyślnymi, więc nowicjusz w Rails musi nie tylko nauczyć się Ruby i Rails, ale Sass (prawdopodobnie prosty, jeśli znasz CSS) i CoffeeScript (nie jest to szalenie trudne, ale na pewno różni się od surowego JavaScript) na minimum, aby zacząć, a ponadto można założyć, że Git. Nawet bez uwzględnienia RSpec i przyjaciół oraz kilkunastu klejnotów, z którymi zwykle się skończysz, to 4 różne rzeczy, których musisz nauczyć się, zanim zaczniesz poważnie pisać aplikacje Railsowe. Porównaj to z językiem takim jak C #, Java, a nawet PHP, w którym Twoja wiedza na temat HTML / CSS / JavaScript / SQL nie ulegnie zmianie i wystarczy nauczyć się samego języka i być może niuansów ramowych.


3
WRT Rails 3.1 Sass i CoffeeScript to ustawienia domyślne, które można łatwo wyłączyć. W rzeczywistości „normalny” CSS będzie działał, ponieważ Rails 3.1 używa składni SCSS SASS. Możesz ich użyć, ale nie jesteś pod żadnym przymusem. WRT Git Myślę, że Linus lepiej wyjaśnia, dlaczego tak naprawdę powinieneś używać DVCS, takich jak Git, niezależnie od tego, jakich ram używasz. youtube.com/watch?v=4XpnKHJAok8
Shreyas Satish

Oh Zgadzam się, tylko mówię, że domyślna Rails jest zwykle dużo hiper tak początkującym będą czuć presji, aby go używać (wiem, czułem, że sposób)
Wayne Molina

3
+1 za # 4 ... jeśli opuścisz Rails na rok, kiedy wrócisz, wszyscy będą latać w statkach kosmicznych i będziesz w swojej łodzi wiosłowej myśląc o wtf? Składnia Rails 2 wydawała się stara przed wydaniem Rails 3.
jimworm

-1 Dobry szyn bashing post, ale nawet nie sugerujesz alternatywy. „Zagnieżdżone formularze” to trudny problem i Rails prawdopodobnie rozwiązuje je lepiej niż ktokolwiek inny.
scottschulthess

13

Dokumentacja.

Chociaż Przewodniki po Railsach są świetnym źródłem do nauki, nawigacja po bibliotekach Railsów (i ogólnie Ruby) nie jest łatwa. Powiedz, że chcesz dowiedzieć się więcej o belongs_tometodzie. Chociaż jest stosowany w ActiveRecord::Basepodklasach (modelach), nie jest udokumentowany w ActiveRecord::Basedokumentach, ale w miksie, który klasa importuje. Zasadniczo nie możesz zobaczyć pełnej listy wszystkich metod, których możesz użyć na obiekcie w jednym miejscu (z wyjątkiem sytuacji, gdy odpalasz irbi sprawdzasz sam obiekt).

W przypadku bardzo dynamicznego języka, jakim jest Ruby, nie jest łatwo stwierdzić, skąd pochodzi używana metoda. Może to stanowić problem, szczególnie dla programistów uczących się, którzy chcą poznać nowy stos technologii.


To jest dla mnie zabójca; ilekroć muszę debugować część naszego kodu Ruby / Rails, zawsze spędzałem zbyt dużo czasu próbując dowiedzieć się, gdzie zdefiniowano daną metodę; i nawet wtedy zawsze muszę pamiętać, że tylko dlatego, że widzę definicję metody, mogła zostać zdefiniowana gdzie indziej.
joev

9

Ruby on Rails ma znaczną krzywą uczenia się. Najpierw musisz nauczyć się osobliwości języka, następnie nauczyć się frameworka, następnie nauczyć się Rails Way robienia rzeczy, a następnie dowiedzieć się o wielu powszechnie używanych klejnotach.

Jednak gdy się tego nauczysz, dzieje się to niezwykle naturalnie. W rzeczywistości inne ramy zaczynają być ciężarem.

Rails jest bardzo zorientowany na TDD / BDD, więc jeśli tak nie jest, musisz nauczyć się jeszcze dwóch rzeczy, zanim zostaniesz kompetentnym programistą Railsów. Nie masz kompilatora i IDE do tworzenia kopii zapasowych, więc zasięg testów jest w dużej mierze twoją rezerwą.

Wielu zwolenników TDD, w tym ja, uważałoby tę jedną z mocnych stron RoR, a także jego przekleństwo. Gdy zaczniesz pisać TDD, przekonasz się, że bezpieczeństwo oferowane przez zasięg testowy jest lepsze niż bezpieczeństwo oferowane przez kompilator. Potem konieczność pisania kodu JUST, aby zadowolić kompilator, staje się obciążająca.

TDD nie wydaje się dodatkowym zadaniem w RoR, wydaje się, że jest to jedyny sposób na pracę.

Railsy mają jeden poważny problem z wydajnością: każde żądanie jest ustawione w kolejce za aktualnie aktywnym, w przeciwieństwie do dzielenia ich na wątki, jak robi to większość frameworków, lub zezwalania na blokowanie zdarzeń w celu zwolnienia innych żądań, jak w przypadku Node.js i Twister. Oznacza to, że musisz napisać kod, aby skrócić czas reakcji, ale w większości przypadków jest to dość łatwe.

Railsy są również bardzo dobrze zaprojektowane do obsługi systemów treści, co w rzeczywistości jest dużą ilością Internetu. Robienie czegoś bardziej skomplikowanego, na przykład gry internetowej lub systemu e-commerce, oznacza naukę nowych klejnotów. Szybko dowiadujesz się, że wszystkie klejnoty są dostępne, ale im bardziej niejasne jest to, co chcesz zrobić, tym trudniej będzie znaleźć dobrą dokumentację.


Jeśli chodzi o problemy z wydajnością - wydaje mi się, że czytam, że wiele z nich zostało w dużej mierze rozwiązanych w wersji 1.9 interpretera, ale mogę się całkowicie mylić. Czy są jakieś sposoby na obejście tego ograniczenia wydajności?
Matty,

1
@Matty: Jak dodałem, kod, aby czasy reakcji były jak najszybsze. Zrób wszystko, co można pozostawić procesowi zaplecza. Ale powinieneś to zrobić z dowolnym frameworkiem - po prostu łatwo tego nie robić. Ponadto jRuby jest podzielone na różne wątki, ale ma swoje własne problemy i moja odpowiedź była już wystarczająco długa.
pdr

7

Z mojego osobistego doświadczenia wynika, że ​​głównym problemem jest kompatybilność .

Kiedy:

  • istnieją xszyny projekty wdrożone,
  • każdy projekt wykorzystuje yklejnoty.
  • podczas gdy istnieją nwersje szyn,
  • plus mzainstalowane wersje klejnotów,
  • z severalwersjami rubinu,
  • na jednym komputerze z systemem Linux jako maszyną produkcyjną.
  • programista działa na innym notatniku programistycznym OS X.

Jako freelancer, który nie ma luksusu do aktualizacji / upgrade większość rzeczy, czeka wiele problemów ze zgodnością z powyższych zmiennych ... natomiast rails, gemsi rubyciągle się zmienia / ewoluuje.


7
Wszystko, co wspomniałeś, zostało naprawione za pomocą RVM (lub rbenv ) i Bundlera . Możesz wtedy mieć określone wersje Ruby i pojedyncze zestawy klejnotów dla każdego projektu.
Ashley Williams,

Ta odpowiedź jest (teraz) całkowicie nieistotna. RVM do zarządzania wersją Ruby, Bundler do obsługi wersji klejnotów; Capistrano do obsługi wdrożeń na serwerze produkcyjnym, a Figaro dba o tajniki aplikacji / zmienne środowiskowe. Tworzę swoją aplikację na [Cloud9] (c9.io) (IDE sieci), a proces wdrażania jest dosłownie bundle exec cap production deploy. Capistrano zajmuje się wersjonowaniem aplikacji na serwerze. Jak każde inne frameworki, które się pojawią (np. Node.js), pisane są narzędzia do rozwiązywania problemów .
Chris Cirefice

5

Prędkość zdecydowanie stanowi problem. Wyjątkowa elastyczność Ruby ma znaczący wpływ na wydajność.

Skalowanie w poziomie jest nieoczywistym zadaniem, z wyjątkiem technologii specjalnie zaprojektowanych do tego zadania, które zwykle zastępują prostotę dobrego skalowania.
Jeśli jesteś w stanie obsłużyć 100 razy więcej żądań na maszynę z technologią A niż z technologią B, warto skorzystać z technologii A, jeśli masz powód, by sądzić, że możesz obsługiwać dane z jednego serwera przez okres czasu, który pozwala na dodanie późniejsza równoległość.
W 2009 r. Stackoverflow był nadal obsługiwany z jednego serwera WWW . Oczywiście nie jest to już opcja. Ale przypuszczam, że dobrze, że zaczęli od technologii, która może skalować się do wielu użytkowników w jednym wystąpieniu, zanim będą musieli martwić się skalowaniem.

W porównaniu z tym RoR jest naprawdę wolny. Czas na obsługę prostych żądań jest znaczny i dlatego problemem jest obsługiwanie wielu klientów (wszystko to widać w odniesieniu do szybszych alternatyw).

Ze względu na niejasną orientację, oto kilka liczb, porównujących różne inne języki odpowiednie do tworzenia stron internetowych z Ruby:

Zauważ, że nie oznacza to, że jeśli użyjesz frameworka X dla Javy, będzie on dokładnie 200 razy szybszy niż RoR. Różnica prędkości mierzona w tych testach ma jednak istotny wpływ na ogólną wydajność Twojej aplikacji.


4
Ta odpowiedź mówi tylko o „prędkości” w czasie wykonywania. Ruby (i Rails) jest zoptymalizowany pod kątem szybkości programowania.
Nicolai Reuschling,

5
To nie jest dobre porównanie. Większość czasu spędzonego na żądaniu internetowym wykonuje operacje we / wy z bazy danych. Powiązanie z testami intensywnie obciążającymi procesor jest mylące.
ryeguy

3
@pdr: Wiele problemów Twitter był używali rubin za wszystko , nawet swoje procesy backend które były obciąża CPU. Obszary takie jak te są statycznie pisane. Teraz używają do tego Scali. Naprawdę uważam, że korzystanie z RoR jest znacznie szybsze pod względem czasu programowania niż C # lub Java. Używałbym go do większości aplikacji internetowych, a następnie używałbym C # lub Scali do zadań w tle intensywnie wykorzystujących procesor.
ryeguy

3
+1 za ważne punkty. Biorąc to pod uwagę, możesz wiele zrobić, aby zoptymalizować aplikacje Railsowe. Rack nadaje się do tego, że jest raczej rozszerzalnym systemem, który pozwala na dużą elastyczność w tym, jak wszystko się nazywa. Nie wspominając, Ruby 1.9 jest szybszy, JRuby jest szybszy. Osobiście jestem wielkim fanem JRuby, możliwość zmieszania się z mocą JVM to wspaniała wygrana (po prostu uważaj na klejnoty, które używają wyjątków do kontroli przepływu -> ogromne koszty ogólne)
Xorlev

2
@Nicolai Reuschling: Jaką wartość ma „optymalizacja Ruby lub RoR pod kątem szybkości rozwoju”? Czy możesz podać weryfikowalne , ilościowe dane, w jaki sposób Ruby faktycznie zapewnia wyższą prędkość programowania niż alternatywy (na przykład Lift)? Wszystko inne jest tylko nieważnym roszczeniem. To pytanie dotyczyło także wad RoR . Wysoka prędkość programowania jest zaletą i dlatego nie wchodzi w zakres tego pytania. Niska wydajność środowiska wykonawczego mieści się w zakresie tego pytania, ponieważ jest to wadą.
back2dos,

3

Railsy mają jeden poważny problem z wydajnością: każde żądanie jest ustawione w kolejce za aktualnie aktywnym, w przeciwieństwie do dzielenia ich na wątki, jak robi to większość frameworków, lub zezwalania na blokowanie zdarzeń w celu zwolnienia innych żądań, jak w przypadku Node.js i Twister. Oznacza to, że musisz napisać kod, aby skrócić czas reakcji, ale w większości przypadków jest to dość łatwe.

Myślę, że to bardzo błędne. Możesz uruchomić Railsy w trybie wielowątkowym. Podczas pracy w trybie wielowątkowym powinieneś używać tylko bibliotek IO, które uwalniają GIL (na przykład klejnot „mysql2”), w przeciwnym razie staje się to bezcelowe.

Jeśli używasz jRuby, możesz po prostu uruchomić proces pojedynczej szyny w trybie wielowątkowym i w pełni wykorzystać całą dostępną moc procesora. Jeśli jednak korzystasz z MRI (Ruby 1.8.x lub 1.9.x), musisz uruchomić wiele procesów, aby w pełni wykorzystać procesory, tak samo jest w przypadku node.js.


Pytanie wyjaśniające tutaj - czy jest łatwy sposób, aby dowiedzieć się, które biblioteki IO wydają GIL?
Matty,

Myślę, że najlepszym sposobem, aby to ustalić, jest przeprowadzenie analizy porównawczej gist.github.com/35d4769d8c8c0dfafc56
Pratik Naik


Dobrze usłyszeć od jednego z głównych deweloperów! Te informacje nie są wymienione w żadnej dokumentacji, prawda? Rozpoczęcie testowania bibliotek, aby się tego dowiedzieć, jest trochę żmudne (choć interesujące działanie).
Matty,

3
  • Rails ma wiele subtelności, które ukrywają przed tobą złożoność. (Powiązania ActiveRecord, cały cykl sprawdzania poprawności / zapisywania, interpretacja danych żądania na podstawie dostarczonych nagłówków) Gdy zaczynasz, jest to niesamowite. Gdy dorośniesz, zauważysz, że zaczynasz dopasowywać swoją aplikację do „sposobu Railsowego” postępowania - czasami jest to dobre, czasem jest nieszkodliwe, a czasem jest to wręcz sprzeczne z intuicją w stosunku do tego, co próbujesz zrobić. Nie wszystkie tabele bazy danych powinny być modelowane jako obiekty, może zajść potrzeba sprawdzenia poprawności w innym miejscu itp. Wielu programistów Railsów unika nie walki z frameworkiem (co zwykle jest mądre), ale efektem długoterminowym jest ... ty przeniesie przyzwyczajenia Railsów do miejsc, w których niekoniecznie są potrzebne.

  • Społeczność ma w zwyczaju pisać oprogramowanie, które nazywa się „magią” - buforowanie lib, które działają magicznie! Evented I / O, który magicznie przyspiesza! Magiczna magia! To, co zwykle ma miejsce, to bardzo atrakcyjny interfejs API dla brakującego rozwiązania technicznego, a oszukują cię bardzo ładne przykłady, że rzecz robi to, co zamierzasz, a dopiero później okazuje się, że obejmuje ona niepełne rozwiązanie. Cykl tego jest dość stały i uczysz się z nim kręcić, ale zdecydowanie powinieneś zapoznać się z ideą czytania dużej ilości kodu, od którego zależysz (dobra rzecz!). Mówię, że magiczne rozwiązania społeczności Rails nie są tak magiczne, jak README może sugerować.

  • W związku z powyższym: im częściej używasz Railsów, tym bardziej powinieneś czytać jego źródło. Im lepiej rozumiesz wewnętrzne elementy ramowe, tym bardziej będziesz szczęśliwy na dłuższą metę. Nie do końca specyficzne dla Railsów, ale po prostu mówię wam z doświadczenia tutaj. Nazwy metod czasami obiecują coś, czego tak naprawdę nie otrzymujesz.

  • Kultywacja ładunku jest problemem związanym z Railsami, ale prawdopodobnie jest to prawdą w przypadku wszystkich społeczności frameworkowych / językowych. Wydaje mi się to bardziej wyraźne (dla mnie) w Railsach i jako takie nadaje dziwny pokoleniowy wygląd kodowi Railsów - podczas pracy nad różnymi projektami Railsów zauważysz pewne tendencje, które zdradzają okres, w którym zostały utworzone . Jak można się domyślić na podstawie tego stwierdzenia, społeczność ma tendencję do poruszania się dość szybko w zakresie przyjmowania nowych rozwiązań i wycofywania starych. Powinieneś naprawdę być na bieżąco z wiadomościami Ruby, aby zrozumieć część kodu, którego będziesz codziennie doświadczać.

  • Ogólnie rzecz biorąc, myślę, że społeczność zwykle nie zajmuje się problemem współbieżności danych - gdy rozwijasz aplikację, gdy osiągasz punkt, w którym musisz oddzielić dane, wycofać fizycznie zdalne zmiany i zablokować dostęp do danych, rozwiązania stają się nieco bardziej precyzyjnie zestrojony, co sprawia, że ​​niektóre z ładnie wyglądających rzeczy w Railsach są mętne z technicznymi wymogami dokładności. Railsy nie rozwiązują każdego problemu z aplikacją internetową, tak myślę, i chociaż twórcy z pewnością nie głoszą tej wiadomości, łatwo dać się zwieść myśleniu, że jest to implikowane.


2

W zależności od tego, jak na to spojrzysz, szybkość, z jaką Rails się zmienia, może, ale nie musi być dla ciebie zastrzeżeniem. Z roku na rok rzeczy zmieniają się nieco radykalnie, ponieważ coraz więcej jest tego, co jest do bani i potrzebuje rozwiązań.

Jeśli jednak aktywnie się rozwijasz, będziesz miał na to ochotę.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.