не спорю, но есть разные понятия "говняно"

ну вот пихать в конструктор все что попало это говняно

а если будешь делать все "правильно сразу" твой стартап обойдут те, кто сделал говняно, выпустил мвп, вышел на рынок, поднял инвестиции, набрал программистов и все переписал ?

ее истинный рельсвей

ну это утрировано конечно

а если будешь делать все "правильно сразу" твой стартап обойдут те, кто сделал говняно, выпустил мвп, вышел на рынок, поднял инвестиции, набрал программистов и все переписал ?

очень с порно

спорно угу

есть

не, нету. я говорю сугубо по собственному опыту и опыту людей вокруг себя. это вполне может быть не верно

а если будешь делать все "правильно сразу" твой стартап обойдут те, кто сделал говняно, выпустил мвп, вышел на рынок, поднял инвестиции, набрал программистов и все переписал ?

опять звучишь как CEO

но это не то, что говорил Антон

phone = Phone.new(twilio_adapter) phone.send_sms(a,b) phone.send_sms(c,d)

опять звучишь как CEO

ну значит следующую работу буду искать на СЕО

phone = Phone.new(twilio_adapter) phone.send_sms(a,b) phone.send_sms(c,d)

а если twilio_adapter зависит от юзера

phone = Phone.new(twilio_adapter) phone.send_sms(a,b) phone.send_sms(c,d)

ну, значит то

например в одной стране twilio а в другой не твилио?

а если twilio_adapter зависит от юзера

не зависит обычно

далаадно

phone = Phone.new(twilio_adapter) phone.send_sms(a,b) phone.send_sms(c,d)

phone = Phone.new(twilio_adapter: twilio_adapter, logger: logger) phone.send_sms(a,b) phone.send_sms(c,d)

phone = Phone.new(twilio_adapter: twilio_adapter, logger: logger) phone.send_sms(a,b) phone.send_sms(c,d)

TwilioPhone.new

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

мб сделать класс который решает какой адаптер использовать в зависимости от юзера

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

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

^

мб сделать класс который решает какой адаптер использовать в зависимости от юзера

поздравляю, ты изобрел java

ну его результат

например в одной стране twilio а в другой не твилио?

ок, тогда вот так phone = Phone.new(twilio_adapter_builder: twilio_adapter_builder, logger: logger) phone.send_sms(user1,b) phone.send_sms(user2,d) # .... twilio_adapter = twilio_adapter_builder.call(user) twilio_adapter.call(b)

TwilioPhone.new

^

поздравляю, ты изобрел java

Вголосину

TwilioPhone.new

и будет у тебя миллион классов TwilioPhone, HuilioPhone еще чота

не классов, переменных

или один билдер

классов

ну и че

решающий какой адаптер использовать

че дальше то

за ооп и двор стреляю в упор

дак я сам за ооп, но это не имеет ничего общего с ооп

не классов, переменных

переменных то почему

ну по факту классов да

ухххх жара

имеет

Вголосину

ну, ты смеешься, а порой идеи из джавы спасают

та понятно, что это шутки про ProblemFactory

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

да, я знаю, что например по open-close принципу надо сходу делать TwilioPhone

чтобы потом если надо добавить еще один тип телефона - просто создал еще один класс и усё

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

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

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

это тоже вечный флеймовый вопрос

неправильная абстракция безусловно вредит

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

найти баланс - задача разработчика

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

можно ее назвать неправильной раз не нужна)

ну так вот TwilioPhone не нужен, пока у тебя только twilio

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

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

и вот оно из "неправильной" становится "правильной"

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

это тоже не получится =)

и вот оно из "неправильной" становится "правильной"

ну и корявая абстракция так эе при изменениях может стать правильной

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

ну и корявая абстракция так эе при изменениях может стать правильной

ну вот я и считаю, что надо писать под то, что сейчас, а не под то, что может когда-нибудь получиться

ну вот я и считаю, что надо писать под то, что сейчас, а не под то, что может когда-нибудь получиться

но не означает что надо писать говно

ну вот я и считаю, что надо писать под то, что сейчас, а не под то, что может когда-нибудь получиться

о, тут очень тонкая грань

))

возвращаемся

о, тут очень тонкая грань

воооот

воооот

потому что ягни переоценено

но не означает что надо писать говно

ну если для текущих требований это не говно - то почему?

ERROR: S client not available

потому что ягни переоценено

печаль =( а шо ж теперь делать

печаль =( а шо ж теперь делать

думать головой

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

думать головой

именно

ну если для текущих требований это не говно - то почему?

это говно если сложно изменить

define "сложно"?

ну это когда начинаются вопросы а зачем а почему

и нет тестов

ваще нет

как рефакторить тогда

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

сегодня ударный день для чатика)

ну это когда начинаются вопросы а зачем а почему

о, так и до simple и easy дойдем

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

но ты всегда будешь знать что сломал когда есть тесты

конечно

и если вопросов а зачем а почему нет то у тебя дефакто норм архитектура

это сделает работу гораздо проще

и если вопросов а зачем а почему нет то у тебя дефакто норм архитектура

у кого вопросов нет?

ну я прикинул два критерия

тут все утверждения надо уточнять

но ты всегда будешь знать что сломал когда есть тесты

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

типа если они соблюдены то сложно менять

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

каку бы архитектуру ты ни выбрал

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

перефразируй плиз не уверен что понял

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

ну это есесно

перефразируй плиз не уверен что понял

юнит тестам нельзя на 100% верить

а чо юнит?

e2e

и даже интеграционным

я считаю что если архитектура хорошая то не будет вопросов по коду касающихся реализации после гебольшого брифа