Статья

Архитектура системы сборки готовое приложения из модулей

Смартфоны давно уже не являются роскошью или чем то экстраординарным. Их массовое распространение в начале 2010-х привело к тому, что рынок мобильной разработки вырос многократно и конкуренция на нем в том числе. И все важнее стало правильных пропорциях совмещать скорость и качество разработки. Кроме того, довольно часто приложения для разных заказчиков отличаются лишь некоторым уникальным функционалом, что приводит к вопросу о использовании конструкторов и case-средств. И в своем время такой же высокий рост развития интернета и необходимость разработки сайтов со схожим функционалом привел к широкому распространению разных конструкторов сайтов и case-средств. 

В мобильной разработке таких средств нет и вся автоматизация разработки пока что сводится к менеджерам пакетов. К тому же многие идеи case-средств невозможно реализовать из-за различных ограничений мобильных платформ на работу уже установленных приложений. Кроме того, хотелось бы использовать все возможности исключений и обработки отсутствующего функционала, что позволило бы писать код один раз, а потом просто использовать его в нужных местах.

Именно поэтому появилась идея разработки инструментального окружения, позволяющего упростить и ускорить разработку приложений для мобильных платформ. Идея состоит в том, что бы свести разработку приложения к написанию модулей, необходимых для работы приложения, указать для каждого из них, какой функционал им необходим для работы. Кроме того дать возможность некоторым модулям отсутствовать в приложении, что не привело бы к ошибкам компиляции или ошибкам времени выполнения. И в конце концов свести сборку нового приложения к простому указанию его конфигурации и конфигурации его модулей.

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


Введение
Проблемы: 
	Высокая конкуренция. 
	Требуется скорость и качество. 
	Однотипные приложения. 
	Возможность переиспользования большого количества кода. 
	Только менеджеры пакетов
Цели:
	Спроектировать архитектуру инструментального окружения, позволяющего производить быструю сборку готовых приложений с использованием уже написанных модулей по определенной конфигурации
Задачи:
	 Спроектировать архитектуру окружения, клиентскую и серверную части. 
	 	Определить спецификации модуля, приложения. 
	 	Описать алгоритм движка, осуществляющего сборку готового приложения. 
	 	Описать хранилище модулей и алгоритмы их валидация и обработки. 
	 	Описать протокол взаимодействия между клиентом и сервером. 
	 	Описать тех процесс разработки приложения: 
	 		написание модуля, 
	 		отправка не сервер, 
	 		описание сборки приложения, 
	 		формирования проекта приложения, 
	 		генерация исходного кода сборки приложения.

Мы не знаем про "КОП"





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

Удобство. Упрощение. Ускорение.

Пока что на базе CocoaPods

Задача в первую очередь состоит в том, что бы создать интструментальное окружение для разработчика, которое позволит ему более эффективно писать и собирать приложения, которые переиспользуют некоторую формально описанную кодовую базу. Для этого вводится понятие модуля, как функционально законченного фрагмент программы. При помощи описания модлуля через специальные файлы-манифесты и средства доступа к нему через определенный интерфейс появляется возможность абстрагироваться от реализации конкретного модуля и обработать его отсутствие в конечной сборке приложения.

Рассматриваем ситуация только с ios swift разработкой.

Модуль по сути своей будет Pod'ом, но кроме спецификации для самого CocoaPods, будет обладать еще и собственным манифестом, в котором будут описаны необходимые для сборки мета-данные и зависимости, и который будет необохдим для дальнейшей сборки.



Внешняя зависимость - cocoapods
Внутреняя зависимост - модуль
К1. Первая часть клиентского интрументария представляет собой набор ПО для создания отдельных компонентов системы - модулей. Он состоит из следующих частей:
	Инструмент для генерации и конфигурации шаболнных проектов модулей 
	Инструмент для оперирования мета-данными модуля и его зависимостями

К2. Вторая часть представляет из себя ПО по генерации готового приложения. Создает шаблон проекта приложения, подгружает все необходимые внешние и внутренние зависимости и генерирует код сборки всего приложения.

С1. Сервер состоит из 3 частей.
	git-репозиторий, в котором хранятся модули.
	api позволяющее генерировать итоговый файл для cocoapods
	бд, для хранения мета данных о модулях

Одна из основных задач - это проектирование всех необходимых компонент такого окружения. И клиент-серверная архитектура для этого очень хорошо подходит: и разработка модулей происходит на локальных машинах с использованием  дополнительной места информации о приложении и возможностях взаимодействия между модулями и сборка готового приложения из готовых модулей по определённой конфигурации, а на сервере в свою очередь будут храниться сами модули индивидуальных репозиториях, валидация метаданных о модулях, разрешение зависимостей в конфигурации приложения и формирование под файла для клиентской части. 

Технологический процесс написания модуля будет выглядеть следующим образом: 
* Генерация файла манифеста и описание всех необходимых зависимостей. 
* Написание модуля. Описание интрефейса доступа к модулю
* Добавление в файл манифест информации об интерфейсе. 
* Далее модуль обычным гит Пушем отправляется в свой репозиторий
* В гит репозитории с помощью специально написанного скрипта-хука интерфейс модуля сравнивается с его спецификацией. И если модуль Валиде, то информациям о нем попадает в базу доступных для использования модулей.
* Так происходит для каждого следующего написанного модуля. 

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