- macOS, Xcode и swift последних версий;
- настройка рабочего окружений через Bundler, используем SPM и Cocoapods;
- придерживаемся код-стайла, используем Swiftlint;
- применяем различные инструменты кодогенерации - SwiftGen, Generamba, XcodeGen, и тд.;
- предпочитаем MVP или MVVM с координаторами, но не зацикливаемся на чем-то одном;
- разделяем большие монолитные приложения на модули;
- настроенный CI/CD на каждом проекте (Fastlane + Jenkins);
- пишем и поддерживаем тесты и документацию.
Вот краткий список того, чего мы придерживаемся на наших проектах. Подробнее по каждому пункту можно прочитать ниже.
- Используем Bundler и закрепляем набор основных команд в Makefile
- Активно применяем инструменты для кодогенерации:
- SwiftGen для обеспечения type-safe доступа к ресурсам - asset-ам, шрифтам, строкам;
- Generamba для генерации кода модулей-экранов или отдельных компонентов, здесь можно найти студийные шаблоны для генерации MVP-модулей;
- XcodeGen для управления структурой проекта, а также более простого добавления и менеджмента новых модулей;
- SurfGen для проверки на корректность составления спецификации API в формате OpenAPI 3.x, а также генерации на её основе слоя моделей и сервис-слоя.
- Используем CocoaPods для управления сторонними зависимостями на проекте, но уже применяем SPM на всех новых проектах вместо CocoaPods.
- Для генерации новых проектов при их инициализации есть внутренняя разработка - набор скриптов, позволяющих создать проект с нуля вместе со всем необходимым окружением, базовыми файлами, структурой проекта и сертификатами/профайлами.
В рамках всей студии есть закрепленный code-style - увидеть его можно здесь. Проверка на соблюдаемость осуществляется с помощью Swiftlint, который настроен на всех проектах студии.
Проекты, на которых имеются отличия/отклонения/дополнения к нему - в обязательном порядке документируют их в технической документации к проекту.
- Разбиваем большие монолитные приложения на модули:
- новые приложения изначально проектируются таким образом, чтобы весь написанный код был разбит на четко определенные модули;
- проекты в поддержке постепенно разбиваются на модули;
- имеется опыт построения многомодульных приложений на таргетах, CocoaPods и SPM;
- такая структура проекта позволяет более четко определить границы видимости каждого компонента системы, тем самым помогая более правильно разбить приложение на независимые слои, а также помогает избежать конфликтов во время merge при работе в больших командах.
- В качестве архитектурного паттерна для конкретных экранов используем модифицированный MVP:
- Surf MVP является самым распространенным паттерном среди наших приложений;
- для более адекватной навигации используем надстройку в виде координаторов;
- но если для выполнения конкретной задачи или для реализации проекта в целом целесообразно применить другой паттерн (MVVM, VIPER, YARCH, etc.) - команда вправе принять самостоятельное коллективное решение о смене подхода.
- Делим приложение на независимые слои:
- на проектах есть четко выделенный и инкапсулированный сервис-слой;
- выделяем в отдельный модуль приложения все переиспользуемые UI-компоненты;
- ответственности не передаются в открытую, а закрываются протоколами, что позволяет уменьшить число зависимостей между компонентами системы и организовать их тестирование.
GutHub используется как место хранения и управления репозиториями в большинстве случаев: как для коммерческих проектов, так и для внутренних.
Принят следующий workflow для работы:
- на каждый спринт заводится dev/sprint-N ветка;
- все задачи делаются в отдельных ветках;
- в конце выполнения - отдельные ветки через pull request сливаются с dev/sprint-N веткой, если было пройдено обязательное code review и получено необходимое число апрувов от членов команды.
На всех коммерческих проектах настроен CI/CD:
- после создания каждого pull request-а и любого изменения в нем - выполняется build приложения;
- выгрузка приложения в Firebase/TestFlight срабатывает при пуше тэга в репозиторий;
- build и выгрузка приложения происходят на внутренних нодах, расположенных в контуре Surf;
- для распределения работы используется Jenkins, который вызывает конкретные Makefile команды проекта;
- на самом проекте для настройки необходимых действий в Makefile-командах (сборка проекта, тестирование, выгрузка в Firebase/TestFlight) используется Fastlane.
Open-source проекты не нагружаем сторонними зависимостями и обходимся без связки Fastlane + Jenkins, вызывая команды xcodebuild и ему подобные напрямую, а также используя GitHub Actions.
Список актуальных библиотек с открытым исходным кодом в фазе активного развития, в фазе поддержки и архивные проекты - можно посмотреть здесь.