Od dawna chciałem napisać coś konkretnego na podstawie Railsów (udało mi się napisać jakieś 5 małych aplikacji, głównie z tutoriali), jednak potrzeba zarobienia na chleb doprowadziła do tego, że pracuję w PHP korzystając z framework’ów takich jak Symfony czy Laravel. Ostatnio znalazłem trochę czasu i zacząłem odświeżać wiedzę na temat Ruby’ego i samych “szyn”.
Tutaj pojawia się pytanie - w jaki sposób organizowane są większe ilości kodu w projektach Railsowych? W Symfony rozwijając bundle mamy podział na formularze, kontrolery, serwisy, helpery itp. Z założenia serwisy wykonują czarną robotę a co za tym idzie akcja w kontrolerze ma raptem 2 linijki (w zależności od formatowania może mieć nawet 4 ). Jak wygląda takie zarządzanie kodem w Railsach? Czy możecie polecić jakieś artykuły na temat dobrych technik budowania aplikacji railsowych?
Zanim zacznę coś pisać muszę mieć to ładnie rozplanowane - ten typ tak ma
Ogólnie polecam trailblazera jeśli lubisz sobie tak wszystko poorganizować, może on w tym mocno pomóc.
Polecam też sprawdzić sobie jak robią to firmy w jakichś swoich open-sourceowych projektach (np. people od netguru jest całkiem fajnym przykładem wykorzystania przeróżnych patternów)
Do gemów od trailblazera podchodził bym ostrożnie. To jest kolejna warstwa w aplikacji. Railsy dodaja swoją magie a do tego dochodzi jeszcze trailblazer. Potem powstają problemy z aktualizacją aplikacji w RoR, bo trailblazer może nie być jeszcze dostosowany do nowej wersji RoR.
Moja rada to trzeba zrozumieć jak to działa, a potem można samemu napisać mini trailblazera z tym co jest tobie potrzebne. Od wielu osób słyszałem że miały problemy z trailblazerem i skończyło się na tym, że napisali coś samemu pod swoje potrzeby.
formularze (nie ma za bardzo nic wbudowanego poza prostymi helperami), ale jest kilka fajnych zewnętrznych gemów, np. reform, simpleform
Ogólnie mimo wszystko polecam nie kombinować za dużo na początku i robić po prostu “Rails way”. Z czasem, dopiero jak zaczną puchnąć kontrolery i modele, to stopniowo refaktoryzować. Oczywiście warto trochę wcześniej poczytać, ale ja osobiście nie zaczynałbym pierwszej wersji aplikacji od robienia serwisów etc. Powód: potem powstają jednolinijkowe serwisy, które utrudniają zamiast ułatwiać utrzymanie kodu (ale to oczywiście tylko moje subiektywne zdanie, jestem raczej szkoły: refaktoryzować dopiero kiedy coś zaczyna być problemem, a nie sztuka dla sztuki).
Dwa dobre artykuły i prezentacja na temat struktury: