Ну это понятно, просто мб есть какая то последовательность? Я вот для себя вынес пока первое - разделение по полномочиям проверять

Всмысле последовательность? В идеальном мире тестится все

какая может быть последовательность. Перед тем как ты пишешь код, пиши на него тест

пишешь метод логики, пиши тест, потом пиши метод

Когда сайт конторе делал я много нашел косяков своих же, умные люди могли чужие сообщения например читать. Потом сел рефакторить и офигел от всего этого, вот тогда я понял, были бы тести сразу видно было бы где косяки

Такой косяк в отсутствие тестов на авторизацию

Таклй косяк потому что программист сам об этом не подумал

ну если бы он писал тест, он сфокусировал бы внимание

Просто тесты автоматизируют проверки и дисциплинируют проверять все кейсы.

Вово, верно

и облегчают поддержку и прикручивание новых фич

Ну и самое главное, внутри теста писать банально удобнее. Чистое повторяемое окружение

Где только то что ты тестируешь

еще тесты способствуют лучшему коду

если ты незнаешь как протестить значит где то идея solid поломалась

точнее S

OD помоему не применимо к рубям/рельсам щас освежу

не OD, LD - сомнительно

даже понять не смог

L это типа Service.run(arg) должно вызывать Service.new(arg).run?

поясните :)

def self.run(arg) Service.new(arg).run end def initialize @arg = arg end def run something end

я правильно понял?

тогда это паттерна а не принцип

кароче SOLID притащили как есть, а он из C++ как есть в рубях выглядит странно

эм что тебе в D не нравится

O нагло наршуется рубями повсеместно

ну и что

мы же говорим о построении своей аппы

от SOLID остается S__I_

не строй монстрских неповоротливых абстракций и будет тебе D

ничего не понял

наоборот же строй абстракции

ключевое слово неповоротливых же

только общее описание, никаких деталей

хотя я слабо представляю рельсовых проект где куча абстракций

все обычно раскладывается на сервисы

ну допустим S__ID

насчет O

это вроде песня, что манкипатчить зло

мне этот принцип не понятен из SOLID

потому что это преимущество руби

Ну идея в том, что если ты сделал класс, то его уже нельзя переназначать и его методы

а наследуя только расширять. Типа ты захотел расширить от него функционал и у тебя ничего не упадет

а ты не можешь переназначить методы унаследованного класса в рубях

Пиши класс такой, чтобы можно было наследовать и расширять, но не меняй его

а ты не можешь :)

что не могу, я могу запилить у дочки метод и переназначить его(но так делать нельзя).

class B < A def new super something end это уже метод класса B с ним можно все делать но я не вижу возможностей сделать что-то с А

я просто неудачно привел

а я не знаю удачных примеров может йопп знает

У меня есть удачный пример, но увы не мой и с платного курса. Разглашать увы не могу

Ибо достался мне бесплатно

дану падишта притянуто за уши с извращениями

и нужно закинуться чем-то чтобы так сделать

Можно сказать адаптирован под руби, но идея та же

Ну я не тот человек, чтобы судить и оценивать более опытных и прошаренных спецов

Я еще не все попробовал, поэтому рассуждать на тему чужих примеров сложно. У меня наследование какое то сложное встречается ну очень редко. Чаще фигачу сервисы везде и всюду

может где то получается и не совсем DRY но достаточно понятно и юзабельно

DRY тоже аккуратно надо юзать

Я бы сказал, что DRY не надо ставить во главу разработки

А то иногда так DRYят проект, навешают 100500 абстракций что не ясно как этот зверь вообще работает

и вхождение в проект выходит не дни и недели, а месяцы

"чем ты это сказал"

эффект йожыка

Да бывает

Я не успеваю писать за своими мыслями?

ERROR: S client not available

https://www.sitepoint.com/7-design-patterns-to-refactor-mvc-components-in-rails/?utm_medium=email&utm_campaign=SitePoint%20Ruby%20Newsletter%20-%20November%2022%202016&utm_content=SitePoint%20Ruby%20Newsletter%20-%20November%2022%202016+CID_13d8ae9f871f00a39b5e079f6d1c45ad&utm_source=CampaignMonitor%20SitePoint&utm_term=7%20Design%20Patterns%20to%20Refactor%20MVC

Все юзают эти паттерны?

ооо древняя статья подкатила

Или чего лишнего есть

Странно, в рубивикли была на неделе

да это классические паттерны

я не юзают value object

мне просто не приходилось

ты думаешь паттерны меняются каждый месяц?

а то пример что я привел интеракторы назвается только я не понимаю разницы между интеракторами и сервисами

Не, я же не гуру проггер, но пытаюсь юзать норм варианты

никакой

Опередил Антон

Только спросить хотел

Я в интеракторы вытаскиваю логику

Они могли бы сделать метод success в сервисе верно?

и в форм обджекте

это все по сути одно интерактор/сервис/форм_обджект

сервисы у меня чаще классы-обертки под апишки и сторонние сервисы, или какой то специфичный класс

Я вот думаю рефакторить вьюхи как тут в примерах или нет, с одной стороны подумаешь html, он всегда был, сдругой стороны смотришь все лаконично

Интеракторы это считалки логики

PopularVideoQuery.new.call(Attachment.all).to_sql - адский изврат

Это порно

вот такое точно не надо делать

scope лучше?)

это абстракция над сотнями скоупов

scope не лучше, он просто есть :)

и выборка может исходить из какой то сложной логики, в скоупах не очень логично складывать

Я вот думаю рефакторить вьюхи как тут в примерах или нет, с одной стороны подумаешь html, он всегда был, сдругой стороны смотришь все лаконично

зачем?

ну вот у меня парни написали скоуп for_active_campaigns который значит joins(:campaigns).where(campaigns: { state: :active}) меня такое скорее путает

Преждевременная оптимизация это как стрижка лысого

ну вот у меня парни написали скоуп for_active_campaigns который значит joins(:campaigns).where(campaigns: { state: :active}) меня такое скорее путает

Вот тебя бы, да всем моих лидам в пример