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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Одной из основных причин разработки микросервисов является то, что они обеспечивают четкие границы модулей. 

Однако минусы микросервисов настолько огромны, что это все равно, что отрубить себе правую руку, чтобы научиться писать левой; есть более управляемые (и менее болезненные!) способы достижения того же результата.

Даже с тех пор, как началось повальное увлечение микросервисами, возобладали некоторые более хладнокровные. В частности, Оливер Дротбом, разработчик среды Spring, долгое время был сторонником альтернативы moduliths. Идея состоит в том, чтобы сохранить монолит, но спроектировать его вокруг модулей.

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

Модульный монолит — это подход к проектированию приложений, который позволяет, с одной стороны, отложить во времени операционную сложность использования микросервисов, а с другой — избежать превращения монолитной системы в большой комок грязи. Сама идея модульности не нова и основана на давно известных принципах Separation of Concerns и Information Hiding. Но не так-то просто перейти от абстрактных принципов к пониманию, как их реально использовать на практике.

На Хабре не так много информации о модульных монолитах в целом и практически ничего о конкретных вариантах их реализации. Но об этом есть серия статей у Камиля Гржибека. Сегодня поделюсь переводом первой из них.

Всем привет сегодня я покажу как можно завернуть проект в spm (модуляризация)

Модуляризация — Это процесс разбиения кодовой базы на небольшие специализированные, готовые к повторному использованию модули

У меня есть небольшой проект и я хочу чтобы он был завернут в spm.