При создании приложения на основе фреймворка Core Data мы проектируем модель данных, в которую потом снова и снова вносим изменения. Неужели при этом каждый раз нужно удалять все данные и загружать их заново, а заодно перегружать сервер и батареи пользователей? Сначала кажется, что это единственный вариант решения, но я выяснил — всё можно сделать проще.

В статье рассказываю, как свести к минимуму последствия изменений структуры данных и их негативное влияние, а также удивляюсь, почему Core Data ещё сам не предложил такое решение.

В предыдущей статье я рассказывал о том, как мы выделили модуль чата в нашем приложении. Всё прошло успешно, и мы собирались распространить этот опыт — начать тотальную модуляризацию в iOS-разработке Badoo. Даже презентовали подход продуктовым командам, командам, занимающимся тестированием и непрерывной интеграцией, и постепенно стали внедрять модуляризацию в наши процессы. 

Мы сразу понимали что будут проблемы, поэтому не торопились и раскатывали решение поэтапно, что помогло нам вовремя понять проблемы о которых пойдет речь далее. 

В этой статье я расскажу:

— как мы не потерялись в сложном графе зависимостей;

— как спасли CI от чрезмерной нагрузки;

— что делать, если с каждым новым модулем приложение запускается всё медленнее;

— мониторинг каких показателей стоит предусмотреть и почему это необходимо.

В iOS-разработке Badoo мы уже несколько лет занимаемся созданием модулей, и большая часть нового кода разрабатывается вне кодовой базы приложений. Сейчас у нас более 100 модулей для Badoo и Bumble. В этой статье я расскажу о нашем опыте и отвечу на самые популярные вопросы о модуляризации: 

— по какому принципу выделять модули; 

— как организовать связи между ними; 

— достаточно ли для фичи одного фреймворка; 

— как сократить время запуска многомодульного приложения; 

— зачем в этом процессе мониторинг;

— можно ли автоматизировать создание новых модулей и так далее. 

Мой коллега, лид команды iOS-разработки и Core-команды Артем Лоенко, в начале года говорил об этом на митапе FunCorp в докладе «Катастрофически полезные последствия модуляризации». Я приведу более подробный разбор процесса модуляризации и некоторых опущенных в его рассказе деталей.