Живот извън Rails controllers / models.

[Dimitar Panayotov]

Здравейте на всички.

Напоследък в няколко проекта, по които работя успоредно, усещам нарастващо отвращение към пъхането на важния код в модели и контролери. Има си и такова нещо като utility classes / functions естествено, но и това може да те докара само донякъде, след което започва да си води своите проблеми -- например спагетификация, защото в един момент пораства до 20 файла, всеки 1 от които разчита на всеки 5 други. Тъпо. :) А и според мен ако [lib/utils/] директорията ти има повече от 15-20 файла, не правиш нещо правилно.

Не ми се спори дали може да се натисне по-екстремно там (или в самия Rails код), за да се реши този конкретен проблем -- не е въпросът в това. Тези от вас които не работят на удобно / топло и с гарантирана заплата, а трябва да вършат нещата бързо и ефикасно и винаги за вчера, знаят това -- става дума да се намери решение което да не иска огромна начална (или нарастваща във времето) инвестиция.

Напълно съм готов и склонен да отделя 2 уикенда подред, за да си реструктурирам проектите, стига да сметна че някой определен подход е good enough.

Преди време бях видял такъв gem в GitHub, но за съжаление така и не успях да го издиря в history-то си. Той deal-ваше с понятия като actions, strategies и др. подобни [по принцип] неприятни ОО багажи. Но самият gem и подходът който предлагаше бяха общо взето най-простият, чист и видимо ефикасен метод.

Та...

(1) Можете ли да препоръчате gem? Или просто определен по-стриктен и неразрешаващ вечни изключения подход? Аз не просто търся добра идея -- такава мога и сам да си генерирам след 2-3 излизания с велосипеда с техно-транс музика докато катеря баира на Борисовата. :) Говорим за нещо което да е вече съградено (доколкото това е възможно въобще за такива по-общи заявки, естествено) и вече да е работило добре за някого.

(2) Как сте го правили вие в дълго-животни и нарастващи Rails проекти? Нещо изцяло специфично за вашия проект също е ценно да се знае, ако сте склонни да споделите.

(3) Дали сте чували определени препоръки, но не сте ги опитвали? Също е useful info.

Отворен съм за feedback, но нека опитаме да скипнем troll / професорски replies като "прочети някоя книга lol" или "ами напиши си по-добре business logic класовете, noob".

Благодаря предварително! =)

[Sava Chankov]

Здрасти и добре дошъл в клуба на надрасналите кофражите (a.k.a фреймуърци)!

Ние решихме отчасти проблема с бизнес логиката, като за новите фийчъри я държим изцяло в PORO (plain old ruby objects), а ActiveRecord използваме само за писане/четене от базата данни. Така тестовете на тази част на приложението литнаха и кодът е много по-четим - класовете ясно отразяват същности от областта на приложението, а не са разпънати на прокрустовото ложе на Rails. Хубавото на този подход е, че не изисква изцяло да си пренапишеш приложението, а можеш да го прилагаш само към новата функционалност, която добавяш и  постепенно да рефакторираш старите части, когато се налага. Подходът заехме от книгата Unfuck a Monorail for Great Justice на Giles Bowkett, която общо взето си струва само заради това.

поздрави,

Сава

[Valentin Mihov]

> Преди време бях видял такъв gem в GitHub, но за съжаление така и не
> успях да го издиря в history-то си. Той deal-ваше с понятия като
> actions, strategies и др. подобни [по принцип] неприятни ОО багажи.
> Но самият gem и подходът който предлагаше бяха общо взето
> най-простият, чист и видимо ефикасен метод.

Мисля че говориш за този гем: https://github.com/apotonick/trailblazer

Не съм го ползвал, но чувам хубави отзиви за него. Пиши ако го тествате
да разкажеш как е било при вас.

> (2) Как сте го правили вие в дълго-животни и нарастващи Rails
> проекти? Нещо изцяло специфично за вашия проект също е ценно да се
> знае, ако сте склонни да споделите.

Ние ползваме service objects. Това са PORO обекти, които имат
конструктор и един публичен метод и общо взето представляват ламбда
функции със state в тях. Като имаш по-сложна функционалност я слагаш в
един такъв обект, коjто създаваш и викаш от контролера или модела.
Обектите не се преизползват. По този начин всяко едно парче
функционалност живее в отделен клас със отделни спекове за него и е
доста лесно да се разцепи на малки методи за да е по-четимо.

Като цяло е готино, защото е лесно да подхване човек да го ползва и може
да мигрира постепенно. Ето един пример от проект, по който работя:
https://github.com/valo/maycamp_arena/blob/master/app/services/process_uploaded_file.rb

И спековете:
https://github.com/valo/maycamp_arena/blob/master/spec/services/process_uploaded_file_spec.rb

--Вальо

[Radoslav Stankov]

Здрасти,

В проектите, по който работя, правим доста подобни неща като Вальо и Сава. 

Нещо което правим доста често е да имаме Facade обекти:

```

# примерно

MediaStore.call(some_url) 

# и това връща

MediaStore::File || MediaStore::Error

```

Като зад MediaStore се крият една камара обекти. Примерно `MediaStore::Recognizer::YouTube`.

Всичко зад `MediaStore` модула са прости ruby обекти и не използва нищо от app/models или друга част от приложението. И като цяло се опитаваме цялата ни логика да бъде изолирана в такъв тип обекти. Разбира се някой неща са по-изолирани от другите :)

Разбира се не всичко е `Module.call` и не трябва да бъде. 

п.п. Малко "shameless self-promotion" - https://speakerdeck.com/rstankov/starving-activerecord

[Gudata]

Ей тука съм събрал няколко линка по темата.

http://www.yatoto.com/posts/1073194 

Погледни DCI и по-скоро примерният проект, който е направил към сайта за да илюстрира DCI. Изключително жив код.

 

On Friday, September 4, 2015 at 1:27:25 PM UTC+3, Dimitar Panayotov wrote:

[Evgeni Dzhelyov]

https://speakerdeck.com/rstankov/starving-activerecord презентацията на Радо е много добра! Силно препоръчвам, +1

[Dimitar Panayotov]

Пичове, благодаря ви много за всички отговори. Аз също намерих 2-3 варианта. С голям кеф и усмивка ще разгледам и вашите, и моите, но първо трябва да се измъкна от поредния списък от 37 тикета които правят неща по-добре от Facebook и Google взети заедно, и все пак трябва да са готови от един човек, за една седмица -- знаете как е, нали. :) 

OFF-TOPIC: Започнах да си търся нови дистанционни работодатели защото тези се чудят по колко пъти на ден ходя да пикая, за да ми вадят платени часове, следователно нещата отиват на зле с финансирането им, следователно не е лошо скоро да се дръпна от тях, преди да получа неприятна изненада в Inbox-а. Извинете за това, просто исках да се оплача от това какви задници хабят кислород. :(

Обещавам да се върна тук и да ви споделя впечатления и конкретни взети мерки.

Факт е че няма такова нещо като универсални мъдрости в програмирането (или където и да е другаде), но също така е факт че когато човек обясни защо техниката която е използвал/а му е спестила много главоболия и време и му/й е направила работата по-приятна, това винаги може да помогне на някой друг. Случвало се е с мен и с радост го причинявам на други хора когато имам уместната възможност.

Благодаря ви! Stand by за нещо по-конкретно когато премина поредния Superman + Hulk mode.

// Дими.