Цифровое образование

Академия Яндекса: Дзен-Мобайл: Можно ли выжить без MVP/MVVM/MVI? - видео HD

Академия Яндекса: Дзен-Мобайл: Можно ли выжить без MVP/MVVM/MVI? - видео
02:08:06
Лекции из курсов различных школ Яндекса, записи мастер-классов, семинаров и докладов на мероприятиях — для специалистов IT-отрасли, студентов технических вузов и даже школьников.

Дзен-Мобайл: Можно ли выжить без MVP/MVVM/MVI? - видео.

Вопросы спикерам сюда → t.me/zenmobileВечером 18 сентября пятеро Android-разработчиков будут спорить о том, можно ли выжить без паттернов MVP/MVVM/MVI (MVx), делиться опытом и отвечать на ваши вопросы. Чем закончится дискуссия, неизвестно, но результат во многом будет зависеть от зрительских вопросов.В эфире: Дмитрий Губа из Яндекс.Дзена, Александр Блинов из Headhunter, Евгений Мацюк из Лаборатории Касперского и Алексей Быков из Revolut. Модерирует встречу Егор Курников.Начало с 10:00
RSS
Разработка
00:45
+4
Начало с 10:00
Антон Антонов
11:15
+5
Очень православно
lyushiks
13:56
+5
Православно!
Andrew Romanyuk
19:34
+1
Очень круто, спасибо.
Pavel Belovol
23:01
+1
Классно
Alexander Nifanin
10:01
+3
Спасибо за интересную встречу! Одна из самых интересных по архитектуре на Youtube.
Самые интересные вопросы задал ведущий, он и должен получить три приза.
Наконец, сказали, что юнит-тестирование не нужно в презентере. Этого я ждал года три.) Более бесполезной, непродуктивной, бессмыссленной траты времени сложно поискать. Даже в интеракторах писать их особо не нужно. А писать нужно в сложных случаях, где программист может ошибиться. Не там, где конвертируется список из одной формы в другую, а там, где есть распознавание строк (RegEx), какие-то сложные операторы RxJava. По сути, юнит-тесты не нужны совсем (только мешают при рефакторинге), либо нужны только в очень небольшом количестве случаев.
На мой взгляд, без архитектуры жить вполне можно, особенно на небольших проектах или в маленьких командах (из одного-двух человек). Смысл архитектуры в Андроиде — борьба с жизненным циклом. Если бы не это, даже и архитектура была бы не нужна, достаточно простого ООП. Архитектура — набор ограничений.
Рад, что Александр Блинов подметил насчёт SOLID, что это далеко не главный паттерн. Он применим только к ООП и вообще надуман. Сборник взаимосвязанных принципов из пяти случайных букв, чтобы получился SOLID, как в кроссворде. Даже порядок важности принципов нарушен. ООП вполне существует без SOLID, который сильно ограничивает и мешает. Если вы не проектируете библиотеку, по сути, SOLID не нужен. Чем больше абстракций (классов, интерфейсов), тем сложнее писать код. Сами абстракции мешают отладке, пониманию кода, могут служить проблемой при реализации жизненного цикла (что-то стартует слишком поздно, что-то сложно подстроить под данную ситуацию). В будущем, я надеюсь, от него отойдут.
schtscherbakow
18:46
+1
побольше бы таких стримов! офигенно!
Загрузка...