Jakie są wady RoR? [Zamknięte]

Obecnie próbuję zdecydować, jakiego języka po stronie serwera się uczyć i używać do tworzenia stron internetowych i chociaż stosunkowo łatwo jest uzyskać informacje o tym, dlaczego x, y lub z jest dobrą rzeczą, trudniej jest znaleźć wady każdego z nich z nich.

W szczególności jestem ciekawy, jakie są wady uczenia się i / lub używania Ruby on Rails w przeciwieństwie do jakiegokolwiek innego języka / frameworka.

Mówiąc z własnego doświadczenia: Minusem jest to, że opierają się na ramach Rails trochę zbyt wiele. Jest to świetna i wspaniała rzecz, jeśli piszesz tylko proste, zielone aplikacje CRUD, które wpadają wprost w „słodki punkt” Railsów; Twoja produktywność gwałtownie wzrośnie. Jednak w momencie, gdy musisz zrobić coś poza tym najsłodszym miejscem - wejść w interakcję z istniejącą bazą danych, porozmawiać z inną aplikacją, która nie ma zdefiniowanego JSON lub XML API, zaimplementować skomplikowany obieg pracy, Railsy staną się twoim wrogiem. to jestmożna robić te rzeczy za pomocą Railsów, ale idzie to „wbrew pozorom”, więc zasadniczo jesteś sam i zastanawiasz się, jak to zrobić, ponieważ społeczność zwykle po prostu odpowiada „Nie rób tego, to nie jest Rails way ”- powoduje to utratę produktywności lub bardzo niechlujny kod, ponieważ w zasadzie musisz włamać się do środowiska Rails.

Jest też niewypowiedziana wada: wszystko inne będzie brzydkie i niechlujne. Kiedy skosztujesz słodkiego, słodkiego nektaru Railsów (dobra, trochę ewangelizując tutaj ...) wszystko inne jest zalewane. Powrót z Railsów z powrotem do PHP, ASP.NET WebForms lub Java jest jak chodzenie po gwoździach po zabawie w bujnym ogrodzie; nie zobaczysz innych języków / ram w tym samym świetle i chociaż nadal możesz je docenić, potajemnie będziesz tęsknił za uściskiem Railsa.

W przypadku twojego pierwszego języka po stronie serwera wydaje mi się, że może być kilka problemów z RoR:

1. Nie tylko uczysz się języka, uczysz się frameworka. Zdecydowanie poświęciłbym trochę czasu na zabawę zwykłym starym rubinem, zanim wskoczę na szyny.

2. Ponieważ są to ramy, a jednocześnie „opiniotwórcze”, wydaje mi się, że dałoby to bardzo ograniczony zakres tego, co się dzieje w ramach.

Ogólnie rzecz biorąc, Ruby on Rails może być dobrym punktem wyjścia, aby rzucić piłkę, ale jest wiele do nauczenia się na temat tworzenia stron internetowych, których możesz przegapić, ponieważ zbytnio polegasz na jednej platformie.

Próbowałem nauczyć się RoR kilka razy i moim największym problemem jest zawsze próba poprawnego działania pakietów i dokumentacji. Problem z dokumentacją polega na tym, że zawsze wydaje się nieaktualna (lub bardzo podstawowa). Dostałem podstawy ze strony, ale poza tym wszystko wydawało się tak przestarzałe (nawet książka, którą kupiłem i w końcu wróciłem). Inną rzeczą, która może być wadą, są zależności między niektórymi bibliotekami oraz sposób, w jaki mogą one powodować konflikty z innymi, jak stwierdził Ben Coe .

Coś, o czym myślałem później i zamiast komentować, po prostu zredaguję moją odpowiedź: RoR ma szansę zrujnować dla ciebie Ruby. Wiem, że kiedy spróbowałem, pomyślałem, że „Ruby była głupia”. Potem kilka miesięcy później postanowiłem dać Ruby szansę i pokochałem ten język, ponieważ dzięki nim nienawidziłem tego języka. Nie zagłębiałem się w to wiele, ale kiedy to zrobiłem, naprawdę podobała mi się Sinatra . Myślę, że czerpałem radość, jaką większość ludzi czerpie z RoR z Sinatry.

Jeśli jest to twój pierwszy język po stronie serwera, jest tak dobry, jak każdy inny. Należy skupić się na jednym, a kiedy poczujesz, że go opanowałeś, eksploruj innych i wyciągaj własne wnioski.

Na co dzień pracuję z RoR i ASP.NET, ale co dziwne, wolę świat ASP.NET, ale ma to więcej wspólnego z osobistą filozofią niż z językiem lub samą architekturą. (Jestem trochę maniakiem kontroli i osobiście gram w mocno pisanych językach).

Niezależnie od tego, mówię, spróbuj. RoR to świetne środowisko do pracy, ale zanim przejdziesz do Railsów, poczuj się dobrze z Ruby jako językiem. Poza materiałami internetowymi, Ruby jest całkiem fajnym językiem skryptowym, jeśli skończysz z zarządzaniem skrzynką * nix i możesz zaoszczędzić mnóstwo czasu.

Jako ktoś, kto ostatnio nauczył się Railsów (jako hobby - nigdy nie używał go do rozwoju klasy komercyjnej) i pracował już w JEE i ASP.NET, odpowiedź Wayne M brzmiała bardzo prawdziwie.

W każdym razie jest jeszcze subtelna strona, o której nikt jeszcze nie wspomniał, ale która trochę mnie niepokoiła z Railsami - silne poleganie na konwencji nad konfiguracją .

Zasadniczo, jeśli jesteś przyzwyczajony do orientacji opartej na „znajdowaniu w plikach” z nową bazą kodu, CoC może cię zirytować podczas próby pobrania Railsów. Doskonale nadaje się do prostych zielonych pól CRUD, które są wykonywane dokładnie tak, jak Rails (jak Wayne M), ale w przypadku czegoś bardziej wyjątkowego i skomplikowanego ciężko będzie zorientować się, co się dzieje, jeśli spróbujesz wypracować przepływ, szukając w plikach, aby zobaczyć, jak podłączona jest instalacja wodno-kanalizacyjna.

Chociaż myślę, że ten problem prawdopodobnie nie będzie tak zły, gdy będziesz mieć dużo więcej doświadczenia z Railsami. Zdecydowanie widzę, że jest to problem dla kogoś, kto pochodzi ze starego web Java / .NET, który jest przyzwyczajony do bardzo pełnego przepływu konfiguracji - i jest przyzwyczajony do tego, że wszystko gdzieś się pisze.

Ze mną największym problemem jest uczenie się mojego pierwszego X (w twoim przypadku X jest językiem / frameworkiem sieciowym po stronie serwera), gdy tylko widzę inne problemy, od razu chcę zacząć stosować X, nawet jeśli może nie być najlepszą opcją. W tym poprawiłem się, ale wciąż jest to silna tendencja.

Ruby on Rails to dobry wybór na początek - jest dobra społeczność, mnóstwo dokumentacji i dobre samouczki. Pamiętaj jednak, aby pamiętać o alternatywnych rozwiązaniach, zwłaszcza jeśli zaczniesz robić więcej tworzenia stron internetowych. RoR może być przesadą w przypadku niektórych problemów, nieodpowiednimi rozwiązaniami dla innych i najlepszym wyborem dla innego zestawu. Wiedz, że to mocne i słabe strony oraz jak korzystać z tego narzędzia.

Radzę mieć jasny obraz projektu, który chcesz ukończyć, a następnie po prostu zacznij go budować. Gdy napotkasz problemy, w końcu zdobędziesz wszystkie odpowiednie narzędzia. Takie podejście jest dobre, ponieważ podejmujesz decyzje na podstawie zwięzłych problemów.

Kolejną rzeczą do zrobienia jest kupowanie książek. Samouczki internetowe nie ograniczają tego z mojego doświadczenia; pozostawiają też dużo miejsca na rozrywkę. Kiedy masz książkę, wydawcy muszą upewnić się, że zapewnia ona wartość, ponieważ stracą pieniądze, jeśli otrzymają złe recenzje. Wydając trochę pieniędzy zaoszczędzisz dużo czasu.

Naprawdę nie rozumiem tych, którzy poetycko opowiadają o tym, czym jest spacer po ogrodzie Ruby-on-Rails. Doszedłem do tego jako doświadczony programista ASP.NET-MVC, Java, PHP, Python - i okazało się, że jest to najokropniejszy strata czasu! 90 procent internetowych odpowiedzi w Google jest niepoprawnych lub niekompletnych. Dlaczego? Czy to zmienia się tak bardzo każdego roku? A może nikt nie dba o to, aby kod rzeczywiście działał? Zajęło mi mnóstwo czasu, aby po prostu zrobić proste rzeczy; daleko więcej niż zajęłoby mi to na przykład C # / ASP.NET-MVC. Na pewno nigdy tak długo nie zajęło mi nauczenie się moich oryginalnych technologii. To prawda, ROR jest zwięzły. Jeśli to dla ciebie ważne. Ale rzadko stwierdziłem, jak stworzyć kod, który wykona zadanie. Osobiście wolałbym pisać na klawiaturze przez 20 sekund, aby napisać kod, który zdecydowanie działa, jest jasne i możesz go przestrzegać, zamiast wpisywać zwięzły kod Ruby przez 2 sekundy, ale to nigdy nie działa, dopóki nie sypię całą noc, szukając jakiegoś sposobu, aby rzeczywiście działał. To okropna, śmierdząca kupa dodo. Dlaczego? Czy to ten kod typu open source (jak w darmowym) nie zachęca do uczynienia go narzędziem wysokiej jakości? Zbyt wielu dzieciaków ze skryptami pompujących wersje i moduły oraz złą dokumentację? Nie wiem Ale kiedy w końcu udało mi się uciec od pierwszego projektu Ruby-Rails, przysięgałem, że nigdy więcej nie wejdę w ten bałagan! nie zachęca, aby stało się narzędziem wysokiej jakości? Zbyt wielu dzieciaków ze skryptami pompujących wersje i moduły oraz złą dokumentację? Nie wiem Ale kiedy w końcu udało mi się uciec od pierwszego projektu Ruby-Rails, przysięgałem, że nigdy więcej nie wejdę w ten bałagan! nie zachęca, aby stało się narzędziem wysokiej jakości? Zbyt wielu dzieciaków ze skryptami pompujących wersje i moduły oraz złą dokumentację? Nie wiem Ale kiedy w końcu udało mi się uciec od pierwszego projektu Ruby-Rails, przysięgałem, że nigdy więcej nie wejdę w ten bałagan!

Proponuję spojrzeć na indeksy oceniające prekursory różnych języków / skryptów. Oto link, który może się okazać przydatny: popularne profesjonalnie używane języki związane z siecią.

Pokazuje to względną popularność języków związanych z siecią na podstawie wyszukiwań ofert pracy online.

Zgadzam się z niektórymi z powyższych odpowiedzi na temat RoR, od dwóch lat rozwijam aplikacje w RoR. Jest naprawdę dobry z prostymi aplikacjami, operacje CRUD (tworzenie, odczyt, aktualizacja i usuwanie) działają bardzo dobrze, jest dobrodziejstwem dla tworzenia prostych aplikacji, ale jest także jego ograniczeniami. Chociaż istnieje wiele klejnotów oferuje różne zalety i łatwość użycia, to w zasadzie to. Wyjście z pudełka sprawi, że wszystkie aplikacje będą przekręcone.

Jeśli jesteś dużym zespołem pracującym nad aplikacją korzystającą z RoR, delegowanie pracy może być trudne.