Артемий Клименко - Вы за это заплатите! Цена чистой архитектуры
Vložit
- čas přidán 5. 07. 2022
- Ближайшая конференция: Mobius 2024 Spring, 23 мая (online), 31 мая - 1 июня (offline, Москва)
Подробности и билеты: jrg.su/EH5c9Q
- -
Есть стереотипное представление о «Чистой Архитектуре», которое сформировалось однажды и не менялось годами.
Цель доклада - сломать этот стереотип.
Опытным слушателям, считающим, что тема уже давно раскрыта, этот доклад предоставит уникальный опыт и возможность взглянуть на вопрос за рамками стереотипа.
Опытным слушателям, не знающим, как правильно высказаться против, будет дана вся необходимая теория и аргументация.
Новички же смогут получить определение «Чистой Архитектуры», что позволит избежать завышенной цены. - Věda a technologie
Отличный доклад. Мне кажется, что автор не полностью раскрыл тему, можно было бы чуть больше накинуть реальных примеров приложений, чтобы на практике показать, почему клиент не имеет своего domain слоя, а лишь зависит от сервера. Но возможно это связано, с ограничением по времени, поэтому все равно доклад получился очень хорошим. Очень рад, что в мобильном сообществе стали публично поднимать тему «Чистой архитектуры» в мобилке. Докладчику респект
Так вроде чистая архитектура это не про конкретный подход, а про идею не делать кусок свалявшихся макарон. Ну и все таки дядю Боба надо внимательно читать - он же английским по белому говорит, что приведенные примеры - это исклюсительно примеры из ЕГО опыта, а не истинна в последней инстанции.
А теперь все те, кто верил в клин и "священные подмены"....
посмотрим как бесшовно "подменят" xml вьюхи на компоуз.
Ювелирно, не задев ни один слой. ))))
Работал раньше с Артемием. Войну интерфейсам он объявил еще в 2019-ом ))
и правильно сделал, ибо пихают их куда не надо.
👍👍👍
1. Почему раньше так важна была возможность "подмены"? Технологии бурно развивались, и с огромной вероятностью за время жизни проекта появлялись новые девайсы/библитеки/стандарты/подходы. И это новьё обязательно нужно было внедрить в свой проект. И, в общем то, неважно какой ценой.
2. Почему сейчас возможность "подмены" не так важна? Технологии устаканились. И до смерти проекта с огромной вероятностью вполне подойдет то, что было выбрано на старте проекта.
3. Поэтому, таки да! Соглашусь, что вполне оправдано говорить о "цене вопроса"
В ролике было сказано, что и сам автор книги выделяет необходимость интерфейсов в двух случаях:
1) Для защиты от внешних реализаций (под определение которых и подпадают все те независимые от нас вещи, как "платформа/девайсы/библитеки/технологии").
2) Для реализации инверсий зависимости, чтобы перенаправить зависимости на более устойчивые компоненты.
Это не оспаривалось :)
Хотелось отметить, что часто важна скорее возможность не "подмены", а полной "замены".
Для полной замены не так важны интерфейсы, как выделение технологии в компонент или в отдельный модуль.
Замена компонента или модуля в рамках архитектуры - дело не хитрое :)
Пример:
_________________
Допустим для хранения информации в файле в DataSource используется зависимость от платформы в виде SharedPreferences.
Если платформенная зависимость уже попала в модуль, то отгораживать DataSource интерфейсом бесполезно.
Если мы захотим заменить SharedPreferences на что-то другое, то это будет именно замена, а не "подмена", причем только для этого модуля..
Осуществляться подмена будет в любом случае в рамках компонента.
Интерфейс не нужен.
Если хочется защититься от платформы, то надо выделять работу хранения в файле через SharedPreferences в отдельный модуль.
Тогда замена одной реализации на другую будет осуществлена в рамках всего проекта.
При этом наличие интерфейса будет иметь роль в скорости сборки всего проекта в том случае, если была инверсия зависимостей.
Тобишь надо выделить отдельный Api-модуль c интерфейсом, от которого будут зависеть и Feature-модули, и выделенный модуль.
Тогда после замены не будет массовой пересборки модулей, пересоберётся только app модуль, который будет инжектить реализацию в другие модули.
Интерфейс нужен (для скорости сборки).
_________________
Некоторые технологии, внедряются сквозь все компоненты.
Зависимости от них не убрать выделением в отдельный компонент или отгораживаясь интерфейсом.
Пример Rx и Корутины.
Куда проще менять между собой Rx и Корутины во многомодульном проекте, в модулях которого минимальное количество компонентов.
Такую работу легко планировать. Без ущерба релизам :)
согласен.
направление в сторону устойчивости. и получается Entity самая устойчивая связь :)))))))))) ага, может быть когда все изначально предельно ясно как божий день то да. но в реальности это самая часто меняющая часть приложения. и все изменения растут оттуда.
Было же сказано, что устойчивый не равно редко изменяющийся.
@@vasiliychernov2123 так, и что я не так сказал? я с этим выражением согласен. Но я не согласен с тем что Entity самая устойчивая
@@andreyrudin2286 У устойчивости есть чёткое определение, поэтому нет смысла соглашаться с утверждением об устойчивости Entity или не соглашаться. Можно лишь измерить её в каком-либо конкретном случае, но речь о том, что их следует проектировать так, чтобы они были устойчивыми.
Из вашего первого комментария можно сделать вывод, что вы не согласны с тем, что Entity устойчивы, потому что они часто изменяются, что не относится к определению устойчивости. Я указал именно на это.
Похоже на троллинг.
Забыл упомянуть доаоды "за" интерфейсы:
1. Читаемость кода. Сравни, каково понять контракт читая интерфейс, и читая реализацию.
2. Командная разработка. Интерфейс согласовали и разбежались - один пилить клиентов, другой ревлизацию.
3. Документирование контракта. Публиковать реализацию класса?
4. Флейворы. Самый очевидный случай подмены реализации.
В целом доклад полезен тем, кто использует CA не особо понимая смысл. Начнут сомневаться, задумаются и о смысле :)
Никакого троллинга.
В докладе интерфейсы на переиспользуемые компоненты от модулей были продемонстрированы в рамках Api-Impl структуры. Они есть, их никто не отрицал.
Интерфейсы в Api-Impl структуре оправданы теми же целями, к которым стремится Чистая Архитектура, но рассуждение о структурах - это уже предмет для другого доклада)
Речь шла только о том, как можно избавиться от лишних компонентов, которые нельзя оправдать принципами Чистой Архитектуры.
Если все доводы "ЗА" были продуманы в противовес сказанному в докладе о компонентах внутренней реализации модулей, то мне есть что ответить:
1. Вы говорите "Сравни, каково понять контракт читая интерфейс, и читая реализацию." - сравниваю:
В контракте читаешь методы, в реализации они никуда не делись, также читаются. Не вижу проблем.
Проблемы начинаются в другом месте. Если в реализации количество методов увеличивается до такой степени, что проще выделить интерфейс для улучшения читаемости и понимания того, что компонент делает, то это явный признак, что с реализацией что-то не так. Скорее всего не были выделены необходимые компоненты и всё было скинуто в одну кучу.
Это опять же говорит в пользу меньшего количества компонентов, т.к. быстрее определяются подобные проблемы (еще на этапе Core Review).
Более актуальный вопрос при поддержке больших проектов - "Что лучше для читаемости? Десятки компонентов или единицы?"
2. Вы говорите про "Командную разработку":
Я делал выводы основываясь на опыте разработке в команде из 60+ андроид-разработчиков. Потому доклад был в первую очередь про увеличение скорости разработки на большом проекте в большой команде.
Общая работа нескольких разработчиков над одной фичей может параллелиться по модулям. А бить мельче будет в ущерб скорости. При этом не важно с интерфейсами вы бьете или без них.
3. Вы говорите "Документирование контракта. Публиковать реализацию класса?":
Не совсем понял, что вы имеете в виду под публикацией.
Если вы подразумеваете создание модулей в рамках одного проекта, то остаётся определить, где действительно нужны интерфейсы, а где нет.
Если вы публикуете модуль, который люди смогут подтянуть и переиспользовать на любом проекте, то делайте интерфейс, если не хотите, чтобы люди видели с ходу вашу реализацию. Но это не оправдано Чистой Архитектурой.
Тот же Retrofit идёт без интерфейса сразу с реализации. Мне как пользователю достаточно было прочитать документацию, чтобы его использовать. Если бы вдруг кто-то добавил интерфейс перед ним, то лично мне это никак бы не помогло освоить его быстрее.
Более того интерфейс на сторонних либах может, не то, чтобы навредить, но быть сильно излишним. Допустим, есть 2 разные либы от разных разработчиков, но предназначенные для решения одной проблемы (например Glide и Picasso). Каждый создаст под себя свой интерфейс, который не был никем унифицирован. Эти интерфейсы между собой не совместимы. Чтобы осуществить подмену одной либы на другую, нужно как-то их унифицировать и отгородиться от внейшней реализации собственным интерфейсом. Опять получится чехарда (интерфес-реализация)*внутрениия - (интерфейс-реализация)*внешние. Кому поможет этот внешний интерфейс в данном случае? Чем он был оправдан?
В общем, если говорить про внутреннюю реализацию модуля, то интерфейсы на каждый компонент не нужны. И не важно публикуете вы для своего проекта или для всего мира.
4. Вы говорите "Флейворы. Самый очевидный случай подмены реализации.":
Флейворы существенно замедляют скорость сборки проекта. Если вы боретесь за скорость разработки, то нужно уменьшать скорость сборки. На больших проектах это становится существенным фактором. Лучше пользоваться debug и release implementation-ами, а если надо, то добавить еще и своих вариантов, например QA.
Активно ими пользуемся при подмене и пока не было никаких проблем. Могу спокойно утверждать, что это не только не противоречит сказанному в докладе, но и хорошо вписывается в архитектуру.
В итоге могу сказать, что все перечисленные аргументы не актуальны для наших проектов, где мы боролись за масштабируемость, которая является одним из основных факторов скорости разработки.
Лайк не глядя
Фигню какую-то рассказывает про невозможность подмены двух баз через общий интерфейс. Чел просто не умеет проектировать интерфейсы. Как будто велика победа выкинуть 3 дефиниции чтобы перестать думать должном проектировании.
Это сарказм?)
А то в ролике ни слова про "Невозможность"
Было сказано, что разные источники данных (оперативная память, файл, БД, сеть) имеют сильные отличия в своих свойствах между собой
Было аргументировано, что необходимость подведения разных источников данных под один интерфейс будет не легко обосновать
@@user-ho3gn9lg7q Никакого сарказма. На 18:42 вы сообщаете что (цитирую) "файл и БД отличаются серьезно, вы НЕ СМОЖЕТЕ подвести это под один интерфейс". Это опасное заблуждение. Типичный пример, показ картинки из кеша на файловой системе или из иного источника, при должном проектировании компонентов, потребует именно общий интерфейс для доступа. Вы наверное думаете, что этот интерфейс должен реализовывать всю полноту возможностей условной БД что невозможно для работы файловой системой. Но проектировать надо отталкиваясь от потребностей собственной системы. Нет никаких проблем реализовать инстансы, например, FSDataSource и DBDataSource имея общий интерфейс DataSource и пользоваться "Стратегией" для выбора реализации в рантайме.
ЗЫ: При всём уважении к вашему опыту, стоит поработать еще годков 5-7 чтобы во всей полноте осознать почему публичные заигрывания с Clean Architecture принесут больше вреда чем пользы вашему продукту, и тем потащит эти идеи к себе. Почитайте ниже. Маслята всерьез рассуждают о подмене XML вьюх на компоуз не задев ни один слой. 🤦♂Наслушавшись вас будут утверждать что если замена способа отображения аффектит нетворкинг, то это нормально.