Один из лучших каналов для Android разработчика. Четко! Понятно! Без лишней воды! Алексею большое спасибо!
@olegbeloy9279
2 жыл бұрын
Хорошее видео для общего понимания Я бы не привязывался к количеству строк в классе для разбиения. Главный принцип здесь - SRP. Если есть решение у команды использовать clean architecture, юз кейсы - будь добр использовать это во всех вью моделях и не тратить свои и ревьювера ментальные ресурсы на принятие решения. Потом класс разрастается и что - надо рефакторить, тесты переписывать. Проще изначально сделать правильно
@user-yg6fe2bs9u
2 жыл бұрын
Лучший видос про архитектуры! Большое спасибо)
@senk0n
2 жыл бұрын
18:34 - SUS А вообще спасибо за ролик, многим начинающим и не только будет полезно. Коротко и без избыточного углубления в тему 👌
@illyaevseev312
2 жыл бұрын
По поводу выбора архитектуры я всегда вспоминаю одно наше приложение. В один прекрасный момент один наш постоянный клиент просит нас написать приложение-логинилку. Т.е. ты сканируешь QR код, отправляешь запрос на бэк и происходит какое-то действие. Например логин в системе или открытие электронного замка. Не вопрос. Я пишу его за пару дней и мы довольные расходимся. Проходит немного времени и выясняется, что нужно еще показывать статистику приходов на работу после логина. Запросто. А потом менеджеры очень запросили выводить статистику по процессам. И каждый раз звучало что-то из серии "вот это вот и все". Примерно первый год. Сейчас это CRM с SIP телефонией, чатами и целой кучей функционала. Изначально я закладывал архитектуру с избытком по отношению к функционалу. Как же сильно я в тот момент ошибался ;)
@MobileDeveloper
2 жыл бұрын
Интересная история 😀 но выглядит, что как раз в этой ситуации избыточность могла вас спасти )
@illyaevseev312
2 жыл бұрын
@@MobileDeveloper Так я ведь тогда был абсолютно уверен, что перестраховался по полной. Хотя оказалось, что даже не начал страховаться.
@uservhhrXdgko1234
2 жыл бұрын
самый часто нарушаемый принцип, это принцип KISS Алексей правильные вещи говорит! Не усложняйте лишний раз.
@MobileDeveloper
2 жыл бұрын
Збазибо)
@dmitriykhalturin4918
2 жыл бұрын
КИСС мой любимый принцип!!!
@aleksandrvolkov4310
2 жыл бұрын
сначала ты ничего не усложняешь, не думаю о архитектуре, а потом через год говоришь бизнесу, что приложение не поддерживаемое и нужно переписывать)
@pavelkopytin
2 жыл бұрын
@@aleksandrvolkov4310 Надо понять одно, автор просто забыл упомянуть, архитектура приложения это ни что-то незыблемое, а она так же должна развиваться с ростом проекта. Как пример, на другом канале рассказали про правило трех, когда у вас есть какой-нибудь метод в одном месте, вы можете смело его скопировать в другое, может слегка изменить. Но вот если это приходится делать в третий раз - это повод задуматься о выделении данного метода в отдельный класс и переиспользовании. Архитектура - это живая сущность, растет вместе с проектом и должна отвечать только тем требованиям, которые существуют на данном этапе.
@MrKizup
2 жыл бұрын
Сразу видно, что видос прям о наболевшем) Еще бы это донести до тех аутсорс компаний, которые делают приложения и забывают про них, но надо обязательно упороться в "архитектуру", написать кучу лишнего и ненужного, чисто для того, чтобы показать мол видали, мы пишем "правильно"
@vasiliyditiatkin6848
7 күн бұрын
Спасибо дядь, норм раскидал. Замечал у андроиндщиков в коде прикол с интерфейсами которые имплементятся 1й реализацией.
@thunderdoge
2 жыл бұрын
От себя ещё накину, что любые правила, типа "если класс занимает больше N строк, то его нужно разбивать" конечно стоит держать в голове, но действовать все равно по ситуации. Если ваш класс хорошо согласован, не делает ничего лишнего, то пусть он занимает хоть 800 строк, вполне может быть так, что от разбиения код станет только запутаннее.
@MobileDeveloper
2 жыл бұрын
Ну в целом, да, но мы прям в линтере прописали эти правила и пока довольны )
@mironoff2007
Жыл бұрын
800 строк это с учетом пустых строк, скобок закрытия и тд? А то бывает и презентер на 5к строк
@Doctor.Livesey
Жыл бұрын
Делал сложный компонент на JavaScript. Вот там 1000 строк было примерно.
@pavelkorolevxyz
2 жыл бұрын
Поддерживаю мысль что нужно делать только то что нужно, а что не нужно не делать) Но с примером 19:08 когда отдельные модули делать не совсем согласен, в большинстве случаев над модулями начинают думать не когда команды параллельные есть, а когда твой монолитный модуль собирается минуту+ и это всех начинает напрягать. Главная их фича в том что и инкрементальный и клин билды намного предсказуемее работают, из-за чего проект можно скейлить и параллелить (А проблемы со временем сборки начинаются очень быстро, даже каких-нибудь 100к строк кода с каптом уже достаточно чтобы начать их ощущать). Так что это скорее про грэдл и котлин, и то как они устроены, а не про команду. И даже более того, если "эта параллельная фича тима" будет просто жить в отдельном модуле без правильного контракта, то она зааффектит сборку гораздо сильнее чем если бы они писали всё в том же монолите, потому что перед монолитом теперь надо их модуль целиком собрать. Я бы тут сказал скорее "не лезте создавать модули если не понимаете к каким последствиям это приведёт, лучше монолит чем плохая модуляризация".
@MobileDeveloper
2 жыл бұрын
Как правило если у вас этот модуль уже собирается по 30 минут, то фича команды прям уже за углом )
@immortal_lnight
2 жыл бұрын
У меня раньше был древнеримский ноутбук (6 ОЗУ), который проект на 2 экрана собирал 40 минут)))
@kirsan2353
2 жыл бұрын
@@maxhuman5898 А если очень хочется пощупать, и есть свободное время?
@mr-re1ax
2 жыл бұрын
Спасииииибо! Мне за 5 лет уже начало казаться что я единственный человек который это понимает😢
@B12animation
2 жыл бұрын
Я дед Евгений, внук установил мне язык программирования, я вхожу в Айти благодаря всем вам
@user-ms1yy5mk2t
2 жыл бұрын
Про интерактор, мне кажется стоит обратиться к первоисточнику kzitem.info/news/bejne/r6mg2Z2wa3NqoJw. Потому что ваше объяснение ему не соответствует и только путает. Поправьте, если я что-то не знаю про Viper, но насколько мне известно, то там интерактор имеет абсолютно тоже значение что и в clean architecture. Интерактор - это объект реализующий сценарий использования.
@pavelkopytin
2 жыл бұрын
абсолютно тоже самое и думал, интерактор это и есть юзкейс
@andk6893
5 ай бұрын
Очень полезное видео, просто бальзам на душу! )
@VINNY94051
Жыл бұрын
Делай как удобно, кажется это основной посыл видоса, мне например нравится закрывать классы интерфейсами (не все подряд очевидно) но если закрывать условную репу интерфейсом, так проще ориентироваться что есть внутри нее, просто почитал контракт с репой и погнал ее использовать (про многомодульность и тестирование тут не говорю)
@MobileDeveloper
Жыл бұрын
Скорее посыл видео, что не надо плодить лишних сущностей без необходимости
@lonely86boy
2 жыл бұрын
Отличное видео, даже для немного опытных! Когда включился свет на заднем фоне - немного испугался, потом увидел девушку - стало полегче
@azamat0180
2 жыл бұрын
Спасибо вам большое,Алексей!
@ksander4386
Жыл бұрын
Лучшее объяснение про архитектуру
@aleksandrvolkov4310
2 жыл бұрын
1) Почему то про модули не сказал для ускорение сборки, на огромных проектах без разделения невозможно. 2) Про архитектуру в общем: если убрать тестирование, то она нужна для понимания проекта новым человеком. 3) Нужен ли обязательно домен слой(если нет какой-то бизнес логики, просто сходи в сеть и покажи результат), вопрос очень холиварный. В частности надо ли делать маппинг даат классов на каждом слое, иначе api response ответ, объявленный data слое будет виден в presentation, что не по клину)) 4) Ещё бы добавить в видео пару слов о архитектуре, которая используется в гугловых примерах и кодлабах, многие берут оттуда, считая это эталоном.
@triihart
6 ай бұрын
8:30 жертвуем увеличением количества кода. на клине приходится писать в разы больше и код под задачу будет размазан по нескольким файлам, а не по одному
@asp424
2 жыл бұрын
Спасибо! Вы супер!
@MobileDeveloper
2 жыл бұрын
Спасибо!)
@kafychannel
2 жыл бұрын
спасибо за видео , было очень познавательно
@danilastepanov108
Жыл бұрын
Очень, очень годное видео! Спасибо)
@indiedistortion9986
Жыл бұрын
как же божественно запилил!
@alexrbh9515
4 ай бұрын
Лайк! Но про 600 строк хз, как по мне это слишком много для андроид проекта. Уже после 300-400 возникает чувство что что-то не так и SOLID где то умирает в сторонке)
@user-cl6gb6rg8f
Жыл бұрын
Блин, очень классно, спасибо большое 🙏🙏🙏
@olegleonov1310
2 жыл бұрын
Ну не только для команды или для маленьких проектов пишут архитектуру. Также для удобного написания тестов
@MobileDeveloper
2 жыл бұрын
Кто бы ещё писал эти тесты
@olegleonov1310
2 жыл бұрын
@@MobileDeveloper На последних двух работах всегда пишем) В SberDevice, Epam.
@dmitriykhalturin4918
2 жыл бұрын
@@MobileDeveloper ))))) на сто 46 % согласен
@Anadol777
Жыл бұрын
Ультра полезное видео, спасибо!
@amiakari7700
3 ай бұрын
Спасибо за видео!
@dmitriimitryaev6508
3 ай бұрын
чел ты хорош
@sovrinfo
2 жыл бұрын
Спасибо за видео.Коммент в поддержку!
@MobileDeveloper
2 жыл бұрын
Спасибо!
@bulsond
2 жыл бұрын
Функция в 50 строк? На мой взгляд, это до хера. 10-20 строк максимум, функция должна делать только одну логическую операцию если иначе, то ее необходимо разбивать на ряд малых фукций.
@alexandersmirnov4274
Жыл бұрын
что такое ентити зачем они нужны и чем отличаются от доменных моделей?
@user-df8xo5kw2p
2 жыл бұрын
Круто, согласен полностью и обеbми руками, ногами за каждое слово. Но только вот, еще бы на собесах от Junior не требовали бы clean architecture. Я конечно понимаю, что Junior должен хотя бы представлять, что это такое и на проекте не донимать вопросами дядей Seniors, что это такое и зачем. Но блин порой из-за дефицита кадров(Или жадности работодателей, все хотят за дешево спеца и сразу "херак-херак" продакшен) реально на позицию junior ищут midlle. И в итоге начинают делать pet проекты на 1-2 экрана с clean archeteture. Дабы показать, что они её знают, хотя она там нафиг не уперлась. Да и пониманию её, это ну ни разу не способствует:(
@awkwardquestion8643
2 жыл бұрын
Я думал сейчас от джунов такое по дефолту уже требуется
@user-zg3yu9xy6l
2 жыл бұрын
Интересное видео. У себя пришел к тому, что в 80% случаев в MVVM мне требовались только репозитории и в 20% - usecases к ним. Причем логика в usecase очень хорошо выделяется в процессе развития проекта, и изначально их плодить на каждый чих точно не стоит. Но не совсем согласен с запретом использования одного usecase из другого (горизонтальные зависимости) - если у них адекватное именование и взаимодействие внутри usecase логично и понятно, считаю, что не зачем городить еще один уровень абстракции создавая Interactor.
@BelokonRoman
2 жыл бұрын
Меня бомбит от джунов и мидлов, которые MVP на MVVM натягивают и Clean архитектурой все это погоняют, но при этом не знают фундаментальных вещей по типу чем List от Set отличается. А еще часто задаю очень простой вопрос на собесе: зачем нужна архитектура. И многих людей это ствит в тупик. И там идут ответы "Ну так надо" или "Все так делают"
@kafychannel
2 жыл бұрын
9:54 а как же тестирование наших датасорсов, подмена реализации. может быть, на одном скрине нам нужно сохранять данные A , а на другом мы хотим сохранять данные B . Вы предлагаете скопипастить DataSource для сохранения A , чтобы создать DataSource для хранения B ? тогда нарушается DRY . или нам нужно перед сохранением данных B удалять данные A , тогда это можно решить паттерном декоратор))
@MobileDeveloper
2 жыл бұрын
Я говорю про тёплое, а вы про мягкое Если нужно подменить это вопрос интерфейса, а не количества датасорсов. Про интерфейс там дальше будет
@user-ii9xe4pu6x
Жыл бұрын
Алексей, привет! А что-нибудь про микросервисы ты собираешься рассказывать? Был опыт?
@MxMayers
2 жыл бұрын
Я считаю если ты начинающий, "особенно начинающий" то архитектуру с юзкейсами и тд нужно пихать даже в калькулятор! Даже если ты не планируешь идти в команду, даже если это твое хобби от основной работы и ты не планируешь серьезно лезть в mobile development всегда везде следует делать архитектуру. Почему? Потому что должна вырабатываться привычка писать чистый читаемый код, это как в спортзале: если ты привык одевать пояс на присед с малым весом (допустим 30 - 50 кг), у тебя не будет проблем когда ты будешь приседать 90 - 120 ты первым делом автоматом будешь искать пояс потом только выполнять упражнение (безопасность превыше всего!). Еще пример: гораздо проще накидать юзкейсов и потом по ним продвигаться, чем сидеть и думать что тут должно быть или что тут еще можно добавить... я раньше не понимал подход database first типа "что за бред" 🤔, сейчас же наоборот, к UI перехожу в самую последнюю очередь когда все разложено "по полочкам" по пакетам по юзкейсам.
@bulsond
Жыл бұрын
Разочарую, но database first тоже неверный подход. Верный это DDD, то есть сначала domain. kzitem.info/news/bejne/q4WvxYeEhGWinWk
@temurisroilov5847
2 жыл бұрын
Топ контент: 🔥
@aung.95chit7
2 жыл бұрын
Happy birthday, God blessing you.
@MobileDeveloper
2 жыл бұрын
Thank you very much ☺️
@user-zi2sl7jh3t
2 жыл бұрын
ТОП ! Видео ТОП !
@MobileDeveloper
2 жыл бұрын
Спасибо )
@antonpopkov5003
2 жыл бұрын
Interactor и UseCase это разные названия одной сущности. Это одинаковые вещи, по-сути
@zoompartyru
2 жыл бұрын
Видео здравого смысла!
@artem.novikov_nn
6 ай бұрын
Я думаю потому и используются несколько разных по ответственности data source в одном репозитории изза того, что domain слоя нет
разбиение функций и классов должно быть конечно не по длине в строках, ибо длина в строках сильно зависит от особенностей конкретного языка и используемых конструкций, а в зависимости от цикломатической сложности и вообще здравого смысла. Т.к. функция или класс должны выполнять какое-то одно действие или быть расчитаны на одного актора, то это логически не позволяет классу или функции быть слишком большими, ибо они тогда начинают делать еще доп действия, которые они делать не должны
@hueynews7489
8 ай бұрын
Приветствую! Для меня как для недоджуна видео было максимально бесполезно. Надеюсь что я действительно всё пойму на реальном проекте :D
@kafychannel
2 жыл бұрын
14:04 а что если есть бизнес логика отображать моментально на юай обновление Вьюхи после действия юзера , результат выполнения которого требует времени (запрос в сетку) , то здесь как по мне идеально подойдёт вложенный интерактор в другой интерактор, отвечающий за запрос в реальную сетку.
@MobileDeveloper
2 жыл бұрын
Господи как сложно все )
@sergey30027
2 жыл бұрын
Хорошее видео, но если настолько упрощать архитектуру для проекта, который разрабатываешь один, то могут случиться исходники телеграма
@volodymyr107
2 жыл бұрын
Интересует как в случае клин архитектуры передавать токен в ретрофит. У последнего есть хорошая вещь для этого - интерцепторы и аутентификаторы, но тогда в нетворк модуль надо подключать базу или проперти и вытягивать токен из них
@Ast991
2 жыл бұрын
При чем тут клин к ретрофиту? Ретрофит должен разруливать, dagger, koin и т.д.
@illyaevseev312
2 жыл бұрын
Retrofit поддерживает очень много всего. Но совсем не обязательно использовать абсолютно все фичи. Даже если какие-то из них ну очень нравятся. Local и remote data source срастаются в Repository. Поэтому получить token из базы, если он хранится там, и отдать прямо в метод api.fetchSms(token, ...) не составит труда.
@Ast991
2 жыл бұрын
@@illyaevseev312 токен подвязывается напрямую в апи сервисе аннотацией @Headers. Можно руками прокидывать в кастомный интерцептор. Тут как барин пожелает.
@illyaevseev312
2 жыл бұрын
@@Ast991 По поводу @Headers. По-вашему я сказал что-то другое? По поводу интерцептора. Вы же помните, что мы говорим не о том, что можно написать интерцептор или нельзя? Мы говорим о том как поступить с точки зрения чистой архитектуры. Вы, конечно, можете меня переубедить, но пока я уверен, что кастомный интерцептор это remote data source и про базу данных вообще ничего не должен знать. Более того. Я уверен, что решать какой токен использовать и использовать-ли вообще должен в обсуждаемом случае все-таки repository.
@Ast991
2 жыл бұрын
@@illyaevseev312 при чем тут токен к архитектуре вообще? Не смешите мои носочки
@OverNoobDmg
2 жыл бұрын
Благодарю за видео. Единственное не понял почему плохо, чтобы юз кейс использовал другой юз кейс. Например я в приложении работаю на одном экране со списком сущностей1, а на втором экране со списком сущностей2. Сущность1 хранит в себе список сущностей2. Сущность2 хранить в себе список сущностей3. Если использовать в юз кейс только репозитории, то возникает дублирование кода при сборке сущности2.
@ulmaxy
Жыл бұрын
Горизонтальные зависимости плохи тем, что сегодня мы в UseCase1 добавляем зависимость от UseCase2 и у нас все вроде ок, а завтра оказывается что нам в UseCase2 нужна зависимость от UseCase1, и вот мы уже не можем пользоваться inject конструкторами даггера, потому что появляется циклическая зависимость (т.к. мы не хотим иметь несколько инстансов одного и того же юзкейса). В вашем случае если сборка сущности2 слишком сложная, то можно ее вынести в какой-нибудь отдельный делегат, и его инжектить в каждый юзкейс
@user-zs4es8gj4p
Жыл бұрын
Пол слова знающего человека могут стоить многих дней поисков.
@captainsustain
6 ай бұрын
Не согласен в деталях, да архитектура должна соответствовать масштабу проекта, но она всё равно должна быть, можно не использовать интеракторы/юзкейсы, но разбиение на модули и следование гайдам очень важно, тк во первых читаемость, расширяемость хорошая, и разделение ответственности автоматически, (+ интерфейсы лучше применять, и di и тестирование проще с ними) во вторых - в будущем на проекте будут работать другие люди, и они быстрее вьедут и не будет вопросов "че тут за говнокод". Плюс польза для самого себя - ты сразу заводишь привычку писать всё нормально, в итоге нет каши в голове типа "а надо тут или нет" - просто делай сразу нормально, и переделывать потом не надо будет, переделки множат говнокод и разнообразие в проекте, а хорошая архитектура - это минимум разнообразия в подходах. В больших проектах часто такое вижу, что модули сильно отличаются по реализации, надо пытаться минимизировать эту разницу
@user-uj4qx2wi8n
Жыл бұрын
Скажите, пожалуйста, по поводу тестового задания для джуна. Если задание стандартное вроде 2х экранов список + детали, то делать всё по clean(слои, интерфейсы, мапперы) - это в плюс идет или в минус?
@dmitrygus1631
9 ай бұрын
В сервисе используется postgres, redis, clichouse, rabbitMQ. Сколько должно быть dataSources? Не выдумка, реальный сервис - часть большого проекта.
@legioncommander7261
2 жыл бұрын
Репозиторий по канонам должен иметь только один датасорс. А вот уже интерактор может в несколько репозиториев ходить
@RareScrap
2 жыл бұрын
Спасибо за интересное видео. Но я не совсем понимаю почему горизонтальные зависимости плохи по вашему мнению? На мой взгяд когда для вычисления чего-то в юзкейсе нам нужен результат другого юзкейса - использовать его можно и нужно. Или вы считаете что лучше поставлять результаты других юзкейсов параметрами? Хотелось бы поимер ситуации когда вложенность юзкейсов вредит, а не помогает.
@diatm1506
6 ай бұрын
Немного не понятно в мобильной разработке. Нашёл круг A Comparison of Popular Flutter App Architectures (ui, web, db, external, interfaces, devices) внутри (controllers, gateways, presenters) внутри (use cases, entity) чем это связано с application layer (presentation, business logic, data access) и MVC, MVP, MVVM? В вебе всё делится на front end например angular(module->component->service->rest api) и back end например nest js (http request->controller->dto->service->dto->repository->entity->db) если не брать (Firebase как альтернативу) , а в мобилах всё вместе нету разделения на front и back? Ну хотя смотря какой вид рендеринга CSR(spa), SSR, SSG, LSR, RSC
@diatm1506
6 ай бұрын
О нашёл ios, swift clean arhitecture with MVVM Ui (view) , View model - presentation layer (MVVM) UseCase, interactor, entity - domain layer (business logic) Repository, data source, api/storage service - data layer (data repositories)
@hazye8801
2 жыл бұрын
Добрый день, когда ожидать видео про написание клиентской части playzone?
@orangebytheway
2 жыл бұрын
Привет, как тебе идея позвать на видео или стрим кого-нибудь из команды Language Design, и поговорить с ним о будущих дизайн фичах котлина, чем они сейчас занимаются, над чем больше всего работают и тд. Я думаю это будет оочень интересно
@dreamer6228751
2 жыл бұрын
Вот прям красавец, а то напилят калькулятор с 100500 усеркейсов)). Спасибо за видосик
@andrew3937
2 жыл бұрын
Чтобы иметь право решать что нужно, а что не нужно, надо быть мидлом-синьером) Об этом никто не говорит только))
@MobileDeveloper
2 жыл бұрын
В своём прокаты ты сам себе синьор
@MobileDeveloper
2 жыл бұрын
Да и на галерах часто ты сам себе синьор
@TamimProduction
2 жыл бұрын
А если у нас слишком сложная модель, которая например в себе содержает много данных и отношения к другим моделям, как с этим быть если дата сорс не может зависит от другого? Раньше у нас были разные репы для каждого из этих моделей, каждый раз тебе нужно хранить 1 модель тебе нужно зависит от кучу реп, и в некоторых местах эта логика повторялась, и пришлось добавить хелпер чтобы не копи пастить код, и с этим все у нас появилась проблема с консистентностью даннах. Мы решили что репа будет отвечать за главную модель, дата сорс также, но дата сорс зависит от других чтобы можно было хранить модели с которыми есть отношение, получилась у нас схема похожа на пирамиду, дата сорс ответственный за хранение главную модель, а за другие модели которые внутри ответственны другие дата сорсы, то есть дата сорс обращается к другим дата сорсам для хранения под-моделей, и потом только хранит свою модель. Другие дата сорсы также с начала обращаются к другим для хранения под-моделей и потом только свою. У нас так получилось решить проблему с кучей реп и кучей хелперов и других ответственных компонентов, также мы так гарантируем что данные хранятся в правильном порядке не важно какой у нас флоу, и все прозрачно так как нет никаких подводных камней.
@MobileDeveloper
2 жыл бұрын
Ничего не понял, но выглядит так как будто вам помогут юзкецсы )
@TamimProduction
2 жыл бұрын
@@MobileDeveloper У нас так было через юзкейсы/интеракторы. Но как показалась практика не очень подходящий вариант для сложных моделей и отношения между ними, мы решили сделать так, чтобы дата сорс был полностью ответственным за хранения всех этих данных, поэтому, в некоторых моментах когда есть many-to-many отношения, дата сорс может зависеть от другого. По старому подходу через юзкейсы у нас было грязнее намного. Пока я писал этот коммент, я понял что у каждого проекта своя специфика, и какие-то правила могут нарушаться чтобы не получить еще больше проблем, главное чтобы все было прозрачно и логично.
@TamimProduction
2 жыл бұрын
@@MobileDeveloper Спасибо за ролик) Шикарный)
@Mecenatt
2 жыл бұрын
Помниться написал на PHP форум , с модерацией и т.д , там не то что клин архитектуры не было , там даже ООП не использовалось . Ни одного класса . Долго не мог понять зачем вообще эти классы нужны .
@olegleonov1310
2 жыл бұрын
Я бы добавил, что должен быть source of truth в репозитории и логика по этой части должна быть там, остальная во ViewModel при использовании mvvm. Но это уже тема другого видео, похоже)
@MobileDeveloper
2 жыл бұрын
На эту тему можно бесконечно говорить )
@immortal_lnight
2 жыл бұрын
Сейчас пишу большое приложение в соло (похоже компании денег жаль) надеюсь, что если потом кому-то прийдётся разбираться с моим кодом он поймёт хД
@backoff6776
Жыл бұрын
Хм... интересно. У меня сложился похожий подход. Овэрхэдить на проэкте - не есть хорошо. Но я бы сказал, что UseCase полезен почти всегда. А вот в Repository, при налиичии кейсов, я вообще особого смысла не вижу. Да это добавит некую декомпозицию но она логически неоправдана. Если мне нужно сходить на 3 ресурса, имея при этом токен - я сделаю 1 кейс, который обратится к локальному источнику за токеном, позже сходит по цепочке на нужные удаленные источники, а в случае протухшего токена - сходит на auth сервеер, обновит токен и повторит действа. Зачем нужны в таком случае репозитории, объеденяющие источники попарно?
@telephon3208
Жыл бұрын
не поняла сравнение с бритвой окама))
@mr-re1ax
2 жыл бұрын
Оскара ему Оскара!!!
@-Alexey-
2 жыл бұрын
Какие 600 строк-то? Замучаешься файл мотать. Дядя Боб говорил про 50 в среднем, но не больше 100.
@matjon_dev
2 жыл бұрын
Нужно ли делать датасоурс, репоситорий для тестовых заданий, если даже 2-3 екрана и простая логика?
@MobileDeveloper
2 жыл бұрын
Нет, если только это не цель задания
@aleksandrvolkov4310
2 жыл бұрын
как раз таки надо. красивое и понятное разбиение по слоям и наличие тестов и любое тестовое будет пройдено. если ревьюверам не понравится ваша структура пакетов и классов для пары экранов, то шансы сильно понижаются. то что вы красить кнопочки умеете, итак подразумевается.
@devkonst
5 ай бұрын
Конечно, ведь цель тестового задания показать свои знания, а для проверяющего - оценить их. Любой профессионал скажет - что оверкодинг для тестового задания это отлично. Конечно же обе стороны должны понимать для чего это сделано.
@denrimden6333
2 жыл бұрын
Какие вопросы задают на собесе про cleanархитектура
@MobileDeveloper
2 жыл бұрын
В основном самые простые, а-ля что такое домен, дата слой. Зачем вообще все это нужно)
@denchic45
2 жыл бұрын
Единственная архитектура на андроид это чистая архитектура)) Mv* это же ведь шаблоны проектирования
@ryengard
4 ай бұрын
Чувак, когда говоришь умные мысли, у тя лютые мышечные тики на лице.
@MobileDeveloper
4 ай бұрын
А ты думаешь я не в курсе?
@sergeisalnikov6427
7 ай бұрын
просто треп
@dmitriyobidin6049
2 жыл бұрын
Блин, как же все сложно в этих мобильных приложениях…
@MobileDeveloper
2 жыл бұрын
Капец вообще 😀
@nadzeyakondrat184
2 жыл бұрын
интерфейсы нужны для тестирования. а это важно при любой арихитектуре
@illyaevseev312
2 жыл бұрын
Только проектов, где тесты не пишут, вагон и маленькая тележка. Если их писать никто даже не собирается, то в чем смысл их делать?
@MobileDeveloper
2 жыл бұрын
Эм, ну так я блин в видео же и говорю, что для тестов ок. Только как правильно заметил Илья приложений без тестов 99% Будешь тесты писать тогда и сделаешь интерфейсы
@leight9503
Жыл бұрын
Хм, ну я просто всегда юзаю модули с интерфейсами и DI контейнерами. Тупо везде и всегда. И ни разу не пожалел. Накладные расходы минимальные, MV family штуки получаются как бы сами по себе только там где нужны. Минимализм это здорово, конечно, но как вы потом будете тестировать ваш код без контейнера зависимостей и интерфейсов? Стоит на проекте появиться , хотя бы, одному программеру кроме вас и уже появляется необходимость тестировать ваш код. А это тянет за собой требование к наличию той самой архитектуры... Поначалу все всегда просто, а потом "пара обновлений дизайна, пара новых фичей" и вы уже в говне по уши :) Поэтому я б даже калькулятор писал с DI контейнерами, интерфейсами, модулями и какой-то базовой архитектурой. Ну, я , правда, в геймдеве, мб в других отраслях специфика иная, но тут говна поесть на этом можно очень легко.
@MobileDeveloper
Жыл бұрын
Как говорится на вкус и цвет ) я столько проектов знаю, где куча команд и при этом все руками тестируется, что искренне завидую, что вам так везет с автотестами ) Ну и сейчас можно прям классы мокировать) очень крутые либы стали
@leight9503
Жыл бұрын
@@MobileDeveloper нет, пока не доросли еще, к сожалению, до автотестов. Тестирую модули все еще "руками" из вспомогательных классов, но , по крайней мере, это делается изолированно от остального проекта, а не падает на QA отдел, или коллег уже по факту. Но очень сильно руки чешутся протащить полноценные тесты в проект, ибо не все получается отловить так, да и время занимает. Не подскажете, что дельного можно почитать на тему автотестов и в целом внедрения их в C# проекты? Специфика - Unity/ gamedev.
@MobileDeveloper
Жыл бұрын
В C# не подскажу ) у меня все таки мобильная разработка, но думаю та же пирамида тестирования она относится к любому виду программных продуктов
@leight9503
Жыл бұрын
@@MobileDeveloper угу, погуглю, спасибо!
@andrew3937
2 жыл бұрын
Освети многомодульность пж)
@MobileDeveloper
2 жыл бұрын
Освящаю! Да будет многомодульность ободрена, положена и в градл запущена!
@maksonic_official
2 жыл бұрын
@@MobileDeveloper 🤣🤣🤣
@user-hn8jl8ym1e
2 жыл бұрын
То же самое по поводу кучи библиотек, возможно они вообще не нужны в вашем проекте и все задачи стандартным набором разработчика. И изучение этих библиотек отнимает время, а под капотом они используют то, что вами давно познано и отработано. Сегодня одна модная библиотека, а завтра на вашу голову придумают еще десять. Делюсь мыслью.
@moni_panica
2 жыл бұрын
Лучше понял что такое "код ради кода"
@kalayda
7 ай бұрын
Сборник вредных советов. Главное голос поувереннее.
@frrrost1504
2 жыл бұрын
Пока никто не видит мои модели сами себя сохраняют в базу на .save() и умеют преобразовываться в другие модели dogRealm.threadSafeModel() ...
Пікірлер: 140