Тайм-коды по расшифровке аббревиатуры: 3:05 S - Single Responsobility 4:17 O - Open-Closed Principle 5:48 L - Liskov Substitution Principle 8:28 I - Interface Segregation Principle 10:11 D - Dependency Inversion Principle
По поводу удорожания разработки согласен на все 100: на работе постоянно говорили, что надо быстро и тд, но зато потом: Макс, добавь сюда это, туда то и туда то, естественно добавление всего нового функционала быстро и безболезненно, и все довольны)
супер, все с примерами, "а теперь представим, что пришел менеджер и сказал ..." - так гораздо более понятен profit от хорошей архитектуры, примеры того, как не надо делать, тоже в тему, было бы здорово отдельно посмотреть про типичные анти-паттерны (GodClass уже был в видео, магические числа тоже, хочется еще) спасибо!
Никогда никому на ютубе ни на кого не подписывался и уж тем более не стваил "колокольчик". Тут Алексей может даже не просить об этом. Видео просто супер. Возможно не совсем для новичков, но подход и подача просто вышка! Готовлюсь к собеседованиям на джуна - Алексей очень помогает раскидать всё по полочкам. Почему бесплатно? (это не по русски и непривычно! ахаха)
@@MobileDeveloper Я имею в виду, например, в неком классе мне нужно получить текст с EditText и произвести с ним некие манипуляции. Как это сделать без activity context?
Mobile Developer да я его видел. Я имел ввиду серию обучающих видео, где было бы максимальное приближение к реальным проектам... с объяснением всех этапов разработки от и до... у вас хорошие уроки, плюс такой серии уроков в том, что бы вы на практике показывали где и как юзать разные инструменты. Пиши с телефона, что не очень удобно! Надеюсь я смог до вас донести основную идею.
У каждого бывает, смотришь старые коды и думаешь- что это вообще такое... Хорошее видео, наверное архитектура- одно из самых важных на начальном этапе Тестировать нужно на старом устройстве
Самый удобный для понимания пример по принципу L - это класс квадрата наследующийся от класса прямоугольника и замещающий реализацию сеттеров Width и Height так, чтобы при изменении Height, Width автоматически заменяется на то-же значение и наоборот. Для будущего пользователя будет сюрпризом такое поведение объекта приведенного к общему типу Rectangle. Для себя тогда сделал вывод, что в данном конкретном примере вообще не требуется такой класс как Square, т.к. это частный случай Rectangle. Поправьте, если я ошибаюсь в правильности способа как разруливать такую ситуацию.
В целом, принцип L по сути говорит нам о том, что при подстановке классов в переопределениях методах не должно быть какого-то поведения, которого ты не ожидаешь, поэтому если вы переопределяете метод setHeight и делает там ещё и setWidth это нарушение да, хотя особых проблем это вам не даст в этом случае, разве что лишние операции проверки при приведении к типу так как квадрат частный случай прямоугольника. А вот если вы просто сделаете новый метод у квадрата который сразу будет сетать сторону то с точки зрения архитектуры все норм )
Спасибо! Давно ждал. Понравились ваши примеры из реальных проектов. Почти нет лозунгов, которые очень отталкивают, когда смотришь чужие презентации, статьи про архитектуру. Обычно приводят какие-то преимущества, которые скорее недостатки. В этом смысле вы аккуратны, не пропагандируете подходы, а лишь говорите, что с ними может быть лучше. Вообще все эти методологии помогают при определённых условиях. Раньше использовал Clean, MVP, сейчас вернулся на MVC и особо не жалею. Будем ждать новых серий.
Спасибо большое! ) Да мне вот это вот все на VIPER тоже не очень нравится) потом смотришь на проект где два вьюконтроллера зато все на вайпер написано. Согласен, условия должны быть подходящими
@@MobileDeveloper Да, я с вами полностью согласен! Забыл написать, что в случае с ArrayList не всё так однозначно. Я раньше тоже везде передавал List, но в последнее время также стал и ArrayList, MutableList (для адаптеров и операции addAll). Дело в том, что метод putParcelableArrayList требует исключительно ArrayList. Но я с вами согласен, если это возможно, лучше передавать родительский класс или интерфейс.
Alexander Nifanin тоже столкнулся с этой проблемой в parcelable )не знаю зачем они так сделали ) у меня есть отдельная функция которая берет на вход лист в любом формате и parcelable плюс ключ и возвращает parcel с уже вложенным массивом ) пришлось так сделать специально для этого случая
Расскажете про Интекрактор и Репозиторий? Очень запутанные сущности и все их понимают по-разному. Взять 100 проектов и везде связка Вью, Презентер, Интерактор, Репозиторий реализован по-разному. Очень хотелось бы посмотреть как это правильно сделать. Слышал, что Репозиторий надо инжектить, у него не должно быть ссылок на Презентер. Еще Презентер ведь просто посредник между вью и модел, но нет, кто-то там умудряется что-то обрабатывать. Вообщем куча вопросов. Ждем видео :)
Специально даже запуллил с репозитория рабочий проект и поменял одно очень часто используемое int свойство на String, но в контексте моего проекта это сработает, так как неинтовых значений не будет))
10:55 в теории - нет, на практике - обязательно. Ребрендинг должен затрагивать только стили, по идее, но в реальности оно затронет все, включая бэкенд, и провайдеров oAuth. Solid - хорош для промышленного софта, где код работает десятилетиями, но не для приложений бизнес уровня, где требования меняются каждый месяц
Мы спокойно провели небольшой ребрендинг, затронув, только дизайн систему фактически. Так что есть вещи, которые не меняются годами и в бизнес приложениях )
Из int в String: самое первое, что пришло в голову, это в геттере возвращать Integer.parseInt(), но встаёт проблема, что делать, если в параметре будет "unknown", возвращать какое-то другое значение, потом проверять, ну это уже костыль)
@@MobileDeveloper Чем плохо оставить int? Unknown - это ui-интерпретация нуля. Работы по-минимуму, все решается легкой модификацией ui-слоя. В БД так собственно и принято - если id=0 то insert, если >0 - то update. И нормально все себя чувствуют.
14:50 У моего друга на работе в продуктовой компании эффективный менеджер так и поступил. Был отдел отвечавший за мобильное приложение. Чтобы сэкономить отдали мобильную часть на аутсорс. Как быстро это скажется на качестве продукта? Поймет ли менеджер что совершил ошибку? Или экономия с точки зрения менеджера будет предпочтительнее чем потеря качества? Может менеджмент посчитал что приложение полностью готово и дальнейшие изменения будут требоваться очень редко и для этого не надо содержать своих мобильных разрабов? Почему в этой ситуации просто не провели сокращение в мобильном отделе? Зачем уничтожать отдел теряя контроль над разработчиками? С деньгами в компании все очень хорошо, просто нужно было сэкономить и тем самым повысить прибыль.
Менеджеру нужно было выполнять свои KPI и он их выполнил. Вообще выстраивание эффективной модели в компании это тема отдельных научных работ) Потому что любую систему будут пытаться взломать)
хорошо! но для совсем младенцев, может посоветуешь что-то почитать об архитектуре? Или покажешь простенький пример, как проектировать приложение, так сказать от идеи до кода ) а то сейчас смотрю свои аппы, а они похожи на то, где в адаптере 1200 строк )))))
По архитектуре нельзя прочитать что-то одно и просветлиться) Нужно брать паттерны (они всем известны) читать, пробовать, читать, пробовать и так далее. В будущем будет да вебинар, где я буду делать нечто подобное
@@MobileDeveloper "они всем известны" вот не всем )))) Если я буду говорить о себе, то в "высокое" программирование я погрузился где то с полгода назад, до этого 15 лет занимался программированием контроллеров, там несколько другая песня, а точнее больше плясок с бубнами ))) Тем не менее, читаю, изучаю... хорошо, что есть стековерфлоу и гитхаб))) но чем больше изучаю, тем сильнее понимаю, что я ничерта не знаю ((( тем не менее за полгода успешно зарелизил 3 приложения а сторе, первое время, только и занимался, что изучал стектрейс в крашлитикс )) Хочется плавать глубже, но как это сделать, если толком на поверхности плавать не умеешь... алгоритмы, структуры данных - это не проблема, проблема в том, что хочется делать красиво и быстро, как взрослые бородатые дяди )) буду благодарен, если получу пинка в направлении "что такое" паттерны и где их брать ))) Взамен на вебинар могу что-то полезное сделать для канала, а если будешь в Томске, то могу угостить самодельным пивасом ;) да и без вебинара могу )))))
Напиши плз мне в вк ) есть интересное предложение. Насчёт того с чего начать - я, наверное, выпущу отдельный ролик на эту тему, так как очень много запросов на тему с чего начать
13:58 Вот, кстати тоже часто путаница в понятиях связанность и зацепление. Все-таки, сильная связанность - это хорошо, плохо - сильное зацепление. Не так ли?))
Хм, а как вы видите разницу между понятиями связанность и зацепление? Просто я про зацепление слышал один раз, но в целом везде употребляется связность, даже в той самой книге про архитектуру.
@@MobileDeveloper www.geeksforgeeks.org/software-engineering-coupling-and-cohesion/ Wiki переводит их как: ru.m.wikipedia.org/wiki/%D0%A1%D0%B2%D1%8F%D0%B7%D0%BD%D0%BE%D1%81%D1%82%D1%8C_(%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5) и ru.m.wikipedia.org/wiki/%D0%97%D0%B0%D1%86%D0%B5%D0%BF%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5_(%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5)
Основная причина потому что даггер меня всем устраивает. А так я посмотрел Кодеин работает в рантайме и можно runtime exception словить - это не очень надежно, а даггер позволяет все отловить на стадии компиляции.
16:50 Эти студии-галеры с текучкой кадров и отвратительным качеством кода могут делать только одноразовые мелкие проекты? И давать им большие или средние проекты с большей стоимостью нельзя? За счет чего они живут если так отвратительно работают?
25:07 у вас все адаптеры лежат в папке adapters и к сущности (классу) дописывается просто слово Adapter. А если это будет не для ресайклера адаптер, а для ViewPager, например?
@@MobileDeveloper а как вы по названию определяете какой из них вьюпейджер? Они все Adapter называются. И отсюда неаонятно какой из них ресайклер, а какой вьюпейджер
Я предпочитаю использовать mvp, пробовал mvvp, но он мне показался слишком сложным из-за кодогенерации, как-бы даррег второй, этот mvvp. А вот на счёт циклов, я некогда не использовал их в других потоках, но вы сказали их лучше использовать в другом потоке? А ещё, почему так ArrayList плох?
Не совсем понял, а mvvp - это что? Или вы имели ввиду MVVM? Ну если цикл очень ресурсоемкий (а редко бывает иначе), то конечно его не надо крутить в главном потоке )) Сильный телефон это переварит, а вот слабый нет. Я не говорил что ArrayList - плох ) Я говорю, что по максимуму надо не конкретизировать левую часть присваивания, чтобы пользоваться такой чудесной штукой как полиморфизм
Ну если вы в функцию передаёте аргумент ArrayList вы не сможете воспользоваться этой функцией если у вас LinkedList или своя реализация. А если у вас List то пожалуйста - передавайте какую хотите. То есть по возможности нужно абстрагироваться от реализации. Но тоже главное без фанатизма
17:47 все-равно архитектура окажется неподходящей на будущие требования, все что угодно сделай, все равно будет убогое неуклюжее. Надо вытащить наган из кармана и застрелить лошадь на месте где упала. Рефакторить новую ровно на текущие задачи чтобы хватило, и жить спокойно. Требования поменяются поменяем архитектуру. И таким образом будет наслаиваться и "калиться" настоящая структура и форма проекта расчитанная для поля боя
Тут я вижу не двойственную картину мира, а некий range. Вполне можно предвидеть тот факт, что формы станут сложнее, запросов будет все больше и тд и тп) иначе архитектур бы не существовало. Но) предвидеть переход с реста на сокеты довольно тяжело и непонятно зачем, поэтому делать абстракцию над сетевым слоем с этой целью уже не очень попятно зачем. Поэтому я бы сказал рефакторить нужно ровно столько сколько надо плюс примерно на год другой вперёд )
12:15 по идее - нет, но все же будет - да. Наверное, потребуется добавить новое свойство в пользователе, которого небыло изначально, типа telegram-id и весь pipline на всех семидесяти семи слоях нужно будет рефакторить. Это же модно, попробуй сказать весь ваш солид гавно, тебя обвинят в гомофобии, расизме, алкоголизме, непрофессионализме, неполиткорректности и т. д. и попытаются избавиться
Хахах )) да, кстати, если оно будет добавлено на сервере это нужно будет прокинуть до верхнего слоя, однако! Мы не раз сталкивались с тем, что нам удавалось решать проблему замкнувшись внутри одного слоя абстракции, например, когда поле служебное и не нужно для отображения. Так что смысл в этом есть, главное, как и везде, без фанатизма. А насчёт солида, опять же сами принципы говном быть не могут ) а вот применить их хреново можно и ещё как ))
@@MobileDeveloper безусловно solid правильный принцип для проектирования отдельно взятых сущностей и их локальных связей. Однако эти принципы слишком примитивны, чтобы описать природу взаимодействий между целыми слоями архитектуры. Именно из-за попытки применить mvvm, mvp, mvc буквально возникает ужасы. Раньше все строили архитектуру, которая больше отвечает этим принципам, чем сейчас когда принципы объявили новой религией и воздвигли им церковь. Столько пустой работы и разговопов, столько гордыни, все посходили с ума. У безталантливых программистов появилось оружие БИБЛИЯ. Теперь нельзя ссылаться на простой здравый смысл и целесообразность. Инквиторы, чертовы, тебе прочитают очередную аббревиатуру из книги. Год писал на vue, node, graphql. Одно удовольствие. Вот опять возвращаюсь к проклятому Android, наполненному пафосом и идиотизмом. Привет орда узколобых фанатиков! Хехей! Я снова дома
@@MobileDeveloper Ну от этого есть польза, только уже многие на практике пришли к выводу, что на старте проекта когда над ним работает одна команда - хорошо спроектированный монолит выгодней. Микросервисы же это скорее дальнейший(возможный) этап развития монолита, нежели его прямая альтернатива. Иногда же люди гонятся за модой и стартуют сразу с микросервисом, т.к. "монолит - зло". Почему-то у некоторых монолитная архитектура ассоциируется с "водопадом", хотя она и в agile подходе нормально живет :)
![UI/UX - RecyclerView. Проектируем списки. [RU, Android] / Мобильный разработчик](http://i.ytimg.com/vi/NuoawfuKw30/mqdefault.jpg)
![UI/UX - RecyclerView. Проектируем списки. [RU, Android] / Мобильный разработчик](/img/tr.png)
![Многопоточность. Часть 4. Корутины [RU, Android] / Мобильный разработчик](http://i.ytimg.com/vi/jZ8LeeGQw1k/mqdefault.jpg)
![Архитектура. MVI [RU] / Мобильный разработчик](http://i.ytimg.com/vi/IRCv3mkc6jY/mqdefault.jpg)
![Паттерны проектирования. Наблюдатель [RU, Android] / Мобильный разработчик](/img/1.gif)
Словами не передать, насколько качественный и нужный контент на канале. Спасибо тебе большое.
Спасибо большое, рад что понравилось! )
Тайм-коды по расшифровке аббревиатуры:
3:05 S - Single Responsobility
4:17 O - Open-Closed Principle
5:48 L - Liskov Substitution Principle
8:28 I - Interface Segregation Principle
10:11 D - Dependency Inversion Principle
По поводу удорожания разработки согласен на все 100: на работе постоянно говорили, что надо быстро и тд, но зато потом: Макс, добавь сюда это, туда то и туда то, естественно добавление всего нового функционала быстро и безболезненно, и все довольны)
Да, я тоже такой тактики придерживаюсь. Лучше потратить доп. время на архитектуру, чем потом страдать в постоянном продакшне)
32:40 есть небольшое замечание: скрывайте пожалуйста эту менюшку снизу, закрывает много кода.
Окей, со временем возьму нормальный монитор и увеличу разрешение )
супер, все с примерами, "а теперь представим, что пришел менеджер и сказал ..." - так гораздо более понятен profit от хорошей архитектуры,
примеры того, как не надо делать, тоже в тему, было бы здорово отдельно посмотреть про типичные анти-паттерны (GodClass уже был в видео, магические числа тоже, хочется еще)
спасибо!
Спасибо! ) Да это будет в будущих видео по этой теме.
Никогда никому на ютубе ни на кого не подписывался и уж тем более не стваил "колокольчик". Тут Алексей может даже не просить об этом. Видео просто супер. Возможно не совсем для новичков, но подход и подача просто вышка! Готовлюсь к собеседованиям на джуна - Алексей очень помогает раскидать всё по полочкам. Почему бесплатно? (это не по русски и непривычно! ахаха)
Спасибо большое ) бесплатно просто так, потому что хочу развития технологий у нас в стране. Но есть и платный контент он лежит на патреоне.
"Ссылка на активити - это вообще жопа"
Заржал в голос :D
)))
Как тогда получить доступ к UI элементам из другого класса?
В смысле? Можно конкретнее?)
@@MobileDeveloper Я имею в виду, например, в неком классе мне нужно получить текст с EditText и произвести с ним некие манипуляции. Как это сделать без activity context?
А зачем вам тут контекст? У текстфилда есть text поле берёте его и кидаете в ваш класс
От адаптера 1200 строк чуть сердечко не ёкнуло..
Хех, ну сейчас у меня такого нет уже ) Хотя там была очень очень сложная задача ) (это так немного в оправдание)
@@MobileDeveloper а вы не используете библиотеки для adapter типа BRVAH? Он мне кажется самым простым и удобным.
@@segreiulanov6057 нет стараюсь не тащить в проект библиотеки, если можно обойтись без них )
1:13 S - Single Responsibility же
Блин )) действительно ) оговорился, видимо в голове крутилось object oriented ))
Лучшее что есть на русском ютубе по данной теме, жду следующих видео! Автору успехов!
Спасибо большое ) сейчас вернусь из отпуска и начну новый сезон так сказать )
Mobile Developer, меня взяли стажером!) во многом благодаря этим видео!
Это очень круто )) значит не зря я их делаю )
Познавательно! Было бы здорово увидеть серию уроков с реализацией какого нибудь приложения с нуля... например интернет магазин или вроде того...
Вроде делали вк ) но я вижу интерес не угасает ) окей подумаю об этом )
Mobile Developer да я его видел. Я имел ввиду серию обучающих видео, где было бы максимальное приближение к реальным проектам... с объяснением всех этапов разработки от и до... у вас хорошие уроки, плюс такой серии уроков в том, что бы вы на практике показывали где и как юзать разные инструменты. Пиши с телефона, что не очень удобно! Надеюсь я смог до вас донести основную идею.
Понял да идею )) подумаю ) в моих планах это делать на стримах и вебинарах
У каждого бывает, смотришь старые коды и думаешь- что это вообще такое...
Хорошее видео, наверное архитектура- одно из самых важных на начальном этапе
Тестировать нужно на старом устройстве
Согласен))) Постоянно такое у себя вижу)
@@MobileDeveloper miro.medium.com/max/1400/1*NT1um6PYhJU4q9E26cQUew.png
@@romankryvolapov хахах) да моя любимая шутка :))
@@MobileDeveloper это отсюда medium.com/mindorks/understanding-clean-code-in-android-ebe42ad89a99
Самый удобный для понимания пример по принципу L - это класс квадрата наследующийся от класса прямоугольника и замещающий реализацию сеттеров Width и Height так, чтобы при изменении Height, Width автоматически заменяется на то-же значение и наоборот. Для будущего пользователя будет сюрпризом такое поведение объекта приведенного к общему типу Rectangle. Для себя тогда сделал вывод, что в данном конкретном примере вообще не требуется такой класс как Square, т.к. это частный случай Rectangle. Поправьте, если я ошибаюсь в правильности способа как разруливать такую ситуацию.
В целом, принцип L по сути говорит нам о том, что при подстановке классов в переопределениях методах не должно быть какого-то поведения, которого ты не ожидаешь, поэтому если вы переопределяете метод setHeight и делает там ещё и setWidth это нарушение да, хотя особых проблем это вам не даст в этом случае, разве что лишние операции проверки при приведении к типу так как квадрат частный случай прямоугольника. А вот если вы просто сделаете новый метод у квадрата который сразу будет сетать сторону то с точки зрения архитектуры все норм )
Спасибо! Давно ждал. Понравились ваши примеры из реальных проектов. Почти нет лозунгов, которые очень отталкивают, когда смотришь чужие презентации, статьи про архитектуру. Обычно приводят какие-то преимущества, которые скорее недостатки. В этом смысле вы аккуратны, не пропагандируете подходы, а лишь говорите, что с ними может быть лучше. Вообще все эти методологии помогают при определённых условиях. Раньше использовал Clean, MVP, сейчас вернулся на MVC и особо не жалею. Будем ждать новых серий.
Спасибо большое! ) Да мне вот это вот все на VIPER тоже не очень нравится) потом смотришь на проект где два вьюконтроллера зато все на вайпер написано. Согласен, условия должны быть подходящими
@@MobileDeveloper Да, я с вами полностью согласен! Забыл написать, что в случае с ArrayList не всё так однозначно. Я раньше тоже везде передавал List, но в последнее время также стал и ArrayList, MutableList (для адаптеров и операции addAll). Дело в том, что метод putParcelableArrayList требует исключительно ArrayList. Но я с вами согласен, если это возможно, лучше передавать родительский класс или интерфейс.
Alexander Nifanin тоже столкнулся с этой проблемой в parcelable )не знаю зачем они так сделали ) у меня есть отдельная функция которая берет на вход лист в любом формате и parcelable плюс ключ и возвращает parcel с уже вложенным массивом ) пришлось так сделать специально для этого случая
@@MobileDeveloper Интересный способ. А вы лист преобразуете в массив?
@@alexandernifanin7366 неправильно выразился) я лист привожу к ArrayList )
ооо, самое интересное начинается, усаживаемся поудобнее :)
Хаха, рад что зашло )
17:50 Как эти менеджеры работают если не понимают предметную область? Или это больше безответственность?
Ну других то нет ))
Расскажете про Интекрактор и Репозиторий? Очень запутанные сущности и все их понимают по-разному. Взять 100 проектов и везде связка Вью, Презентер, Интерактор, Репозиторий реализован по-разному. Очень хотелось бы посмотреть как это правильно сделать. Слышал, что Репозиторий надо инжектить, у него не должно быть ссылок на Презентер. Еще Презентер ведь просто посредник между вью и модел, но нет, кто-то там умудряется что-то обрабатывать. Вообщем куча вопросов. Ждем видео :)
Про это подробнее буду рассказывать в чистой архитектуре.
Спасибо! Очень интересно! Жду новых выпусков про Архитектуру
А что еще можно рассказать?
@@MobileDeveloper Если честно хотелось бы больше примеро
в SOLID ичистой архитектуры в Андроид SOLID
Хм, да возможно стоит сделать отдельный выпуск про чистую архитектуру
@@MobileDeveloper спасибо :)
Специально даже запуллил с репозитория рабочий проект и поменял одно очень часто используемое int свойство на String, но в контексте моего проекта это сработает, так как неинтовых значений не будет))
Ну да, а попробуйте поменять String на Enum
10:55 в теории - нет, на практике - обязательно. Ребрендинг должен затрагивать только стили, по идее, но в реальности оно затронет все, включая бэкенд, и провайдеров oAuth.
Solid - хорош для промышленного софта, где код работает десятилетиями, но не для приложений бизнес уровня, где требования меняются каждый месяц
Мы спокойно провели небольшой ребрендинг, затронув, только дизайн систему фактически. Так что есть вещи, которые не меняются годами и в бизнес приложениях )
Вы полностью на kotlin перешли ? Или на java все же есть проекты
Нет, я давно уже на котлине только
Из int в String: самое первое, что пришло в голову, это в геттере возвращать Integer.parseInt(), но встаёт проблема, что делать, если в параметре будет "unknown", возвращать какое-то другое значение, потом проверять, ну это уже костыль)
Тут, имхо, только конвертеры между слоями помогут.
@@MobileDeveloper Чем плохо оставить int? Unknown - это ui-интерпретация нуля. Работы по-минимуму, все решается легкой модификацией ui-слоя.
В БД так собственно и принято - если id=0 то insert, если >0 - то update. И нормально все себя чувствуют.
Я уже плохо помню контекст, но там смысл был в другом )
14:50 У моего друга на работе в продуктовой компании эффективный менеджер так и поступил. Был отдел отвечавший за мобильное приложение. Чтобы сэкономить отдали мобильную часть на аутсорс. Как быстро это скажется на качестве продукта? Поймет ли менеджер что совершил ошибку? Или экономия с точки зрения менеджера будет предпочтительнее чем потеря качества? Может менеджмент посчитал что приложение полностью готово и дальнейшие изменения будут требоваться очень редко и для этого не надо содержать своих мобильных разрабов? Почему в этой ситуации просто не провели сокращение в мобильном отделе? Зачем уничтожать отдел теряя контроль над разработчиками? С деньгами в компании все очень хорошо, просто нужно было сэкономить и тем самым повысить прибыль.
Менеджеру нужно было выполнять свои KPI и он их выполнил. Вообще выстраивание эффективной модели в компании это тема отдельных научных работ) Потому что любую систему будут пытаться взломать)
Годноту подвезли
Спасибо! ))
Я ржал с "тут нажали и тут же обработаем"))))
хорошо! но для совсем младенцев, может посоветуешь что-то почитать об архитектуре?
Или покажешь простенький пример, как проектировать приложение, так сказать от идеи до кода )
а то сейчас смотрю свои аппы, а они похожи на то, где в адаптере 1200 строк )))))
По архитектуре нельзя прочитать что-то одно и просветлиться) Нужно брать паттерны (они всем известны) читать, пробовать, читать, пробовать и так далее. В будущем будет да вебинар, где я буду делать нечто подобное
@@MobileDeveloper "они всем известны" вот не всем ))))
Если я буду говорить о себе, то в "высокое" программирование я погрузился где то с полгода назад, до этого 15 лет занимался программированием контроллеров, там несколько другая песня, а точнее больше плясок с бубнами )))
Тем не менее, читаю, изучаю... хорошо, что есть стековерфлоу и гитхаб))) но чем больше изучаю, тем сильнее понимаю, что я ничерта не знаю ((( тем не менее за полгода успешно зарелизил 3 приложения а сторе, первое время, только и занимался, что изучал стектрейс в крашлитикс ))
Хочется плавать глубже, но как это сделать, если толком на поверхности плавать не умеешь... алгоритмы, структуры данных - это не проблема, проблема в том, что хочется делать красиво и быстро, как взрослые бородатые дяди )) буду благодарен, если получу пинка в направлении "что такое" паттерны и где их брать )))
Взамен на вебинар могу что-то полезное сделать для канала, а если будешь в Томске, то могу угостить самодельным пивасом ;) да и без вебинара могу )))))
Напиши плз мне в вк ) есть интересное предложение. Насчёт того с чего начать - я, наверное, выпущу отдельный ролик на эту тему, так как очень много запросов на тему с чего начать
@@MobileDeveloper окей, написал
13:58 Вот, кстати тоже часто путаница в понятиях связанность и зацепление. Все-таки, сильная связанность - это хорошо, плохо - сильное зацепление. Не так ли?))
Хм, а как вы видите разницу между понятиями связанность и зацепление? Просто я про зацепление слышал один раз, но в целом везде употребляется связность, даже в той самой книге про архитектуру.
@@MobileDeveloper www.geeksforgeeks.org/software-engineering-coupling-and-cohesion/
Wiki переводит их как:
ru.m.wikipedia.org/wiki/%D0%A1%D0%B2%D1%8F%D0%B7%D0%BD%D0%BE%D1%81%D1%82%D1%8C_(%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5)
и
ru.m.wikipedia.org/wiki/%D0%97%D0%B0%D1%86%D0%B5%D0%BF%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5_(%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5)
👍 👍 👍 👍 👍
Спасибо ))
почему ты юзаешь дагер с котлином , а не Kodein?
Основная причина потому что даггер меня всем устраивает. А так я посмотрел Кодеин работает в рантайме и можно runtime exception словить - это не очень надежно, а даггер позволяет все отловить на стадии компиляции.
16:50 Эти студии-галеры с текучкой кадров и отвратительным качеством кода могут делать только одноразовые мелкие проекты? И давать им большие или средние проекты с большей стоимостью нельзя? За счет чего они живут если так отвратительно работают?
Нет, они часто делают долгие проекты и очень большие. А держится это все на повальной не компетентности принимающей стороны
Зависимости: привет MV* паттерны: ui и навигация от бизнес-логики, работающей с бд и сервером)
Я не понял, это плохо?)
Спасибо, отличное объяснение
Рад, что получилось объяснить )
Спасибо тебе автор за то что ты это делаешь
Рад помочь ))
25:07 у вас все адаптеры лежат в папке adapters и к сущности (классу) дописывается просто слово Adapter. А если это будет не для ресайклера адаптер, а для ViewPager, например?
Там все адаптеры лежат и для VP тоже
@@MobileDeveloper а как вы по названию определяете какой из них вьюпейджер? Они все Adapter называются. И отсюда неаонятно какой из них ресайклер, а какой вьюпейджер
Я их называю PagerAdapter
Какие Open Source проекты ты советуешь поизучать,?
Android Architecture examples
github.com/android/architecture-samples
Я предпочитаю использовать mvp, пробовал mvvp, но он мне показался слишком сложным из-за кодогенерации, как-бы даррег второй, этот mvvp. А вот на счёт циклов, я некогда не использовал их в других потоках, но вы сказали их лучше использовать в другом потоке? А ещё, почему так ArrayList плох?
Не совсем понял, а mvvp - это что? Или вы имели ввиду MVVM? Ну если цикл очень ресурсоемкий (а редко бывает иначе), то конечно его не надо крутить в главном потоке )) Сильный телефон это переварит, а вот слабый нет. Я не говорил что ArrayList - плох ) Я говорю, что по максимуму надо не конкретизировать левую часть присваивания, чтобы пользоваться такой чудесной штукой как полиморфизм
@@MobileDeveloper да, я про mvvm) А как именно конкретизировать? Чёт не очень понял.
Ну если вы в функцию передаёте аргумент ArrayList вы не сможете воспользоваться этой функцией если у вас LinkedList или своя реализация. А если у вас List то пожалуйста - передавайте какую хотите. То есть по возможности нужно абстрагироваться от реализации. Но тоже главное без фанатизма
@@MobileDeveloper интересная мысль, не сталкивался, но уже хочу проверить)) Спасибо
Всегда пожалуйста )
16:31 не butterknife ли выпиливали?))
Нет я им не пользуюсь, это databinding
Ну, если под "быстренько накидать" предполагается захардкодить чуть ли не все приложение, то ответ очевиден - расширяемость системы)
Это где?)
Я Джуниор. Когда я вижу ТАКИЕ проекты я психологически умираю. Дайте успокоительное.. пожалуйста...
MVP\MVVM очень жду потмоу что пользуюсь и хочу увидеть что где не так
Дойду и до этого )
ждем!
17:47 все-равно архитектура окажется неподходящей на будущие требования, все что угодно сделай, все равно будет убогое неуклюжее.
Надо вытащить наган из кармана и застрелить лошадь на месте где упала. Рефакторить новую ровно на текущие задачи чтобы хватило, и жить спокойно. Требования поменяются поменяем архитектуру. И таким образом будет наслаиваться и "калиться" настоящая структура и форма проекта расчитанная для поля боя
Тут я вижу не двойственную картину мира, а некий range. Вполне можно предвидеть тот факт, что формы станут сложнее, запросов будет все больше и тд и тп) иначе архитектур бы не существовало. Но) предвидеть переход с реста на сокеты довольно тяжело и непонятно зачем, поэтому делать абстракцию над сетевым слоем с этой целью уже не очень попятно зачем. Поэтому я бы сказал рефакторить нужно ровно столько сколько надо плюс примерно на год другой вперёд )
12:15 по идее - нет, но все же будет - да. Наверное, потребуется добавить новое свойство в пользователе, которого небыло изначально, типа telegram-id и весь pipline на всех семидесяти семи слоях нужно будет рефакторить. Это же модно, попробуй сказать весь ваш солид гавно, тебя обвинят в гомофобии, расизме, алкоголизме, непрофессионализме, неполиткорректности и т. д. и попытаются избавиться
Хахах )) да, кстати, если оно будет добавлено на сервере это нужно будет прокинуть до верхнего слоя, однако! Мы не раз сталкивались с тем, что нам удавалось решать проблему замкнувшись внутри одного слоя абстракции, например, когда поле служебное и не нужно для отображения. Так что смысл в этом есть, главное, как и везде, без фанатизма. А насчёт солида, опять же сами принципы говном быть не могут ) а вот применить их хреново можно и ещё как ))
@@MobileDeveloper безусловно solid правильный принцип для проектирования отдельно взятых сущностей и их локальных связей. Однако эти принципы слишком примитивны, чтобы описать природу взаимодействий между целыми слоями архитектуры.
Именно из-за попытки применить mvvm, mvp, mvc буквально возникает ужасы.
Раньше все строили архитектуру, которая больше отвечает этим принципам, чем сейчас когда принципы объявили новой религией и воздвигли им церковь.
Столько пустой работы и разговопов, столько гордыни, все посходили с ума.
У безталантливых программистов появилось оружие БИБЛИЯ. Теперь нельзя ссылаться на простой здравый смысл и целесообразность. Инквиторы, чертовы, тебе прочитают очередную аббревиатуру из книги.
Год писал на vue, node, graphql. Одно удовольствие. Вот опять возвращаюсь к проклятому Android, наполненному пафосом и идиотизмом. Привет орда узколобых фанатиков! Хехей! Я снова дома
а если человек забудет отсканировать время?)
А можете таймметку дать?)
28:30 :))
Бурная молодость )
14:20 Плохая система монолитна - зачастую да. Но не надо автоматом применять это правило в обратную сторону, не каждый монолит - плохая архитектура.
Согласен) Насмотрелся на микросервисную архитектуру на разных проектах, тоже есть большие сомнения, что это прям так здорово )
@@MobileDeveloper Ну от этого есть польза, только уже многие на практике пришли к выводу, что на старте проекта когда над ним работает одна команда - хорошо спроектированный монолит выгодней. Микросервисы же это скорее дальнейший(возможный) этап развития монолита, нежели его прямая альтернатива. Иногда же люди гонятся за модой и стартуют сразу с микросервисом, т.к. "монолит - зло". Почему-то у некоторых монолитная архитектура ассоциируется с "водопадом", хотя она и в agile подходе нормально живет :)
Это как говорить что молоток плохой. Молоток это инструмент. А уж как его использовать задача мастера