А зачем убеждать? Идём к манагеру: у нас по дизайну тени такие, из коробки - вот такие. Из коробки - можем зарелизить прямо сейчас.По дизайну - непредсказуемо, нужно ресёрчить. Что делать? В 99% случаев будем посланы сразу же релизить.
Есть, конечно, приложения с уникальными требованиями к дизайну, но это, всё-таки, скорее исключение, чем правило.
В любом случае, реально круто, что кто-то - как автор статьи - находит и мужество и время поразбираться с такими вопросами.
Ну, на каких-то вещах такое может и работать. Но это должны быть очень простые фичи.
Но я реально не вижу, как можно в короткий спринт уложить и анализ, и формулирование требований, и разработку дизайна, и подготовку бэка, и разработку на мобилках, и регресс. Вот не верю.
Это называется "Натягивать сову на глобус", если честно. Выкатывать обрезанный функционал только ради того, чтобы "уложиться в спринт" - прямо такое себе. Ловить баги, минусы в маркете ради всего этого - не, спасибо.
Ценность одна: удобство пользователя при решении его задачи.
Всё это хорошо до тех пор, пока ценность фичи для клиента не возникает только по факту её полной готовности. Если мы в первом релизе выкатим "Отксанировать QR-код для оплаты через СБП", а саму оплату выкатим только во втором релизе - это прям спорно будет.
И таких фич, которые тупо не ложатся в две недели - очень много.
Вот для меня всегда было загадкой, как можно что-нибудь большое запихать в двухнедельный спринт - не жертвуя качеством. С учётом того, что по частям это в принципе невозможно выкатывать - ни с точки зрения смысла, ни с точки зрения функционала. Как-то был подобный опыт участия - ощущаешь себя каким-то персонажем из Дилберта.
Воистину всё так. Занимаемся разработкой мобильного приложения для одного из банков — заказчиков тема планшетов вообще не задевает. Не скажу точно по актуальной статистике, но с планшетов заходит очень мало людей.
И париться под спец. раскладку (слева один фрагмент, справа другой) — никто не видит смысла. С учётом того, что тогда нужно делать и специальный дизайн под альбомный вариант… За это время успеем несколько новых фич запилить.
Не, разумеется, если в команде разработки сидит 50 с лишним человек, которым нечем заняться — да, можно кого-то этим озадачить. Но это прям явно перебор какой-то, примерно так на порядок.
Да это как-то совсем за гранью добра и зла… Типичное приложение мобильного банка, и такая прорва людей… У них больше времени, вангую, уходит на согласования и проч, чем собвственно на проектирование и разработку.
Если честно, не очень понимаю, в чём вообще смысл — почему андроид-девелоперы должны страдать из-за чужих косяков? Тут с существующим стеком ппц боли хватает, но нет, боли надо добавить.
Через год Хуавей автообновит свои девайсы, заменив Android на HarmonyOS (как это сделал Самсунг со своими часами, заменив ОС на Tizen) — и внезапно окажется, что вся эта боль была зря…
Имхо тут всё проще. Смотрим на картинку от гугла и спрашиваем: ок, чуваки, а где тут будет жить бизнес-логика? И сразу видим, что места для неё и не предусмотрено:
— размещать логику в Presenter/ViewModel — так себе вариант, хотя бы потому, что нет возможности её повторно использовать из других мест
— размещать логику в репозитории (то есть, по факту, в CRUD-механизме) ещё смешнее.
А так как логика всё-таки обычно нужна, то и сразу становится видна необходимость дополнительного слоя. В clean это use cases/interactors, в ribots (https://bit.ly/3iBclap) — это Data Managers, один-в-один, как тот, что сверху. В разных архитектурах такой слой всегда явно выделяется, и не важно, как он там называется.
Спасибо, приятно читать такие статьи, особенно имея УЭХК в качестве предыдущего места работы. По хорошему, что-то подобное должен был бы и Росатом подготовить, но у них это не принято, увы.
> Главная проблема — эта архитектура пришла к нам из мира iOS (из раздела про Viper)
Вот тут я тоже не понял — я не знаю особенности реализации Viper на iOS, но картинка один-в-один из Clean Architecture. Очень многие успешно затягивают clean arch в андроид-проекты, не очень понял, в чём тут проблема.
Вот хз. Смотрю на код CleanArch, MVVM или MVP — сразу вижу общую картинку. Назначение, состав и принцип работы.
Если понадобится кросс-платформенность — вон классный Flutter под рукой есть.
А тут смотрю на кусок кода — и реально не вижу, что это и зачем.
На досуге как-то посмотрел флаттер (основное занятие у меня — это android и kotlin) — так вот весьма понравилось мне. По тьюториалам, конечно, сложно судить, но то, что я видел и пробовал, очень неплохо. Понравилось, как работают с состояниями и как изменения в состояниях рендерится на UI.
Длинный код (всё описание view в коде) с непривычки — да, необычно. Можно нагородить нечитаемых вещей. Но, как я понимаю, в Compose будет примерно так же.
По поводу сохранности паспортных и прочих данных я бы, в первую очередь, переживал бы на тему наших операторов. Достаточно много слышали про проблемы с банками в последнее время — ещё интереснее подумать о количестве утечек, про которые публично не сообщалось.
Самая жесть будет с относительно небольшими или со специализированными сайтами/магазинами.
Те же CaptureOne или DxO, у которых я софт для обработки фотографий покупаю, Sparx, у которого Enterpise Architect покупаю — они станут морочиться ради 56 пользователей из России? Вот точно не станут…
Хм, то есть захожу я в PayPal и вижу: в связи с невозможностью хранения ваших данных на территории РФ мы удалили ваш аккаунт?
Иду поплакаться в Твиттер и вижу там то же самое?
Зачем так сложно? Сошлются на том, что при заключении договора кредита на 950 тысяч рублей сроком на два 2 месяца были использованы ваши биометрические данные: система подтвердила, что это были вы, возражения не принимаются.
А зачем убеждать?
Идём к манагеру: у нас по дизайну тени такие, из коробки - вот такие. Из коробки - можем зарелизить прямо сейчас.По дизайну - непредсказуемо, нужно ресёрчить. Что делать?
В 99% случаев будем посланы сразу же релизить.
Есть, конечно, приложения с уникальными требованиями к дизайну, но это, всё-таки, скорее исключение, чем правило.
В любом случае, реально круто, что кто-то - как автор статьи - находит и мужество и время поразбираться с такими вопросами.
Ну, на каких-то вещах такое может и работать. Но это должны быть очень простые фичи.
Но я реально не вижу, как можно в короткий спринт уложить и анализ, и формулирование требований, и разработку дизайна, и подготовку бэка, и разработку на мобилках, и регресс. Вот не верю.
Это как выкатить на рынок Теслу, которая не умеет тормозить, а поворачивать умеет только направо.
"Выжившие клиенты бесплатно получат новую версию!"
Это называется "Натягивать сову на глобус", если честно.
Выкатывать обрезанный функционал только ради того, чтобы "уложиться в спринт" - прямо такое себе. Ловить баги, минусы в маркете ради всего этого - не, спасибо.
Ценность одна: удобство пользователя при решении его задачи.
Всё это хорошо до тех пор, пока ценность фичи для клиента не возникает только по факту её полной готовности. Если мы в первом релизе выкатим "Отксанировать QR-код для оплаты через СБП", а саму оплату выкатим только во втором релизе - это прям спорно будет.
И таких фич, которые тупо не ложатся в две недели - очень много.
Вот для меня всегда было загадкой, как можно что-нибудь большое запихать в двухнедельный спринт - не жертвуя качеством. С учётом того, что по частям это в принципе невозможно выкатывать - ни с точки зрения смысла, ни с точки зрения функционала.
Как-то был подобный опыт участия - ощущаешь себя каким-то персонажем из Дилберта.
Спасибо, очень полезно.
И париться под спец. раскладку (слева один фрагмент, справа другой) — никто не видит смысла. С учётом того, что тогда нужно делать и специальный дизайн под альбомный вариант… За это время успеем несколько новых фич запилить.
Не, разумеется, если в команде разработки сидит 50 с лишним человек, которым нечем заняться — да, можно кого-то этим озадачить. Но это прям явно перебор какой-то, примерно так на порядок.
Через год Хуавей автообновит свои девайсы, заменив Android на HarmonyOS (как это сделал Самсунг со своими часами, заменив ОС на Tizen) — и внезапно окажется, что вся эта боль была зря…
— размещать логику в Presenter/ViewModel — так себе вариант, хотя бы потому, что нет возможности её повторно использовать из других мест
— размещать логику в репозитории (то есть, по факту, в CRUD-механизме) ещё смешнее.
А так как логика всё-таки обычно нужна, то и сразу становится видна необходимость дополнительного слоя. В clean это use cases/interactors, в ribots (https://bit.ly/3iBclap) — это Data Managers, один-в-один, как тот, что сверху. В разных архитектурах такой слой всегда явно выделяется, и не важно, как он там называется.
Вот тут я тоже не понял — я не знаю особенности реализации Viper на iOS, но картинка один-в-один из Clean Architecture. Очень многие успешно затягивают clean arch в андроид-проекты, не очень понял, в чём тут проблема.
Если понадобится кросс-платформенность — вон классный Flutter под рукой есть.
А тут смотрю на кусок кода — и реально не вижу, что это и зачем.
Длинный код (всё описание view в коде) с непривычки — да, необычно. Можно нагородить нечитаемых вещей. Но, как я понимаю, в Compose будет примерно так же.
Те же CaptureOne или DxO, у которых я софт для обработки фотографий покупаю, Sparx, у которого Enterpise Architect покупаю — они станут морочиться ради 56 пользователей из России? Вот точно не станут…
Иду поплакаться в Твиттер и вижу там то же самое?