Pull to refresh

Comments 8

Хорошая статья, очень легко и интересно читается, грамотно продумали структуру, спасибо за то, что делитесь опытом!

Несколько технических вопросов:
1) Как реализованы Visual Regression Tests? Какое-то стороннее решение используете?
2) Приложение UIGallery создавали просто чтобы видеть все компоненты в одном месте или какую-то функциональную нагрузку оно тоже имеет? Оно обновляется вручную или пересобирается автоматически при добавлении новых UI-подмодулей в репозиторий?
3) Для реализации UI в модулях используете XIB-ы? Или может даже на SwiftUI начали переходить?
4) Как конкретно вы реализовывали явные зависимости? Из абзаца про них ясно только, что вы на них перешли :) Вижу, что в след. статье будет про граф зависимостей, если там будет и описание по настройке явных зависимостей, то вопрос считайте неактуальным, подождем статью.
Привет, спасибо за обратную связь! Извиняюсь за задержку с ответами, идем по порядку:
1-2. UIGallery как раз является таргетом, агрегирующим все UI подмодули. Есть модель, в которой зарегистрированы все интересующие билдеры вьюшек. Когда UIGallery запускается как приложение — из этой модели строится табличка, где по каждому пункту можно провалиться и посмотреть как это выглядит. Когда запускается тест-схема, из добавленных туда примеров автоматически формируется итоговый набор тест кейсов (через XCTestSuite). Генерацию снепшотов и сравнение сейчас делаем с помощью FBSnapshotTestCase, но планируем в ближайшее время переехать на что-то более легковесное и свифтовое. Техникой, как автоматически добавить множество различных конфигураций UIView с разными стилями и вью моделями пока не овладели, поэтому разработчик делает это сам.
3. Всю верстку сейчас пишем кодом, активно отрабатываем переход на SwiftUI, но пока что не можем отказаться от iOS 12 из-за неутешительной статистики ее использования.
4. Об этом будет в следующей статье, в целом стоит лишь выключить галочку Find Implicit Dependencies и посмотреть где что не прилинковано после Clean Build. А так — да, дальше расскажу поподробнее как мы работаем с этим при большом количестве модулей.

По поводу зависимостей. Мы используем https://github.com/yonaskolb/XcodeGen Там есть куча возможностей сгенерировать проект со всеми модулями, флагами, зависимостями и т.д. Можно легко менять тип модуля и его линковки. Нет проблем с ребейсом, ничего никогда не теряется или случайно не выключается. Проект файл даже не коммитится в git и CI и каждый девелопер генерирует его на своей машине.
Сам пользуюсь уже несколько лет и для своих личных проектов и не нашел ни одного минуса

Спасибо! Мы его тоже используем, но сейчас только для генерации новых модулей. В целом можно рассматривать переезд на XcodeGen и для большого «взрослого» проекта, но это может быть достаточно трудоемкой задачей.
Отличная статья! Вы не тестировали swift package manager?
Привет, к моменту когда мы решили делить приложение на модули, SPM еще не поддерживал iOS проекты без костылей, поэтому сейчас мы рассматриваем его как потенциальный менеджер зависимостей. Однако, скорее всего, только для внешних зависимостей, т.к. deps (о нем будет чуть подробнее во 2 статье, в течение недели должна опубликоваться) отлично справляется с нашим сложным графом и очень гибок в настройках (по сравнению с SPM, где пока мало параметров Build Settings можно кастомизировать)
Sign up to leave a comment.