«Давайте уволим половину разработчиков»: кроссплатформенная мобильная разработка в 2019 году
«Давайте уволим половину разработчиков»: кроссплатформенная мобильная разработка в 2019 году
4040

// Подождите, мы оказывались недовольны, если из двух кодовых баз получалось три, а нам предлагают сразу же именно так и сделать. В чём тогда смысл вообще?

Идея-то была в том, что из двух кодовых баз предполагается выделить общую абстрактную часть, не зависящую от конкретной платформы. Если действительно следовать принципам "чистой архитектуры" от дядюшки Боба (Роберта Мартина, не путать с Джорджем), то у нас получается, что у нас на каждую платформу есть две кодовых базы - с привязкой к фреймворку и полностью абстрактная логика. И переход на 3 базы означает экономию на одной абстрактной базе, которую все сейчас пишут заново.

Но есть две проблемы:
1. Практическое отсутствие действительно чистой архитектуры. Я работал в командах, которые декларировали чистую архитектуру под Андроид, но на деле это была просто удобная распилка на небольшие классы - но в каждом слое была привязка к конкретному фреймворку (Android). В то время, как "фреймворк - это деталь реализации" (с) Роберт Мартин в книге "Чистая архитектура". Следовательно, нет чистой абстрактной кодовой базы, которую можно было бы сделать общей, вообще нет привычки писать полностью оторвавшись от Андроида - отсылки к контексту и конкретным либам можно встретить на любом этапе логики.

2. в Андроид и iOS исторически сложился разный конкретный принцип "пиления" на отдельные классы - то, что называют "чистой архитектурой" из п.1 (которая, как я пояснил, часто не является чистой, так как в абстрактном слое нужна полная отвязка от платформы, от конкретных либ, даже от Rx, как бы это ни было тяжело). К примеру, в нашей команде iOS упарывался в хорошем смысле по VIPER, а Андроидеры фигачили разновидности MVC-MVVM.


Поэтому, когда Андроид-девелопере садились пилить на Xamarin, они писали общую часть по своим принципа, а iOS-отдел - хотел писать по своему. Это и создает дополнительные проблемы в кроссплатформе - столкновение "архитектурных привычек"

Универсальный-то выход по Роберту Мартину, который выстрадал свою точку зрения за десятки лет программирования (он кодил еще в 60х) - в таком пилении на классы, в такой архитектуре, в которой есть чистая логика, не привязанная к платформе, с объявленными интерфейсами, и блок реализации на конкретном фреймворке, платформе, устройстве. Тогда нам будет без разницы, какая ось победила в этом десятилетии и куда еще клиент хочет портировать свою программу - нам надо будет взять только часть кода, привязанную к конкретной реализации, и сделать ее для новой платформы.

6
Ответить

"он кодил еще в 60х"
Сергей, ну Вы сравнили, мамонта из 60-х и современные практики разработки :) Это как авто на паровом двигателе сравнивать с Теслой.
Сейчас разработка ПО ускоряется, никому эти вот архитектуры не всрались:
"в таком пилении на классы, в такой архитектуре, в которой есть чистая логика, не привязанная к платформе, с объявленными интерфейсами, и блок реализации на конкретном фреймворке, платформе, устройстве"
Пока Вы будете писать свою идеальную архитектуру, конкуренты уже запустят продукт и словят хайп и бенефиты. А под конец разработки Вашей идеальной архитектуры придет Product Owner и своими бизнес-требованиями разнесет эту архитектуру в неудачную поделку. Или при тестировании выяснится, что надо все переделывать из проблем с производительностью или совместимостью.

Касательно iOS/Android, если приложение позволяет использовать Cordova или React Native - тут можно сэкономить на кодовой базе, если нет - то лучше и не пытаться.

4
Ответить

Абсолютно точно!

Ответить