Артемий Клименко - Вы за это заплатите! Цена чистой архитектуры

[@ВиталийПерятин-с2ц]

Отличный доклад. Мне кажется, что автор не полностью раскрыл тему, можно было бы чуть больше накинуть реальных примеров приложений, чтобы на практике показать, почему клиент не имеет своего domain слоя, а лишь зависит от сервера. Но возможно это связано, с ограничением по времени, поэтому все равно доклад получился очень хорошим. Очень рад, что в мобильном сообществе стали публично поднимать тему «Чистой архитектуры» в мобилке. Докладчику респект

[@ГлебНикитенко-р7у]

А теперь все те, кто верил в клин и "священные подмены".... посмотрим как бесшовно "подменят" xml вьюхи на компоуз. Ювелирно, не задев ни один слой. ))))

[@alexeypipchuk5978]

Работал раньше с Артемием. Войну интерфейсам он объявил еще в 2019-ом ))

[@rudinandrey]

и правильно сделал, ибо пихают их куда не надо.

[@math_music_pixels]

Так вроде чистая архитектура это не про конкретный подход, а про идею не делать кусок свалявшихся макарон. Ну и все таки дядю Боба надо внимательно читать - он же английским по белому говорит, что приведенные примеры - это исклюсительно примеры из ЕГО опыта, а не истинна в последней инстанции.

[@KonstantinTarasov-q7q]

На фронтенде (чем по сути является мобилка) чистая/слоистая архитектура не нужна. Это правда. Уровень представления/интерфейс один. Соответственно переиспользования usecase для разных адаптеров не будет. СА - это архитектура для сложных бекенд приложений. Когда одинаковые сценарии переиспользуются для web, cli и прочих интерфейсов.

[@SergeyMazurkin]

1. Почему раньше так важна была возможность "подмены"? Технологии бурно развивались, и с огромной вероятностью за время жизни проекта появлялись новые девайсы/библитеки/стандарты/подходы. И это новьё обязательно нужно было внедрить в свой проект. И, в общем то, неважно какой ценой. 2. Почему сейчас возможность "подмены" не так важна? Технологии устаканились. И до смерти проекта с огромной вероятностью вполне подойдет то, что было выбрано на старте проекта. 3. Поэтому, таки да! Соглашусь, что вполне оправдано говорить о "цене вопроса"

[@АртемийКлименко-ы1у]

В ролике было сказано, что и сам автор книги выделяет необходимость интерфейсов в двух случаях: 1) Для защиты от внешних реализаций (под определение которых и подпадают все те независимые от нас вещи, как "платформа/девайсы/библитеки/технологии"). 2) Для реализации инверсий зависимости, чтобы перенаправить зависимости на более устойчивые компоненты. Это не оспаривалось :) Хотелось отметить, что часто важна скорее возможность не "подмены", а полной "замены". Для полной замены не так важны интерфейсы, как выделение технологии в компонент или в отдельный модуль. Замена компонента или модуля в рамках архитектуры - дело не хитрое :) Пример: _________________ Допустим для хранения информации в файле в DataSource используется зависимость от платформы в виде SharedPreferences. Если платформенная зависимость уже попала в модуль, то отгораживать DataSource интерфейсом бесполезно. Если мы захотим заменить SharedPreferences на что-то другое, то это будет именно замена, а не "подмена", причем только для этого модуля.. Осуществляться подмена будет в любом случае в рамках компонента. Интерфейс не нужен. Если хочется защититься от платформы, то надо выделять работу хранения в файле через SharedPreferences в отдельный модуль. Тогда замена одной реализации на другую будет осуществлена в рамках всего проекта. При этом наличие интерфейса будет иметь роль в скорости сборки всего проекта в том случае, если была инверсия зависимостей. Тобишь надо выделить отдельный Api-модуль c интерфейсом, от которого будут зависеть и Feature-модули, и выделенный модуль. Тогда после замены не будет массовой пересборки модулей, пересоберётся только app модуль, который будет инжектить реализацию в другие модули. Интерфейс нужен (для скорости сборки). _________________ Некоторые технологии, внедряются сквозь все компоненты. Зависимости от них не убрать выделением в отдельный компонент или отгораживаясь интерфейсом. Пример Rx и Корутины. Куда проще менять между собой Rx и Корутины во многомодульном проекте, в модулях которого минимальное количество компонентов. Такую работу легко планировать. Без ущерба релизам :)

[@SergeyMazurkin]

согласен.

[@kalayda]

Похоже на троллинг. Забыл упомянуть доводы "за" интерфейсы: 1. Читаемость кода. Сравни, каково понять контракт читая интерфейс, и читая реализацию. 2. Командная разработка. Интерфейс согласовали и разбежались - один пилить клиентов, другой реализацию. 3. Документирование контракта. Публиковать реализацию класса? 4. Флейворы. Самый очевидный случай подмены реализации. В целом доклад полезен тем, кто использует CA не особо понимая смысл. Начнут сомневаться, задумаются и о смысле :)

[@АртемийКлименко-ы1у]

Никакого троллинга. В докладе интерфейсы на переиспользуемые компоненты от модулей были продемонстрированы в рамках Api-Impl структуры. Они есть, их никто не отрицал. Интерфейсы в Api-Impl структуре оправданы теми же целями, к которым стремится Чистая Архитектура, но рассуждение о структурах - это уже предмет для другого доклада) Речь шла только о том, как можно избавиться от лишних компонентов, которые нельзя оправдать принципами Чистой Архитектуры. Если все доводы "ЗА" были продуманы в противовес сказанному в докладе о компонентах внутренней реализации модулей, то мне есть что ответить: 1. Вы говорите "Сравни, каково понять контракт читая интерфейс, и читая реализацию." - сравниваю: В контракте читаешь методы, в реализации они никуда не делись, также читаются. Не вижу проблем. Проблемы начинаются в другом месте. Если в реализации количество методов увеличивается до такой степени, что проще выделить интерфейс для улучшения читаемости и понимания того, что компонент делает, то это явный признак, что с реализацией что-то не так. Скорее всего не были выделены необходимые компоненты и всё было скинуто в одну кучу. Это опять же говорит в пользу меньшего количества компонентов, т.к. быстрее определяются подобные проблемы (еще на этапе Core Review). Более актуальный вопрос при поддержке больших проектов - "Что лучше для читаемости? Десятки компонентов или единицы?" 2. Вы говорите про "Командную разработку": Я делал выводы основываясь на опыте разработке в команде из 60+ андроид-разработчиков. Потому доклад был в первую очередь про увеличение скорости разработки на большом проекте в большой команде. Общая работа нескольких разработчиков над одной фичей может параллелиться по модулям. А бить мельче будет в ущерб скорости. При этом не важно с интерфейсами вы бьете или без них. 3. Вы говорите "Документирование контракта. Публиковать реализацию класса?": Не совсем понял, что вы имеете в виду под публикацией. Если вы подразумеваете создание модулей в рамках одного проекта, то остаётся определить, где действительно нужны интерфейсы, а где нет. Если вы публикуете модуль, который люди смогут подтянуть и переиспользовать на любом проекте, то делайте интерфейс, если не хотите, чтобы люди видели с ходу вашу реализацию. Но это не оправдано Чистой Архитектурой. Тот же Retrofit идёт без интерфейса сразу с реализации. Мне как пользователю достаточно было прочитать документацию, чтобы его использовать. Если бы вдруг кто-то добавил интерфейс перед ним, то лично мне это никак бы не помогло освоить его быстрее. Более того интерфейс на сторонних либах может, не то, чтобы навредить, но быть сильно излишним. Допустим, есть 2 разные либы от разных разработчиков, но предназначенные для решения одной проблемы (например Glide и Picasso). Каждый создаст под себя свой интерфейс, который не был никем унифицирован. Эти интерфейсы между собой не совместимы. Чтобы осуществить подмену одной либы на другую, нужно как-то их унифицировать и отгородиться от внейшней реализации собственным интерфейсом. Опять получится чехарда (интерфес-реализация)*внутрениия - (интерфейс-реализация)*внешние. Кому поможет этот внешний интерфейс в данном случае? Чем он был оправдан? В общем, если говорить про внутреннюю реализацию модуля, то интерфейсы на каждый компонент не нужны. И не важно публикуете вы для своего проекта или для всего мира. 4. Вы говорите "Флейворы. Самый очевидный случай подмены реализации.": Флейворы существенно замедляют скорость сборки проекта. Если вы боретесь за скорость разработки, то нужно уменьшать скорость сборки. На больших проектах это становится существенным фактором. Лучше пользоваться debug и release implementation-ами, а если надо, то добавить еще и своих вариантов, например QA. Активно ими пользуемся при подмене и пока не было никаких проблем. Могу спокойно утверждать, что это не только не противоречит сказанному в докладе, но и хорошо вписывается в архитектуру. В итоге могу сказать, что все перечисленные аргументы не актуальны для наших проектов, где мы боролись за масштабируемость, которая является одним из основных факторов скорости разработки.

[@captainsustain]

5. Инъекция в котлин делегаты. Тоже не понял, какую проблему пытаются решать. Все привыкли к +- одинаковым слоям, направлениям зависимостей и DI через интерфейсы, в итоге часовой доклад можно свести к "не используй интерфейсы там, где не надо", каких-то значительных плюсов или минусов нет, потому что видимо проблемы по сути никакой нет) Интересно было послушать рассуждения, задуматься, но практический смысл околонулевой)

[@alexanderlavrentev7187]

👍👍👍

[@rudinandrey]

направление в сторону устойчивости. и получается Entity самая устойчивая связь :)))))))))) ага, может быть когда все изначально предельно ясно как божий день то да. но в реальности это самая часто меняющая часть приложения. и все изменения растут оттуда.

[@vasiliychernov2123]

Было же сказано, что устойчивый не равно редко изменяющийся.

[@rudinandrey]

@@vasiliychernov2123 так, и что я не так сказал? я с этим выражением согласен. Но я не согласен с тем что Entity самая устойчивая

[@vasiliychernov2123]

@@rudinandrey У устойчивости есть чёткое определение, поэтому нет смысла соглашаться с утверждением об устойчивости Entity или не соглашаться. Можно лишь измерить её в каком-либо конкретном случае, но речь о том, что их следует проектировать так, чтобы они были устойчивыми. Из вашего первого комментария можно сделать вывод, что вы не согласны с тем, что Entity устойчивы, потому что они часто изменяются, что не относится к определению устойчивости. Я указал именно на это.

[@Denis196]

Лайк не глядя

[@AxelMcAlen]

Фигню какую-то рассказывает про невозможность подмены двух баз через общий интерфейс. Чел просто не умеет проектировать интерфейсы. Как будто велика победа выкинуть 3 дефиниции чтобы перестать думать должном проектировании.

[@АртемийКлименко-ы1у]

Это сарказм?) А то в ролике ни слова про "Невозможность" Было сказано, что разные источники данных (оперативная память, файл, БД, сеть) имеют сильные отличия в своих свойствах между собой Было аргументировано, что необходимость подведения разных источников данных под один интерфейс будет не легко обосновать

[@AxelMcAlen]

@@АртемийКлименко-ы1у Никакого сарказма. На 18:42 вы сообщаете что (цитирую) "файл и БД отличаются серьезно, вы НЕ СМОЖЕТЕ подвести это под один интерфейс". Это опасное заблуждение. Типичный пример, показ картинки из кеша на файловой системе или из иного источника, при должном проектировании компонентов, потребует именно общий интерфейс для доступа. Вы наверное думаете, что этот интерфейс должен реализовывать всю полноту возможностей условной БД что невозможно для работы файловой системой. Но проектировать надо отталкиваясь от потребностей собственной системы. Нет никаких проблем реализовать инстансы, например, FSDataSource и DBDataSource имея общий интерфейс DataSource и пользоваться "Стратегией" для выбора реализации в рантайме. ЗЫ: При всём уважении к вашему опыту, стоит поработать еще годков 5-7 чтобы во всей полноте осознать почему публичные заигрывания с Clean Architecture принесут больше вреда чем пользы вашему продукту, и тем потащит эти идеи к себе. Почитайте ниже. Маслята всерьез рассуждают о подмене XML вьюх на компоуз не задев ни один слой. 🤦‍♂Наслушавшись вас будут утверждать что если замена способа отображения аффектит нетворкинг, то это нормально.