Jakie są zalety Ruby on Rails? Po dwóch dekadach programowania używam Rails

Czasami słyszę, jak ludzie narzekają na swoich klientów, twierdząc, że upierają się przy korzystaniu z Railsów, że wypili za dużo Kool Aid. Jeśli są rekruterami, prawie czują się chorzy na myśl o znalezieniu kolejnego dewelopera Ruby on Rails 'primadona'. Następnie wyciągają coś podobnego do tego zdumiewająco ignoranckiego porównania między Git i PHP, aby udowodnić swoją rację. „Oni nawet nie wiedzą, o co proszą”, mówią.

Dla nas jako programistów czasami wydaje się, że nasi klienci nie mają pojęcia. Uwielbiamy wyolbrzymiać takie przypadki. Kiedy trochę się nad tym zastanowisz, nie wydaje się słuszne, że osoba, która daje mi pieniądze na budowę, jest w jakiś sposób ograniczona i „po prostu tego nie dostaje”. W rzeczywistości uważam, że większość klientów dobrze zna swoje opcje, a mimo to nadal decyduje się na Rails.

Postaram się wyjaśnić, co moim zdaniem sprawia, że ​​Railsy są na tyle korzystne, że można je poważnie rozważyć w przypadku wielu projektów i potrzeb.

Korzyści z Ruby

Możliwe, że nikt nawet nie wiedziałby o zaletach Rubiego, gdyby nie same Railsy. Niektórzy lubią umniejszać Rubiego, mówiąc, że jest „tak łatwe dla Rubiego” z jego „rycerzem w lśniącej zbroi zwanej Rails” i że bez Railsów „Ruby byłby nieistotny”. Nie mogę powiedzieć na pewno, czy to prawda, ale wiem, że szkoda by było, gdyby świat przegapił tak wspaniały język. Fakt jest taki: autor Railsów celowo wybrał Rubiego, a jego „dziki” zakład opłacił się ogromnym zainteresowaniem. To, co wtedy widział, wielu innych może zobaczyć dzisiaj. Ruby w jakiś sposób umożliwia programistom specjalny rodzaj, który jest tak trudny do wytłumaczenia „niemytym masom”. Dlaczego więc używać Ruby on Rails? Ruby uszczęśliwia programistów, jak reklamowano.

Podczas gdy większość programistów zgadza się, że Ruby jest przydatny, niektórzy uważają go za przesadę . Martwią się o to, co może się stać ze wszystkimi wolnościami, na które pozwala Ruby, z całym potencjałem nadużyć. Pozwolę sobie zilustrować łataniem małp:

 "1".to_i #=> 1 class String def to_i raise 'foobar' end end "1".to_i #=> RuntimeError: foobar

To takie proste: za pomocą zaledwie pięciu wierszy kodu przejęliśmy istniejącą klasę i nadpisaliśmy jej zachowanie. Nic nie jest święte – nawet sznurek. Ten konkretny błąd byłby łatwy do zauważenia, ale sprawy mogą stać się znacznie bardziej złowrogie:

 class String def to_i self.to_f - 1.13 end end "2".to_i #=> 0.8700000000000001

Tak po prostu, wprowadziliśmy błąd do klasy String, który może być zawinięty i zasłonięty przez kolejne warstwy złożoności.

Możesz więc pomyśleć: Czy wszyscy i ich matka mogą zepsuć mój cenny wniosek? Chociaż to zachowanie rzeczywiście wygląda przerażająco – tak naprawdę nie jest. Przez pięć lat używania Rubiego nie miałem dokładnie żadnych problemów z tym zachowaniem. Może wydawać się to sprzeczne z intuicją, ale z drugiej strony, podobnie jak jazda samochodem z prędkością 60 mil na godzinę w przeciwnych kierunkach, oddzielonych tylko cienką białą linią pośrodku drogi. W praktyce oba działają wyjątkowo dobrze.

Kolejną korzyścią jest to, że Ruby jest wszechstronnym narzędziem. Jako taki ma ostre, przypominające nóż krawędzie. Lubię myśleć, że dorośli dobrze sobie radzą z nożami – zabezpieczenie przed dziećmi jest dla… cóż, dzieci (Tweet). A bycie traktowanym jak dziecko w IT sprawia, że ​​stajesz się ofiarą paradoksu Paula Grahama z Blubem: myślisz, że lepiej ci jest bez pewnych cech, których nie rozumiesz lub o których ktoś powiedział ci, że jesteś zbyt niebezpieczny. Oczywiście dzisiaj pytamy „dlaczego używać Ruby on Rails”; jest to więc debata na inny czas. Trzeba przyznać, że Ruby traci niektóre funkcje, które mają inne języki (Lisp hmm, hmm). Podsumowując, Ruby jest blisko szczytu „kontinuum władzy językowej”.

Moje pierwsze lata z Ruby były upokarzające. Tak wiele się nauczyłem, czytając kod innych. Czasami byłem zdumiony; czasami byłem wściekły; ale ostatecznie ta wiedza pozwoliła mi komunikować się z komputerem znacznie efektywniej niż wcześniej. Niemal żal mi innych języków „biurokratycznych”, które zmuszają cię do przeskakiwania przez obręcze tylko po to, by przez nie przeskakiwać, a wszystko to mówiąc ci: „Robię po prostu to, co jest dla ciebie najlepsze, to dla twojego własnego dobra!”

Pragmatyzm

Istnieje głęboki szacunek dla pragmatyzmu wplecionego w DNA Railsów na najniższym możliwym poziomie. W połączeniu z korzyściami płynącymi z Ruby, ten pragmatyzm tworzy eleganckie rozwiązania i zachęca/inspiruje społeczność programistów Ruby on Rails do robienia tego samego. Pragmatyzm jest często reklamowany jako namiot Railsów, więc to twierdzenie nie jest niczym nowym, ale o jego prawdziwości przypomniało mi się całkiem niedawno, gdy mój przyjaciel próbował mi pokazać, jak „fajny” jest Hibernate. Walczył. Czułem jego ból, ponieważ nie był w stanie ustawić niezliczonej ilości opcji i parametrów konfiguracyjnych, które powinny być domyślnymi ustawieniami frameworka.

Z wiekiem moje standardy dotyczące sztucznej złożoności rosły coraz wyżej. Biorąc pod uwagę, że zacząłem pisać kod produkcyjny w 1989 roku w wieku 11 lat (zaczynając od projektu dla mojego sąsiada w Clipper Summer '87), mam prawie zerową tolerancję na niepotrzebne komplikacje. A Rails osiąga naprawdę wysokie wyniki w tym dziale. To coś więcej niż tylko „konwencja nad konfiguracją”; Mówię o całym pragmatycznym sposobie myślenia, który jest wysoko ceniony w społeczności Rails i przenika przez nią.

Wyrazistość

Railsy są tak zbliżone do angielskiego, jak to tylko możliwe (chyba że używasz COBOL). Wykorzystuje to, co jest znane jako wewnętrzne DSL, rozszerzając Rubiego o własną semantykę. Konstruowanie DSL jest zawsze niebezpieczne, ponieważ skutecznie rozwijasz nowy język. Ponieważ jest wewnętrzny, nie musisz używać zewnętrznego parsera, ale w pewnym sensie wydaje się to być nowym językiem. Zespół Rails osiągnął dobrą równowagę dzięki DSL, używając go tam, gdzie ma to sens i rzadko przesadzając, demonstrując doskonałą samokontrolę. Myślę, że każdy programista, niezależnie od doświadczenia w Railsach (a nawet niektórzy nie-programiści) może to zrozumieć:

 class User < ActiveRecord::Base devise :database_authenticatable, :registerable validates_numericality_of :years_of_experience, :allow_blank => true acts_as_taggable acts_as_taggable_on :certificates, :expertise_kinds validates_presence_of :first_name, :last_name, :email has_many :translations has_attached_file :avatar, :styles => {:small => "240x240>"} has_attached_file :cv ...

W rzeczywistości, jeśli nie znasz Rubiego, może to wyglądać dziwnie – to prawie tak, jakby nie był to język programowania. Gdy zdasz sobie sprawę, że to tylko wywołania metod bez nawiasów, możesz zacząć. Mimo to Rails DSL wydaje się być tym specjalnym językiem do opisywania wymagań, podczas gdy w rzeczywistości jest to po prostu inteligentne nazewnictwo i nieodłączne wykorzystanie doskonałej składni Rubiego.

Społeczność

Railsy mają armię współpracowników, którzy dbają o to, by pozostała w doskonałym stanie. Wiele projektów gotuje się z wiekiem, ale dzięki Railsom wciąż iskrzy, gdy trzeba podjąć decyzje. Wydaje się, że opiekunowie (nadal) naprawdę troszczą się i chcą, aby ludzie używali Ruby on Rails i rozumieli jego zalety.

Pod samym Railsem, jako wisienka na torcie, stoi Ruby z jego potężnym menedżerem pakietów, RubyGems, porównywalnym do CPAN pod względem liczby pakietów – i biorąc pod uwagę wiek CPAN, twierdzenie to jest (delikatnie mówiąc) bardzo imponujące. Railsy wykoleiły się na chwilę, gdy próbowały tworzyć własne „wtyczki do Railsów”. Na szczęście to się nie utrzymało, więc RubyGems pozostaje zunifikowanym, doskonałym źródłem kodu programowanego przez bardzo bystre osoby.

Synergia między fajnym językiem, pragmatycznym frameworkiem sieciowym i wspaniałą społecznością daje Railsom wynik znacznie lepszy niż suma jego części.

Dojrzałość

Railsy krążyły wokół bloku. Na swój hipsterski sposób, to już nie jest takie fajne. To dobrze, jeśli chodzi o wybór stosu technologicznego: chcesz czegoś sprawdzonego. A Rails jest właśnie tym. Niedawno napisaliśmy artykuł mówiący o szerokiej gamie dostępnych obecnie interpreterów i środowisk wykonawczych Ruby.

Marketing

Wiem wiem. Jako informatyk powinienem naprawdę cenić „poważne” rzeczy i ignorować „brokat” . Może wydawać się płytkie, ale spójrzmy prawdzie w oczy:

1. W porównaniu z konkurencją, strona Railsów wygląda dobrze .
2. Pierwszy rzut ekranu Railsa w tamtych czasach po prostu zapierał dech w piersiach. Może nie wygląda to dzisiaj tak imponująco, ale pamiętaj, że jedynym powodem, dla którego wszyscy wiemy o Javie, jest to, że wszyscy byli tak podekscytowani możliwością uruchomienia apletu Java w przeglądarce. Okazało się, że nie jest to aż tak ważne, ale mimo to stawiało Javę na celowniku. Podobnie ten 15-minutowy screencast z silnika bloga był wielkim hitem, który podekscytował wiele osób.

Tu nie chodzi nawet o próżność; chodzi o zaangażowanie jak największej liczby mądrych ludzi, aby wlali wodę do młyna. Kiedy rozważane są frameworki, najlepszym miejscem jest tłum. Wybranie struktury, na której skupiają się ci mądrzy ludzie, oznacza po prostu, że o wiele więcej jest już dla Ciebie przygotowanych. I to prowadzi mnie do następnego punktu.

(Nie) wymyślanie koła na nowo

Mam słabość do maleńkich frameworków. Lubię, kiedy mogę zrozumieć, co robi dany framework i dlaczego. W tym sensie Railsy są nieco nadęte, a czasami nawet przytłaczające.

Tu pojawia się dylemat: ile razy chcesz pisać w kółko te same rzeczy? Niektóre z nich można napisać lepiej, jestem pewien, ale wymaga to czasu – dużo czasu. Im więcej pozwolisz Railsom zrobić dla siebie, tym mniej będziesz musiał się martwić o przepisanie lub ponowne zaimplementowanie swojej funkcjonalności.

Railsy to (jak mówią) „baterie w zestawie”. To nie jest dobra rzecz, jeśli lubisz oszczędzić lub jeśli czujesz potrzebę posiadania rozległej wiedzy na temat tego, jak wszystko działa. W praktyce, jeśli odpuścisz swoje lęki, wydaje się, że to działa. Railsy mają rozsądne wartości domyślne dla prawie wszystkiego, czego potrzebujesz i są wystarczająco modułowe, aby uniknąć zakręcania w ciasnych miejscach.

Wniosek

Zadaj sobie ponownie pytanie, po co używać Ruby on Rails? Railsy są odpowiednie zarówno dla najnowocześniejszych publicznych stron internetowych, które konkurują z jednostronicowymi aplikacjami JavaScript, jak i dla złożonych aplikacji systemowych korporacyjnych, które zwykle wyglądają nieco „gorzej” (z bardziej ogólnym interfejsem użytkownika o niższej wierności), ale rekompensują to skazy z mnóstwem skomplikowanych reguł biznesowych i logiki. Jego zaletą jest to, że jest wszechstronny i może konkurować zarówno z eleganckimi, jak i potężnymi.

W przypadku większości typowych problemów, Railsy mają do Twojej dyspozycji komponent niemal natychmiast po wyjęciu z pudełka z dokumentacją, która jest stale powyżej średniej (jakoś główny zespół Railsów przekonał współpracowników, że pisanie dokumentacji jest fajne (nawet jeśli wszyscy wiemy, że jest nie), co prowadzi do dobrze napisanych, zwięzłych i oszczędzających czas dokumentów).

Kiedy odłożysz na bok jednorożce i piątkowe uściski, otrzymasz potężną strukturę, której możesz użyć zarówno do przyszłego zmieniacza gier, jak i następnej witryny biznesowej na środku drogi. A dzięki puli najlepszych klejnotów masz na wyciągnięcie ręki arsenał, który wdraża niektóre z najjaśniejszych pomysłów w programowaniu komputerowym. Bez zamieszania.