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

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?)

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.

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.

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ę.

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.

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:

• Udać się
• Clojure
• JavaScript V8 ( node.js )
• JRuby (alternatywa, o której nie można zapomnieć - w zależności od obszaru problemu JRuby może być lepszym lub gorszym wyborem, aby uzyskać trochę prędkości z aplikacji railsowej)
• Scala
• Jawa
• DO#

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.

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.

• 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.

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ę.