Блог компании vivid money

Возможно, вы знаете про Vivid, где-то слышали или же видите впервые. Мы делаем один из самых быстрорастущих и многообещающих финансовых сервисов в Европе. Чтобы не быть голословным, вот некоторые из наших показателей:

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

Немного вводных

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

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

Наши особенности

Кроме основных обязанностей интервьюеров мы старались делать следующее:

• Располагать к себе кандидата и создавать friendly атмосферу

• Задавать вопросы по ситуации, а не по заготовленному сценарию

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

Для собеседования мы не готовили список вопросов мы готовили темы на которые хотим поговорить. Такими темами были: Swift (куда же без знания языка), UI (так как у нас его очень много, он на 95% кастомный и иногда нетривиальный) и архитектура (для ведущего разработчика это очень важно). По каждой теме мы старались спрашивать только то, что в основном используется в повседневной разработке и то, что связано с нашим приложением. Конечно, иногда мы углублялись в какой-то вопрос, чтобы понять насколько хорошо кандидат знает тему, но тут есть тонкость если вдруг человек не отвечает или отвечает неправильно, мы не делаем на этом сильный акцент, так как это опциональные вопросы и ответы на них не обязан знать каждый.
Также для нас была очень важна практика, так как это то, что раскрывает способности разработчика лучше всяких вопросов. У нас были заготовлены различные задачи, которые мы выбирали в зависимости от ситуации. Среди них не было вопросов по алгоритмам, потому что мы не считаем их показательными они показывают умение находить решения (или вспоминать их), а не умение писать код. Наши задачи показывали то, как кандидат обычно пишет свой код, какие конструкции использует, насколько оптимальны его решения и как он размышляет.

Формат собеседования

Экспериментировать и меняться это то, что свойственно нашей компании. Собеседования не исключение. Мы попробовали разные форматы: одно собеседование на 1.5 часа с вопросами "по ситуации", теоретическое собеседование на 1 час и практическое на 1.5 часа, теоретическое собеседование на 1 час и тестовое задание. В конце-концов мы пришли к следующему:

• Скрининг перед собеседованием из 6 вопросов.

• Одно собеседование на 1.5-2 часа. Из них 10-20 минут на общение с кандидатом не на технические темы, 30-40 минут на кодинг и остальное время на теорию.

• Интервью всегда проводят 2 человека это дает более объективную оценку кандидата после собеседования.

• Каждый интервьюер ведет свою тему. Это позволяет более логично выстроить общение, так как другой собеседующий не будет задавать свои вопросы, уводя беседу в другую сторону или прерывая текущую мысль.

Скрининг

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

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

Циферки:

• Средняя длительность скрининга 4 минуты

• Процент кандидатов, прошедших скрининг 75%

Техническая часть

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

Поняв наши проблемы, мы переработали техническую часть. Теперь у собеседования есть "сценарий", представляющий собой древовидную схему в Miro.

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

Есть одна особенная ветка Swift. Для движения по ней мы проводим лайвкодинг, в рамках которого кандидат решает поставленную задачу, у которой добавляются или меняются требования (прям как в реальной жизни). Задача затраивает практически весь синтаксис языка при ее небольшом объеме. По ходу решения мы задаем вопросы. Например: "Почему использовал class, а не struct?", "Можно ли задачу решить по-другому?" и так далее.

Таким образом, мы получили "фреймворк" для собеседования. Он позволил нам:

• быстро понимать во время собеседования что спрашивать

• вести собеседование более структурировано

• быстро обучать новых интервьюеров

Как оцениваем кандидатов

Нельзя не затронуть столь субъективную тему как оценка уровня кандидата. Мы разделяем уровни разработчика как и многие другие: Junior, Middle, Senior. К каждому уровню еще можем добавлять + или - чтобы оценка была немного более точной.

Для определения уровня используем следующие маркеры:

• Предыдущий опыт. Чем больше в нем сложных и разнообразных задач, тем выше уровень.

• Решение задачи. Чем быстрее и правильнее решена задача, чем чище код и чем лучше обоснованы решения, тем выше уровень.

• Ответы на теоретические вопросы. Тут нам важно понять, подкреплено ли знание теории практикой. Если кандидат отвечает на вопрос это хорошо, но если еще и приводит примеры из опыта или объясняет своими словами, то еще лучше. Короче говоря, для нас понимание важнее знания.

• Умеренный перфекционизм. Это когда кандидат достаточно хорошо продумывает решение, но не тратит кучу времени на незначительные мелочи.

После выхода на работу

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

Напоследок

Надеюсь, вам понравилась статья и вы нашли в ней что-то полезное. Будем рады ответить на комментарии пишите, не стесняйтесь. Также вы можете почитать еще одну нашу статью про найм. Если же вам интересно пройти собеседование, следите за вакансиями здесь.

На этом все. Всем удачи на собеседованиях!

Вступление

Это третья часть серии статей об архитектуре android приложения vivid.money. В ней мы расскажем об Elmslie - библиотеке для написания кода под android с использованияем ELM архитектуры. Мы назвали ее в честь Джорджа Эльмсли, шотландского архитектора. С сегодняшнего дня она доступна в open source. Это реализация TEA/ELM архитектуры на kotlin поддержкой android. В первой статье мы рассказали о том почему выбрали ELM. Перед прочтением этой статьи лучше ознакомиться как минимум со второй частью, в которой мы более подробно рассказывали том собственно такое ELM.

Оглавление

• Часть первая. Как мы выбрали архитектуру слоя представления на новом проекте и не прогадали.

• Часть вторая. Разбираем ELM архитектуру в рамках мобильного приложения.

• Часть третья. Пишем под android с Elmslie.

Что будем писать

В предыдущей статье мы рассказывали о том что такое ELM архитектура. В ней приводился пример, его и будем реализовывать. В нем происходит загрузка числового значения и есть возможность его обновлять. Исходный код для этого примера доступен на GitHub.

Модель

Написание экрана проще начинать с проектирования моделей. Для каждого экрана нужны State, Effect, Command и Event. Рассмотрим каждый из них по очереди:

State

State описывает полное состояние экрана. В каждый момент времени по нему можно полностью восстановить то что сейчас показывается пользователю. Правильнее делать исключения, если это усложняет логику. Не нужно сохранять, показывается ли сейчас диалог на экране или что сейчас находится в каждом EditText.

На нашем экране будет отображаться либо числовое значение, либо состояние загрузки. Это можно задать двумя полями в классе: val isLoading: Boolean и val value: Int?. Для удобства изменения, State лучше реализовывать как data class. В итоге получается так:

data class State(  val isLoading: Boolean = false,  val value: Int? = null)

Effect

Каждый Effect описывает side-effect в работе экрана. То есть это события, связанные с UI, происходящие ровно один раз, причем только когда экран виден пользователю. Например, это могут быть навигация, показ диалога или отображение ошибки.

В нашем примере единственной командой UI будет показ Snackbar при ошибке загрузки value. Для этого заведем Effect ShowError. Для удобства Effect можно создавать как sealed class, чтобы не забыть обработать новые добавленные эффекты:

sealed class Effect {  object ShowError : Effect()}

Command

Каждая Command обозначает одну асинхронную операцию. Подробнее о том как они обрабатываются расскажем чуть позже. В результате выполнения команды получаются события, которые в свою очередь повлияют на состояние экрана.

У нас будет одна операция - загрузить данные. Эту Command назовем LoadValue. Команды так же удобнее задавать как sealed class:

sealed class Command {  object LoadValue : Command()} 

Event

Все события, которые влияют на состояние и действия на экране: Ui: ЖЦ экрана, взаимодействие с пользователем, все что приходит из View слоя Internal: Результаты операций с бизнес логикой

Теперь перейдем к событиям. В нашем проекте мы разделяем события на две категории:

• Event.UI: все события, которые происходят во View слое

• Event.Internal: результаты выполнения команд в Actor.

В этом примере будет два UI события: Init - открытие экрана и ReloadClick - нажатие на кнопку обновления значение. Internal события тоже два: ValueLoadingSuccess - успешный результат Command LoadValue и ValueLoadingError, которое будет отправляться при ошибке загрузки значения.

Если использовать разделение на UI и Internal, то Event удобнее задавать как иерархию sealed class:

sealed class Event {  sealed class Ui : Event() {    object Init : Ui()    object ReloadClick : Ui()  }     sealed class Internal : Event() {    data class ValueLoadingSuccess(val value: Int) : Internal()    object ValueLoadingError : Internal()  }}

Реализуем Store

Закончив с моделями, перейдем собственно к написанию кода. Сам Store реализовывать не нужно, он предоставляется библиотекой классом ElmStore.

Repository

Для нашего примера напишем симуляцию работы с моделью, которая будет возвращать либо случайный Int, либо ошибку:

object ValueRepository {private val random = Random()fun getValue() = Single.timer(2, TimeUnit.SECONDS)    .map { random.nextInt() }    .doOnSuccess { if (it % 3 == 0) error("Simulate unexpected error") }}

Actor

Actor - место, в котором выполняются долгосрочные операции на экране - запросы в сеть, подписка на обновление данных, итд. В большинстве случаев, как и в нашем примере просто маппит результаты запросов в Event.

Для его создания нужно реализовать интерфейс Actor, который предоставляется библиотекой. Actor получает на вход Command, а результатом его работы должен быть Observable<Event>, с событиями, которые сразу будут отправлены в Reducer. Для удобства в библиотеке есть функции mapEvents, mapSuccessEvent, mapErrorEvent и ignoreEvents, которые позволяют преобразовать данные в Event.

В нашем случае Actor будет выполнять только одну команду. При выполнении команды загрузки мы будем обращаться к репозиторию. В случае получения успешного значения будет оправляться событие ValueLoaded, а при ошибке ErrorLoadingValue. B итоге получается такая реализация:

class Actor : Actor<Command, Event> {override fun execute(command: Command): Observable&lt;Event&gt; = when (command) {    is Command.LoadNewValue -&gt; ValueRepository.getValue()        .mapEvents(Internal::ValueLoaded, Internal.ErrorLoadingValue)}}

Reducer

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

В этом классе нужно реализовать функцию reduce для обработки событий. Помимо вашей логики в Reducer можно использовать 3 функции:

• state - позволяет изменить состояние экрана

• effects - отправляет эффект во View

• commands - запускает команду в Actor

class Reducer : DslReducer<Event, State, Effect, Command>() {override fun Result.reducer(event: Event) = when (event) {    is Internal.ValueLoaded -&gt; {        state { copy(isLoading = false, value = event.value) }    }    is Internal.ErrorLoadingValue -&gt; {        state { copy(isLoading = false) }        effects { +Effect.ShowError }    }    is Ui.Init -&gt; {        state { copy(isLoading = true) }        commands { +Command.LoadNewValue }    }    is Ui.ClickReload -&gt; {        state { copy(isLoading = true, value = null) }        commands { +Command.LoadNewValue }    }}}

Собираем Store

После того как написаны все компоненты нужно создать сам Store:

fun storeFactory() = ElmStore(    initialState = State(),    reducer = MyReducer(),    actor = MyActor()).start()

Экран

Для написания android приложений в elmslie есть отдельный модуль elmslie-android, в котором предоставляются классы ElmFragment и ElmAсtivity. Они упрощают использование библиотеки и имеют схожий вид. В них нужно реализовать несколько методов:

• val initEvent: Event - событие инициализации экрана

• fun createStore(): Store - создает Store

• fun render(state: State) - отрисовывает State на экране

• fun handleEffect(effect: Effect) - обрабатывает side Effect

В нашем примере получается такая реализация:

class MainActivity : ElmActivity<Event, Effect, State>() {override val initEvent: Event = Event.Ui.Initoverride fun onCreate(savedInstanceState: Bundle?) {    super.onCreate(savedInstanceState)    setContentView(R.layout.activity_main)    findViewById&lt;Button&gt;(R.id.reload).setOnClickListener {        store.accept(Event.Ui.ClickReload)     }}override fun createStore() = storeFactory()override fun render(state: State) {    findViewById&lt;TextView&gt;(R.id.currentValue).text = when {        state.isLoading -&gt; &quot;Loading...&quot;        state.value == null -&gt; &quot;Value = Unknown&quot;        else -&gt; &quot;Value = ${state.value}&quot;    }}override fun handleEffect(effect: Effect) = when (effect) {    Effect.ShowError -&gt; Snackbar        .make(findViewById(R.id.content), &quot;Error!&quot;, Snackbar.LENGTH_SHORT)        .show()}}

Заключение

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

Думаю, ни для кого не секрет, что в разговорах опытных разработчиков Python, и не только, часто проскальзывают фразы о том, что Django это зло, что в Django плохая архитектура и на ней невозможно написать большой проект без боли. Часто даже средний Django проект сложно поддерживать и расширять. Предлагаю разобраться, почему так происходит и что с Django проектами не так.

Немного теории

Когда мы начинаем изучать Django без опыта из других языков и фреймворков, помимо документации мы читаем туториалы, статьи, книги, и почти во всех видим что-то подобное:

Django это фреймворк, использующий шаблон проектирования Model-View-Controller (MVC).

И дальше куча неточных схем и объяснений о том, что такое MVC. Почему они неточные и что с ними не так, можно посмотреть здесь или здесь.

Обычно в таких схемах MVC описывают подобным образом:

• Model доступ к хранилищу данных

• View это интерфейс, с которым взаимодействует пользователь

• Controller некий связывающий объект между model и view.

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

Стоит обратить внимание на две вещи.

Первое, часто под M в MVC подразумевают модель данных, и говорят, что это некий класс, который отвечает за предоставление доступа к базе данных. Что неверно, и не соответствует классическому MVC и его потомкам MV*. В классическом MVC под M подразумевается domain model объектная модель домена, объединяющая данные и поведение. Если говорить точнее, то M в MVC это интерфейс к доменной модели, так как domain model это некий слой объектов, описывающий различные стороны определенной области бизнеса. Где одни объекты призваны имитировать элементы данных, которыми оперируют в этой области, а другие должны формализовать те или иные бизнес-правила.

Второе, в Django нет выделенного слоя controller, и когда вам говорят, что в Django слой views это контроллер, не верьте этим людям. Обратитесь к официальной документации, а точнее к FAQ, тогда можно увидеть, что этот слой вписывается в принципы слоя View в MVC, особенно, если рассматривать DRF, а как такового слоя Controller в Django нет. Как говорится в FAQ, если вам очень хочется аббревиатур, то можно использовать в контексте Django аббревиатуру MTV (Model, Template, and View). Если очень хочется рассматривать Web MVC и сравнивать Django с другими фреймворками, то для простоты можно считать view контроллером.

Несмотря на то, что Django не соответствует MVC аббревиатуре, в ней реализуется главный смысл MVC отделение бизнес-логики от логики представления данных.Но на практике это не всегда так по нескольким причинам, которые мы рассмотрим ниже.

Перейдем к практике

Выделим в Django приложениях несколько слоев, которые есть в каждом туториале и почти в каждом проекте:

• front-end/templates

• serializers/forms

• views

• models

Не будем рассматривать каждый слой подробно, это все можно найти в документации. В основном будем рассматривать Django c использованием DRF. Попробуем разобрать на двух простых кейсах, что стоит помещать в каждом из слоев и какая ответственность у каждого слоя.

Первый кейс создание заказа. При создании заказа нам нужно:

• проверить валидность заказа и доступность товаров

• создать заказ

• зарезервировать товар на складе

• передать заявку менеджеру

• оповестить пользователя о том, что его заказ принят в работу

Второй кейс просмотр списка моих заказов. Здесь все просто, мы должны показать пользователю список его заказов:

• получить список заказов пользователя

Слой serializers/forms

У слоя serializers три основные функции (все выводы для serializers справедливы и для forms):

• валидировать данные

• преобразовывать данные запроса в типы данных Python

• преобразовывать сложные Python объекты в простые типы данных Python (например, Django модели в dict)

Дополнительно сериалайзеры имеют два метода, create и update, которые вызываются в методе save() и почти всегда используются во view.

Пример использования из документации:

class CommentSerializer(serializers.Serializer):email = serializers.EmailField()  content = serializers.CharField(max_length=200)  created = serializers.DateTimeField()  def create(self, validated_data):  return Comment.objects.create(**validated_data)  def update(self, instance, validated_data):    instance.email = validated_data.get('email', instance.email)    instance.content = validated_data.get('content', instance.content)    instance.created = validated_data.get('created', instance.created)    instance.save()    return instance

Где-то в нашей view:

# .save() will create a new instance.serializer = CommentSerializer(data=data)# .save() will update the existing `comment` instance.serializer = CommentSerializer(comment, data=data)comment = serializer.save()

В данном подходе за сохранение и обновление сущностей отвечает сериалайзер, точнее он оперирует методами модели.

Можно использовать ModelSerializer и ModelViewSet, что позволяет писать CRUD методы в пару-тройку строк.

# serializers.pyclass OrderSerializer(serializers.ModelSerializer):class Meta:  model = Order    fields = __all__# views.pyclass OrderViewsSet(viewsets.ModelViewSet):queryset = Order.objects.all()  serializer_class = OrderSerializer

Если углубиться в реализацию ModelViewSet и ModelSerializer, то можно заметить, что за сохранение и обновление сущностей также отвечает сериалайзер.

В таком случае, кажется, что переопределение create отличное место для того, чтобы описать там все бизнес-процессы и правила создания заказа.

# serializers.pyclass OrderSerializer(serializers.ModelSerializer):class Meta:model = Orderfields = []def create(self, validated_data):# Проверяем, что все товары есть и заказ валиден...# Создаем запись о заказе в БДinstance = super(OrderSerializer, self).create(validated_data)    # Бронируем товары на складе    ...    # Передаем заявку менеджеру    ...    # Оповещаем пользователя    ...    return instance  # views.pyclass OrderViewsSet(viewsets.ModelViewSet):queryset = Order.objects.all()  serializer_class = OrderSerializer

Если с методом создания мы что-то придумали, то логику получения заказов пользователя придется помещать в view.

Получается такая схема:

Плюсы данного подхода:

Легко делать CRUD

Django и DRF предоставляют очень удобные инструменты с помощью которых можно легко создавать CRUD.

Минусы данного подхода:

Нарушение идей MVC

Мы смешиваем бизнес-логику с задачей сериализации (получения/отображения) данных в одном слое. Ни о каком выделенном слое бизнес-логики у нас нет и речи.

Сериалайзеры стоит относить к слою View в MVC в контексте Django. Когда мы располагаем в сериалайзерах свою бизнес логику, мы нарушаем главный принцип MVC отделение логики представления данных от бизнес-логики.

Нельзя переиспользовать

Не получится переиспользовать логику одного сериалайзера в другом сериалайзере, или в каком-то другом компоненте.

Сложно тестировать

Сложно протестировать бизнес-логику независимо от логики сериализации и валидации данных.

Сложно поддерживать

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

В итоге мы получаем разбросанные бизнес-правила по всему проекту, которые невозможно переиспользовать и очень сложно поддерживать.

Высокая зависимость от фреймворка

Высокая зависимость от DRF Serializers или Django Forms. Если мы захотим поменять способ сериализации и отказаться от serializers, то придется переносить или переписывать нашу логику. Также будет сложно переехать с Django Forms на DRF Serializers или наоборот.

Правильные обязанности слоя

Сериализация/десериализация данных

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

Валидация данных

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

Заключение

Сериалайзеры точно не подходят для написания в них бизнес-логики.Если вам нужно что-то большее, чем CRUD, то стоит отказаться от использования метода save у сериалайзеров, так как сохранение данных не должно входить в их обязанности.

Стоит отказаться от ModelSerializer с его магическими методами create и update и заменить их на обычные сериалайзеры (можно использовать ModelSerializer как read only для удобства). Если вы пишете какое-то простое приложение, где кроме CRUD ничего не нужно, то можно не отказываться от удобства DRF и использовать сериалайзеры как предлагается в документации.

Слой Views

Слой View в контексте Django отвечает за представление и обработку пользовательских данных, в нем мы описываем, какие данные нам нужны и как мы хотим их представить. Если вспомнить то, о чем мы говорили в начале, то можно сразу сделать вывод, что во views не нужно писать бизнес-логику, иначе мы смешиваем логику представления данных с бизнес-логикой. Даже если считать, что views в Django это контроллеры, то размещать в них бизнес-логику тоже не стоит, иначе у вас получатся ТТУКи (Толстые, тупые, уродливые контроллеры; Fat Stupid Ugly Controllers).

Но часто можно увидеть что-то подобное:

# views.pyclass OrderViewsSet(viewsets.ModelViewSet):queryset = Order.objects.all()  serializer_class = OrderSerializer                                  def perform_create(self, serializer):  # Проверяем, что все товары есть и заказ валиден    ...    # Создаем запись о заказе в БД    super(OrderViewsSet, self).perform_create(serializer)    # Бронируем товары на складе    ...    # Передаем заявку менеджеру    ...    # Оповещаем пользователя    ...

По дефолту, в ModelViewSet для сохранения и обновления данных используется сериалайзер, что не входит в его обязанности. Это можно исправить, полностью переопределить метод perform_create (не вызывать super, но тогда встает вопрос об объективности наследования от ModelViewSet). Можно написать кастомные методы в ModelViewSetили написать кастомные APIView:

# views.pyclass OrderCreateApi(views.APIView):class InputSerializer(serializers.ModelSerializer):  number = serializers.IntegerField()    ...                     def post(self, request):  serializer = self.InputSerializer(data=request.data)    serializer.is_valid(raise_exception=True)    # Проверяем, что все товары есть и заказ валиден    ...    # Создаем запись о заказе в БД                                             order = Order.objects.create(**serializer.validated_data)    # Бронируем товары на складе    ...    # Передаем заявку менеджеру    ...    # Оповещаем пользователя    ...                       return Response(status=status.HTTP_201_CREATED)

В отличии от слоя serializers, мы теперь легко можем поместить нашу логику получения заказов в слой views.

# views.pyclass OrderViewsSet(viewsets.ModelViewSet):queryset = Order.objects.all()  serializer_class = OrderSerializer                            def get_queryset(self):  queryset = super(OrderViewsSet, self).get_queryset()    queryset = queryset.filter(user=self.request.user)    return queryset

Тем самым, ограничив не только получение списка, но и другие методы CRUD, что, иногда, очень удобно и быстро. Также, можно переопределить каждый метод по отдельности.

Получается такая схема:

Стоит помнить, что мы отказались от использования saveу serializers. В таком случае слой serializers остается чистым и выполняет только правильные обязанности.

Плюсы данного подхода

Легко делать CRUD

Django и DRF предоставляют очень удобные инструменты, с помощью которых можно легко создавать CRUD и views не исключение.

Минусы данного подхода

Нарушение идей MVC

Мы смешиваем в одном слое логику представления данных и бизнес-логику приложения.

Нельзя переиспользовать

Не получится переиспользовать логику одной view в другой view, или в каком-то другом компоненте. Так же будут проблемы, если мы захотим вызывать нашу бизнес-логику из других интерфейсов, например, из Celery задач.

Высокая зависимость от фреймворка

Высокая зависимость от DRF View или Django View. Если мы захотим поменять способ обработки запроса и отказаться от views, то придется переносить или переписывать нашу логику. Будет сложно переехать с Django View на DRF View или наоборот.

Сложно тестировать

Достаточно сложно протестировать код во views независимо от serializers и остальной инфраструктуры Django + придется использовать http client для тестирования.

Сложно поддерживать

Со временем views разрастаются, часть логики переносится в Celery задачи, часть в модели, код во views дублируется, так как их нельзя переиспользовать все это приводит к тому, что проект сложно поддерживать.

Правильные обязанности слоя

Обработка запроса

Во view мы принимаем и обрабатываем запрос клиента, подготавливаем данные для передачи в бизнес-логику.

Делегирование сериализации данных сериалайзерам

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

Вызов методов бизнес-логики

После подготовки и сериализации данных вызывается интерфейс бизнес-логики.

Логика представления данных

Мы должны обработать ответ от методов бизнес-логики и предоставить нужные данные клиенту.

Заключение

Вывод примерно такой же как и с serializers в views не стоит размещать бизнес-логику.

Стоит отказаться от ModelViewSet и миксинов, так как они используют сериалайзеры для сохранения данных, вместо этого использовать обычные APIView или GenericAPIView.

Если вам нужен только CRUD, то можно использовать подход который предоставляет ModelViewSet и не усложнять себе жизнь.

Слой models

Если опираться на более продвинутые туториалы или вспомнить слой Model в MVC, то кажется, что models отличное место для размещения бизнес-логики.

Это может выглядеть примерно так:

# models.pyclass Order(models.Model):number = serializers.IntegerField()  created = models.DateTimeField(auto_now_add=True)  status = models.CharField(max_length=16)                                               def update_status(self, status: str) -> None:  self.status = status    self.save(update_fields=('status',))  ...    @classmethod  def create(cls, data...):  instance = cls(...)    # Проверяем, что все товары есть и заказ валиден    ...    # Создаем запись о заказе в БД    instance = instance.save()    # Бронируем товары на складе    ...    # Передаем заявку менеджеру (например на почту или создаем какую то запись в БД)    ...    # Оповещаем пользователя    ...# views.pyclass OrderCreateApi(views.APIView):class InputSerializer(serializers.ModelSerializer):  number = serializers.IntegerField()    ...      def post(self, request):  serializer = self.InputSerializer(data=request.data)    serializer.is_valid(raise_exception=True)        Order.create(**serializer.validated_data)                    return Response(status=status.HTTP_201_CREATED)

В view мы сериализуем данные с помощью serializer и вызываем метод создания заказа у класса модели.В данном случае мы реализовали classmethod, что бы не было необходимости создавать экземпляр модели. Иначе нам придется понимать какие данные относятся к полям модели, а какие мы должны передать в метод создания, а это уже некие бизнес- правила.

Стоит заметить, что не нужно писать бизнес-логику в методе save(), так как это базовый метод модели и он может неоднократно использоваться в различных частях кода.

Для методов получения данных в таком случае стоит использовать Managers.

# views.pyclass OrderListApi(views.APIView):class OutputSerializer(serializers.ModelSerializer):  class Meta:    model = Order      fields = __all__                             def get(self, request):  orders = Order.objects.filter(user=request.user)    # если у вас сложные условия фильтрации    # например, Order.objects.filter(user=request.user, is_deleted=False, is_archived=False...)    # то стоит написать кастомные методы в Manager        data = self.OutputSerializer(orders, many=True).data        return Response(data)

Получается такая схема:

В данном случае слои serializers и views становятся чистыми и правила бизнес-логики концентрируются в одном слое.

Плюсы данного подхода

Следование идеям MVC

Мы отделили логику представления данных от логики предметной области. View только подготавливает данные и вызывает методы модели, все бизнес правила и процессы описаны в методах модели. Данный подход соответствует главной идее MVC.

Легко тестировать

Вся бизнес-логика собрана в одном слое, который не зависит от других слоев, например, от views или serializers. Каждый метод модели можно протестировать по отдельности как обычный python код. Остается только замокать метод save и базовые методы managers или использовать базу данных, если требуется.

Можно переиспользовать

Методы модели можно вызывать из любого компонента, DRF Views, Django Views, Celery задачи и т.д.

Минусы данного подхода

Зависимость от фреймворка

У нас все еще есть зависимость от фреймворка, но это не так критично. Так как отказ от Django models и ORM или их замена очень редкий кейс.

Сложно поддерживать большие проекты

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

Усложнение CRUD проектов

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

Заключение

Мы не нарушили главных идей MVC и наш код соответствует им. Такой подход можно использовать в малых проектах, когда бизнес-логики не много и она умещается в классах моделей.

Слой Services

Мы перебрали все дефолтные слои в Django приложении, теперь можем вспомнить о том, что под слоем Model в MVC подразумевается не один объект, а набор объектов.

Выделим отдельный сервисный слой services внутри слоя Model, который будет отвечать за бизнес-правила предметной области и приложения. В models оставить только простые property, в которых нет сложных бизнес-правил, и методы для работы с собственными данными модели, например обновление полей. Тогда наши кейсы можно реализовать так:

# models.pyclass Order(models.Model):number = serializers.IntegerField()  created = models.DateTimeField(auto_now_add=True)  status = models.CharField(max_length=16)                                               def update_status(self, status: str) -> None:  self.status = status    self.save(update_fields=('status',))...# services.py# вместо пречесления всех аргументов можно реализовать DTOdef order_create(name: str, number: int ...) -> bool:# Проверяем, что все товары есть и заказ валиден  ...  # Создаем запись о заказе в БД  order = Order.objects.create(...)  # Бронируем товары на складе  ...  # Передаем заявку менеджеру (например на почту или создаем какую то запись в БД)  ...  # Оповещаем пользователя  ...# views.pyclass OrderCreateApi(views.APIView):class InputSerializer(serializers.ModelSerializer):  number = serializers.IntegerField()    ...                             def post(self, request):  serializer = self.InputSerializer(data=request.data)    serializer.is_valid(raise_exception=True)      services.order_create(**serializer.validated_data)                 return Response(status=status.HTTP_201_CREATED)

Стоит придерживаться следующему подходу:

• views подготовка данных запроса, вызов бизнес логики, подготовка ответа

• serializers сериализация данных, простая валидация

• services простые функции с бизнес правилами или классы (Service Objects)

• managers содержит в себе правила работы с данными (доступ к данным)

• models единственный окончательный источник правды о анных

Получение заказов пользователя:

# services.pydef order_get_by_user(user: User) -> Iterable[Order]:return Order.objects.filter(user=user)# views.pyclass OrderListApi(views.APIView):class OutputSerializer(serializers.ModelSerializer):  class Meta:    model = Order      fields = ('id', 'number', ...)                            def get(self, request):  orders = services.order_get_by_user(user=request.user)                                             data = self.OutputSerializer(orders, many=True).data                                return Response(data)

Получается такая схема:

Плюсы данного подхода

Следование идеям MVC

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

Легко тестировать

Сервисы представляют собой простые Python функции, которые легко тестировать.

Можно переиспользовать

Мы можем вызывать наши сервисы из любого компонента + можем повторно использовать какие-то сервисы в других проектах.

Легко поддерживать и расширять

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

Гибкость

Существует множество подходов написания и расширения сервисного слоя.

Минусы данного подхода

Зависимость от фреймворка

Доменный слой не отделен от слоя приложения и инфраструктуры. Мы все еще используем Django модели в качестве сущностей. У нас могут возникнуть проблемы, когда мы захотим отказаться от Django ORM, но это очень редкий кейс и для многих проектов неактуален.

Усложнение CRUD проектов

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

Заключение

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

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

Что касается Django, советую обратить внимание на стайл гайд от HackSoftware у них схожие взгляды, но они разделяют сервисный слой на два компонента (services и selectors) и не используют кастомные методы в managers. Подход написания serializers и включения их во views я взял у них. Также стоит посмотреть на идеи ребят из dry-python.

Общий итог

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

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

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

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

Декларативный стиль UI

View modifiers aka decorator

Начиная разработку, мы решили организовать построение UI компонентов как можно более гибко с возможностью собрать из готовых частей что-то прямо на месте.

Для этого мы решили использовать декораторы: они соответствуют нашему представлению о простоте и переиспользуемости кода.

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

public struct ViewDecorator<View: UIView> {    let decoration: (View) -> Void    func decorate(_ view: View) {        decoration(view)    }}public protocol DecoratableView: UIView {}extension DecoratableView {    public init(decorator: ViewDecorator<Self>) {        self.init(frame: .zero)        decorate(with: decorator)    }    @discardableResult    public func decorated(with decorator: ViewDecorator<Self>) -> Self {        decorate(with: decorator)        return self    }    public func decorate(with decorator: ViewDecorator<Self>) {        decorator.decorate(self)        currentDecorators.append(decorator)    }    public func redecorate() {        currentDecorators.forEach {            $0.decorate(self)        }    }}

Почему мы не стали использовать сабклассы:

• Их трудно соединять в цепочки;

• Невозможно отказаться от функциональности родительского класса;

• Нужно описывать отдельно от контекста применения (в отдельном файле)

Декораторы помогли настроить UI компонентов унифицированно и здорово сократили количество кода.

Это также позволило установить связи с дизайн гайдлайнами типовых элементов.

static var headline2: ViewDecorator<View> {    ViewDecorator<View> {        $0.decorated(with: .font(.f2))        $0.decorated(with: .textColor(.c1))    }}

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

private let titleLabel = UILabel()        .decorated(with: .headline2)        .decorated(with: .multiline)        .decorated(with: .alignment(.center))

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

А теперь сравним код с декораторами и без них.

Пример использования декоратора:

private let fancyLabel = UILabel(    decorator: .text("?? ????   ???"))    .decorated(with: .cellTitle)    .decorated(with: .alignment(.center))

Без декораторов аналогичный код выглядел бы примерно так:

private let fancyLabel: UILabel = {   let label = UILabel()   label.text = "???? ? ????"   label.numberOfLines = 0   label.font = .f4   label.textColor = .c1   label.textAlignment = .center   return label}()

Что здесь плохо 9 строк кода против 4. Внимание рассеивается.

Для navigation bar особенно актуально, так как под строчками вида:

navigationController.navigationBar                        .decorated(with: .titleColor(.purple))                        .decorated(with: .transparent)

Скрывается:

static func titleColor(_ color: UIColor) -> ViewDecorator<UINavigationBar> {    ViewDecorator<UINavigationBar> {        let titleTextAttributes: [NSAttributedString.Key: Any] = [            .font: UIFont.f3,            .foregroundColor: color        ]        let largeTitleTextAttributes: [NSAttributedString.Key: Any] = [            .font: UIFont.f1,            .foregroundColor: color        ]        if #available(iOS 13, *) {            $0.modifyAppearance {                $0.titleTextAttributes = titleTextAttributes                $0.largeTitleTextAttributes = largeTitleTextAttributes            }        } else {            $0.titleTextAttributes = titleTextAttributes            $0.largeTitleTextAttributes = largeTitleTextAttributes        }    }}

static var transparent: ViewDecorator<UINavigationBar> {    ViewDecorator<UINavigationBar> {        if #available(iOS 13, *) {            $0.isTranslucent = true            $0.modifyAppearance {                $0.configureWithTransparentBackground()                $0.backgroundColor = .clear                $0.backgroundImage = UIImage()            }        } else {            $0.setBackgroundImage(UIImage(), for: .default)            $0.shadowImage = UIImage()            $0.isTranslucent = true            $0.backgroundColor = .clear        }    }}

Декораторы показали себя хорошим инструментом и помогли нам:

• Улучшить переиспользование кода

• Сократить время разработки

• Через связанность компонентов легко накатывать изменения в дизайне

• Легко настраивать navigation bar через перегрузку свойства с массивом декораторов базового класса экрана

override var navigationBarDecorators: [ViewDecorator<UINavigationBar>] {    [.withoutBottomLine, .fillColor(.c0), .titleColor(.c1)]}

• Сделать код единообразным: не рассеивается внимание, знаешь где что искать.

• Получить контекстно-зависимый код: доступны лишь те декораторы, которые применимы для данного визуального компонента.

HStack, VStack

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

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

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

Сначала используем наиболее актуальную версию констрейнтов - anchors.

[expireDateTitleLabel, expireDateLabel, cvcCodeView].forEach {    view.addSubview($0)    $0.translatesAutoresizingMaskIntoConstraints = false}NSLayoutConstraint.activate([    expireDateTitleLabel.topAnchor.constraint(equalTo: view.topAnchor),    expireDateTitleLabel.leftAnchor.constraint(equalTo: view.leftAnchor),    expireDateLabel.topAnchor.constraint(equalTo: expireDateTitleLabel.bottomAnchor, constant: 2),    expireDateLabel.leftAnchor.constraint(equalTo: view.leftAnchor),    expireDateLabel.bottomAnchor.constraint(equalTo: view.bottomAnchor),    cvcCodeView.leftAnchor.constraint(equalTo: expireDateTitleLabel.rightAnchor, constant: 44),    cvcCodeView.bottomAnchor.constraint(equalTo: view.bottomAnchor),    cvcCodeView.rightAnchor.constraint(equalTo: view.rightAnchor)])

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

let stackView = UIStackView()stackView.alignment = .bottomstackView.axis = .horizontalstackView.layoutMargins = .init(top: 0, left: 16, bottom: 0, right: 16)stackView.isLayoutMarginsRelativeArrangement = truelet expiryDateStack: UIStackView = {    let stackView = UIStackView(        arrangedSubviews: [expireDateTitleLabel, expireDateLabel]    )    stackView.setCustomSpacing(2, after: expireDateTitleLabel)    stackView.axis = .vertical    stackView.layoutMargins = .init(top: 8, left: 0, bottom: 0, right: 0)    stackView.isLayoutMarginsRelativeArrangement = true    return stackView}()let gapView = UIView()gapView.setContentCompressionResistancePriority(.defaultLow, for: .horizontal)gapView.setContentHuggingPriority(.defaultLow, for: .horizontal)stackView.addArrangedSubview(expiryDateStack)stackView.addArrangedSubview(gapView)stackView.addArrangedSubview(cvcCodeView)

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

view.layoutUsing.stack {    $0.hStack(        alignedTo: .bottom,        $0.vStack(            expireDateTitleLabel,            $0.vGap(fixed: 2),            expireDateLabel        ),        $0.hGap(fixed: 44),        cvcCodeView,        $0.hGap()    )}

А так выглядит тот же код, если написать его на SwiftUI

var body: some View {    HStack(alignment: .bottom) {        VStack {            expireDateTitleLabel            Spacer().frame(width: 0, height: 2)            expireDateLabel        }        Spacer().frame(width: 44, height: 0)        cvcCodeView        Spacer()    }}

Коллекции как инструмент построения

Каждый iOS-разработчик знает как неудобно использовать коллекции UITableView и UICollectionView. Надо не забыть зарегистрировать все нужные классы ячеек, проставить делегаты и источники данных. Кроме того, однажды вашей команде может прийти озарение поменять таблицу на коллекцию. Причин для этого масса: невероятные лейауты и кастомные анимированные вставки, свопы и удаления элементов. И вот тогда переписывать придется действительно много.

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

private let listAdapter = VerticalListAdapter<CommonCollectionViewCell>()private let collectionView = UICollectionView(    frame: .zero,    collectionViewLayout: UICollectionViewFlowLayout())

И далее настраиваем основные свойства адаптера.

func setupCollection() {    listAdapter.heightMode = .fixed(height: 8)    listAdapter.setup(collectionView: collectionView)    listAdapter.spacing = Constants.pocketSpacing    listAdapter.onSelectItem = output.didSelectPocket}

И на этом все. Осталось загрузить модели.

listAdapter.reload(items: viewModel.items)

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

В итоге:

• Абстрагировали от конкретной коллекции (UITableView -> UICollectionView).

• Ускорили время построения экранов со списками

• Обеспечили единообразие архитектуры всех экранов, построенных на коллекциях

• На основе адаптера списка разработали адаптер для смеси динамических и статических ячеек

• Уменьшили количество потенциальных ошибок в рантайме, благодаря компайл тайм проверкам дженерик типов ячеек

Состояния экрана.

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

Давайте поговорим более подробно о состоянии загрузки экрана.

Shimmering Views

Отображение состояний загрузки разных экранов в приложении обычно не сильно отличается и требует одних и тех же инструментов. В нашем проекте таким визуальным инструментом стали шиммеры (shimmering views).

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

Также есть возможность кастомизировать лэйаут, выбрав родительскую view, относительно которой будем показывать, а также привязать к различным краям.

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

Поэтому мы создали SkeletonView, в который добавили анимацию градиента:

func makeStripAnimation() -> CAKeyframeAnimation {    let animation = CAKeyframeAnimation(keyPath: "locations")    animation.values = [        Constants.stripGradientStartLocations,        Constants.stripGradientEndLocations    ]    animation.repeatCount = .infinity    animation.isRemovedOnCompletion = false    stripAnimationSettings.apply(to: animation)    return animation}

Основными методами для работы со скелетоном являются показ и скрытие его на экране:

protocol SkeletonDisplayable {...}protocol SkeletonAvailableScreenTrait: UIViewController, SkeletonDisplayable {...}extension SkeletonAvailableScreenTrait {    func showSkeleton(animated: Bool = false) {        addAnimationIfNeeded(isAnimated: animated)        skeletonViewController.view.isHidden = false        skeletonViewController.setLoading(true)    }    func hideSkeleton(animated: Bool = false) {        addAnimationIfNeeded(isAnimated: animated)        skeletonViewController.view.isHidden = true        skeletonViewController.setLoading(false)    }}

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

setupSkeleton()

Smart skeletons

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

Чтобы построить умный скелетон для какого-либо UI компонента требуется знать: список его дочерних компонентов, загрузки данные, которые мы ожидаем, а так же их скелетон-представления:

public protocol SkeletonDrivenLoadableView: UIView {    associatedtype LoadableSubviewID: CaseIterable    typealias SkeletonBone = (view: SkeletonBoneView, excludedPinEdges: [UIRectEdge])    func loadableSubview(for subviewId: LoadableSubviewID) -> UIView    func skeletonBone(for subviewId: LoadableSubviewID) -> SkeletonBone}

Для примера, рассмотрим простенький компонент, состоящий из иконки и лейбла заголовка.

extension ActionButton: SkeletonDrivenLoadableView {    public enum LoadableSubviewID: CaseIterable {        case icon        case title    }    public func loadableSubview(for subviewId: LoadableSubviewID) -> UIView {        switch subviewId {        case .icon:            return solidView        case .title:            return titleLabel        }    }    public func skeletonBone(for subviewId: LoadableSubviewID) -> SkeletonBone {        switch subviewId {        case .icon:            return (ActionButton.iconBoneView, excludedPinEdges: [])        case .title:            return (ActionButton.titleBoneView, excludedPinEdges: [])        }    }}

Теперь мы можем запустить загрузку такого UI компонента с возможностью выбора дочерних элементов для шиммеринга:

actionButton.setLoading(isLoading, shimmering: [.icon])// oractionButton.setLoading(isLoading, shimmering: [.icon, .title])// which is equal toactionButton.setLoading(isLoading)

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

Машина состояний

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

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

Для экрана она выглядит следующим образом:

final class ScreenStateMachine: StateMachine<ScreenState, ScreenEvent> {    public init() {        super.init(state: .initial,           transitions: [               .loadingStarted: [.initial => .loading, .error => .loading],               .errorReceived: [.loading => .error],               .contentReceived: [.loading => .content, .initial => .content]           ])    }}

Ниже мы привели свою реализацию.

class StateMachine<State: Equatable, Event: Hashable> {    public private(set) var state: State {        didSet {            onChangeState?(state)        }    }    private let initialState: State    private let transitions: [Event: [Transition]]    private var onChangeState: ((State) -> Void)?    public func subscribe(onChangeState: @escaping (State) -> Void) {        self.onChangeState = onChangeState        self.onChangeState?(state)    }    @discardableResult    open func processEvent(_ event: Event) -> State {        guard let destination = transitions[event]?.first(where: { $0.source == state })?.destination else {            return state        }        state = destination        return state    }    public func reset() {        state = initialState    }  }

Остается вызвать нужные события, чтобы запустить переход состояний.

func reloadTariffs() {   screenStateMachine.processEvent(.loadingStarted)   interactor.obtainTariffs()}

Если есть состояния, то кто-то должен уметь эти состояния показывать.

protocol ScreenInput: ErrorDisplayable,                      LoadableView,                      SkeletonDisplayable,                      PlaceholderDisplayable,                      ContentDisplayable

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

• Показ ошибок

• Управление загрузкой

• Показ скелетонов

• Показ заглушек с ошибкой и возможностью попытаться снова

• Показ контента

Также для state machine можно реализовать собственные переходы между состояниями:

final class DogStateMachine: StateMachine<ConfirmByCodeResendingState, ConfirmByCodeResendingEvent> {    init() {        super.init(            state: .laying,            transitions: [                .walkCommand: [                    .laying => .walking,                    .eating => .walking,                ],                .seatCommand: [.walking => .sitting],                .bunnyCommand: [                    .laying => .sitting,                    .sitting => .sittingInBunnyPose                ]            ]        )    }}

Трейт экрана с машиной состояний

Хорошо, а как все это связать воедино? Для этого потребуется еще один протокол оркестратор.

public extension ScreenStateMachineTrait {    func setupScreenStateMachine() {        screenStateMachine.subscribe { [weak self] state in            guard let self = self else { return }            switch state {            case .initial:                self.initialStateDisplayableView?.setupInitialState()                self.skeletonDisplayableView?.hideSkeleton(animated: false)                self.placeholderDisplayableView?.setPlaceholderVisible(false)                self.contentDisplayableView?.setContentVisible(false)            case .loading:                self.skeletonDisplayableView?.showSkeleton(animated: true)                self.placeholderDisplayableView?.setPlaceholderVisible(false)                self.contentDisplayableView?.setContentVisible(false)            case .error:                self.skeletonDisplayableView?.hideSkeleton(animated: true)                self.placeholderDisplayableView?.setPlaceholderVisible(true)                self.contentDisplayableView?.setContentVisible(false)            case .content:                self.skeletonDisplayableView?.hideSkeleton(animated: true)                self.placeholderDisplayableView?.setPlaceholderVisible(false)                self.contentDisplayableView?.setContentVisible(true)            }        }    }    private var skeletonDisplayableView: SkeletonDisplayable? {        view as? SkeletonDisplayable    }    // etc.}

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

Отображение ошибок

Еще одной из наиболее часто встречаемых задач является отображение ошибок и обработка реакции пользователя на них.

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

На помощь снова спешат протоколы и трейты.

Для описания представления всех видов ошибок определена единая вьюмодель.

struct ErrorViewModel {    let title: String    let message: String?    let presentationStyle: PresentationStyle}enum PresentationStyle {    case alert    case banner(        interval: TimeInterval = 3.0,        fillColor: UIColor? = nil,        onHide: (() -> Void)? = nil    )    case placeholder(retryable: Bool = true)    case silent}

Дальше мы передаём её в метод протокола ErrorDisplayable:

public protocol ErrorDisplayable: AnyObject {    func showError(_ viewModel: ErrorViewModel)}

public protocol ErrorDisplayableViewTrait: UIViewController, ErrorDisplayable, AlertViewTrait {}

В зависимости от стиля презентации используем конкретный инструмент отображения.

public extension ErrorDisplayableViewTrait {    func showError(_ viewModel: ErrorViewModel) {        switch viewModel.presentationStyle {        case .alert:            // show alert        case let .banner(interval, fillColor, onHide):            // show banner        case let .placeholder(retryable):            // show placeholder        case .silent:            return        }    }}

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

extension APIError: ErrorViewModelConvertible {    public func viewModel(_ presentationStyle: ErrorViewModel.PresentationStyle) -> ErrorViewModel {        .init(            title: Localisation.network_error_title,            message: message,            presentationStyle: presentationStyle        )    }}extension CommonError: ErrorViewModelConvertible {    public func viewModel(_ presentationStyle: ErrorViewModel.PresentationStyle) -> ErrorViewModel {        .init(            title: title,            message: message,            presentationStyle: isSilent ? .silent : presentationStyle        )    }}

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

Занимательные цифры

• Средний размер вьюконтроллера - 196,8934010152 строк

• Средний размер компонента - 138,2207792208 строк

• Время написания экрана - 1 день

• Время написания скрипта для подсчёта этих строк кода ? - 1 час

Выводы

Благодаря нашему подходу к построению UI новые разработчики довольно быстро вливаются в процесс разработки. Есть удобные и простые в использовании инструменты, которые позволяют сократить время, обычно съедаемое рутинными процессами.

Более того, UI остаётся расширяемым и максимально гибким, что позволяет без труда реализовать интерфейс любой сложности, в соответсвии со смелыми замыслами дизайнеров.

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

Еще не может не радовать сильно похудевшая кодовая база. Это мы осветили в занимательных цифрах. А ясное разделение на компоненты и их взаимное расположение не дают запутаться в коде даже самого сложного экрана.

В конце концов, все разработчики немного дети и стремятся получать удовольствие от разработки. И, кажется, нашей команде это удается!

Ваш новый разработчик только что закончил подписывать трудовой договор и с горящими глазами готов закрывать по 15 задач в день. На его пути стоит лишь одно препятствие новый ноутбук, который пока что не настроен должным образом. Чаще всего процесс настройки окружения описывается в документе, который выдается новому разработчику. Мы не сильно далеко ушли и тоже составили такой список.

1. Установка Xcode

2. Настройка локального git репозитория

3. Настройка окружения

4. Настройка проекта

5. Ознакомление с документацией

6. Настройка таск-трекера (Jira/Youtrack)

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

Итак, давайте сперва рассмотрим настройку окружения.

Настройка окружения

В нашем случае настройка окружения состоит из нескольких пунктов:

1. Установка brew зависимостей

2. Установка mint зависимостей

3. Установка и настройка ruby

4. Установка и настройка python

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

Но и тут мы не остановились и решили еще больше облегчить жизнь нового разработчика и написали скрипт, который устанавливает ansible и производит настройку вышеперечисленных пунктов.

В конечном итоге скрипт получился вот таким:

#!/usr/bin/env bashcurl https://bootstrap.pypa.io/get-pip.py -o get-pip.py && sudo python get-pip.pysudo pip install ansiblecd $(dirname $0) && ansible-playbook main.yml

Тут происходит следующее:

1. Установка менеджера пакетов pip

2. Установка Ansible

3. Запуск наших задач из main.yml

Осталось разобраться, что находится в main.yml. А там всего лишь

- hosts: localhost  roles:- common_setup

Здесь hosts отвечает за те машины, на которых мы хотим запустить наши задачи, в нашем случае это локальная машина, а roles содержит информацию о том, какие задачи нужно выполнить, переменные и метаинформацию.

roles ожидает, что файлы будут находиться в определенных папках, в нашем случае иерархия выглядит вот так

Каждая папка (meta, tasks и vars) должна содержать файл main.yml.

Все команды можно уместить в главном main.yml, но подход через roles обеспечивает большую читаемость и модульность.

Больше всего нас интересует папка tasks, в которой собраны задачи, выполняющие настройку. Рассмотрим структуру задачи, которая выполняет установку и настройку Ruby с помощью rvm.

---- name: Check if RVM already installedstat: path=~/.rvmregister: rvmdirchangedwhen: false- name: Install RVM for a usercommand: bash -c "\curl -sSL https://get.rvm.io | bash -s -- --ignore-dotfiles"when: rvmdir.stat.exists == False- name: Add RVM to profilecommand: bash -c "~/.rvm/bin/rvm get stable --auto-dotfiles"when: rvmdir.stat.exists == False- name: Add RVM to zshrccommand: bash -c "echo '\n[ -s ${HOME}/.rvm/scripts/rvm ] && source ${HOME}/.rvm/scripts/rvm' >> ~/.zshrc"when: rvmdir.stat.exists == False- name: Install {{ rubyversion }}command: bash -c "~/.rvm/bin/rvm install {{ rubyversion }}"when: rvmdir.stat.exists == False- name: Set Ruby Defaultcommand: bash -c "~/.rvm/bin/rvm --default use {{ rubyversion }}"when: rvmdir.stat.exists == False- name: Install Ruby Gems required for iOS app developementgem: name={{ item.name }} version={{ item.version }} state={{ if item.version is defined nil else latest }}withitems: "{{ rubygems_packages_to_install }}"when: rvmdir.stat.exists == False

1. Проверяем, установлен ли rvm.

   name - название задачи

   stat - путь до rvm

   register сохраняет переменную для последующего использования

   changed_when переопределяет поведение смены состояния машины после исполнения

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

2. Устанавливаем rvm.

   name - название задачи

   command - команда для выполнения

   when - условие для выполнения

   Условием для выполнения здесь является отсутствие установленного ранее rvm, мы можем узнать это из сохраненной на предыдущем шаге переменной rvmdir.

3. Настраиваем rvm. Параметры аналогичны.

4. Добавляем строки в .zshrc конфиг. На MacOS Catalina этот шаг обязателен, так как zsh теперь используется по умолчанию.

5. Устанавливаем нужную нам для разработки версию Ruby. Тут параметры тоже аналогичны, единственным отличием будет использование нашей переменной из папки vars. Объявлена она в main.yml следующим образом:

   rubyversion: ruby-2.6.5

6. Назначаем свежеустановленную версию Ruby версией по умолчанию

7. Устанавливаем нужные гемы, в нашем случае это просто bundler. Тут также используется переменная из папки vars, объявленная таким образом:

   rubygems_packages_to_install:

   - name: bundler

   version:2.1.4

На этом настройка окружения закончена, можем переходить к настройке самого проекта.

Настройка проекта

Под настройкой проекта мы подразумеваем полную установку всех зависимостей и других необходимых вещей для успешного билда.

Скрипт для настройки проекта выглядит следующим образом:

#!/usr/bin/rubyrequire 'FileUtils'require 'colorize'RESOURCES_DIRECTORY = './Scripts/Resources'.freezeXCODE_DIRECTORY = '~/Library/Developer/Xcode'.freezedef setup_git_hooks  puts "Setting up git hooks".blue.bold  git_hooks_path = '.git/hooks'  FileUtils.mkdir_p(git_hooks_path)  Dir["#{RESOURCES_DIRECTORY}/Git hooks/*"].each do |file|FileUtils.cp_r(file, "#{git_hooks_path}/#{File.basename(file)}")  endenddef setup_file_templates  puts "\nSetting up file templates".blue.bold  file_templates_path = File.expand_path("#{XCODE_DIRECTORY}/Templates/File Templates/Tests")  FileUtils.mkdir_p(file_templates_path)  Dir["#{RESOURCES_DIRECTORY}/Templates/*.xctemplate"].each do |file|FileUtils.cp_r(file, "#{file_templates_path}/#{File.basename(file)}")  endenddef setup_xcode_snippets  puts "\nSetting up xcode snippets".blue.bold  need_to_reboot_xcode = false  code_snippets_path = File.expand_path("#{XCODE_DIRECTORY}/UserData/CodeSnippets")  FileUtils.mkdir_p(code_snippets_path)  Dir["#{RESOURCES_DIRECTORY}/Snippets/*.codesnippet"].each { |file|path = "#{code_snippets_path}/#{File.basename(file)}"next if File.file?(path)need_to_reboot_xcode = trueFileUtils.cp_r(file, path)  }  return unless need_to_reboot_xcode  puts 'Quiting Xcode'.blue  system('killall Xcode')enddef setup_gems  puts "\nSetting up gems".blue.bold  system('bundle install')enddef setup_mocks  puts "\nSetting up mocks".blue.bold  system('cd $(pwd) && swiftymocky generate')enddef setup_projects  puts "\nSetting up projects".blue.bold  system('bundle exec rake update_projects')end# StepsDir.chdir("#{File.expand_path(File.dirname(__FILE__))}/..")setup_git_hookssetup_file_templatessetup_xcode_snippetssetup_gemssetup_mockssetup_projects

Что тут вообще происходит:

1. Настройка гит-хуков. В нашем случае к коммиту всегда прибавляется номер задачи, который берется из названия ветки.

2. Установка темплейтов для генерации модулей.

3. Установка полезных сниппетов.

4. Установка гемов.

5. Генерация моков.

6. Настройка проекта.

Чуть подробнее, пожалуй, стоит остановиться на последнем шаге. В нем мы подтягиваем и кэшируем все нужные Carthage зависимости и генерируем файлы проектов с помощью XcodeGen.

Заключение

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

В итоге мы сэкономили время нового разработчика при онбординге и позволили ему быстрее приступить к задачам. Более того, этими же скриптами мы настраиваем билд-агенты, получая от скриптов двойную пользу.

Введение

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

Копились бесчисленные баги и знания об устройстве этого инструмента и о лучших практиках. И когда мы получили очередной infinite scroll дизайн, мы поняли: пришло время задуматься и дать отпор тирании UITableViewDataSource и UITableViewDelegate.

Почему коллекция?

До сих пор коллекции пребывали в тени, многие побаивались их чрезмерной гибкости или считали их функционал избыточным.

В самом деле, почему бы просто не использовать стек или таблицу? Если для первого мы быстро упремся в низкую производительность, то со вторым в отсутсвие гибкости при реализации лейаута элементов.

Так ли страшны коллекции и какие подводные камни они в себе таят? Мы сравнили.

• Ячейки в таблице содержат лишние элементы: content view, group editing view, slide actions view, accessory view.

• Использование UICollectionView дает единообразность при работе с любыми списками объектов, так как ее API в целом схож с UITableView.

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

Так же у нас были некоторые опасения:

• Возможность использовать Pull to refresh

• Отсутсвие лагов при отрисовке

• Возможность скролла в ячейках

Но в ходе реализации все они развеялись.

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

Адаптеры

Коллекции это, конечно, хорошо, но пробовали ли вы избавиться от привычного боилерплейта с датасорсами и делегатами, чтобы создание экранного списка занимало не больше 10 строк? Для сравнения, вспомним классическую реализацию экрана со списком на UITableView.

final class CurrencyViewController: UIViewController {    var tableView = UITableView()    var items: [ViewModel] = []    func setup() {        tableView.delegate = self        tableView.dataSource = self        tableView.backgroundColor = .white    tableView.rowHeight = 72.0                        tableView.contentInset = .init(top: Constants.topSpacing, left: 0, bottom: Constants.bottomSpacing, right: 0)        tableView.reloadData()    }}extension CurrencyViewController: UITableViewDelegate {    func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) {        output.didSelectBalance(at: indexPath.row)    }}extension CurrencyViewController: UITableViewDataSource {    func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {        items.count    }    func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {                let cell = tableView.dequeueReusable(cell: object.cellClass, at: indexPath)        cell.setup(with: object)                return cell    }}extension UITableView {    func dequeueReusable(cell type: UITableViewCell.Type, at indexPath: IndexPath) -> UITableViewCell {        if let cell: UITableViewCell = self.dequeueReusableCell(withIdentifier: type.name()) {            return cell        }        self.register(cell: type)        let cell: UITableViewCell = self.dequeueReusableCell(withIdentifier: type.name(), for: indexPath)        return cell    }    private func register(cell type: UITableViewCell.Type) {        let identifier: String = type.name()                self.register(type, forCellReuseIdentifier: identifier)     }}

Приходят на помощь джедаи адаптеры.

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

Ниже приведен пример такого использования.

private let listAdapter = CurrencyVerticalListAdapter()private let collectionView = UICollectionView(    frame: .zero,    collectionViewLayout: UICollectionViewFlowLayout())private var viewModel: BalancePickerViewModelfunc setup() {    listAdapter.setup(collectionView: collectionView)    collectionView.backgroundColor = .c0    collectionView.contentInset = .init(top: Constants.topSpacing, left: 0, bottom: Constants.bottomSpacing, right: 0)    listAdapter.onSelectItem = output.didSelectBalance    listAdapter.heightMode = .fixed(height: 72.0)    listAdapter.spacing = 8.0    listAdapter.reload(items: viewModel.items)}

Однако внутри адаптер представляет собой даже не один класс.

Рассмотрим для начала базовый (и вообще говоря абстрактный) класс адаптера списков:

public class ListAdapter<Cell> : NSObject, ListAdapterInput, UICollectionViewDataSource, UICollectionViewDelegate, UICollectionViewDragDelegate, UICollectionViewDropDelegate, UIScrollViewDelegate where Cell : UICollectionViewCell, Cell : DesignKit.AnimatedConfigurableView, Cell : DesignKit.RegistrableView {    public typealias Model = Cell.Model    public typealias ResizeCallback = (_ insertions: [Int], _ removals: [Int], _ skipNext: Bool) -> Void    public typealias SelectionCallback = ((Int) -> Void)?    public typealias ReadyCallback = () -> Void    public enum DragAndDropStyle {        case reorder        case none    }    public var dragAndDropStyle: DragAndDropStyle { get set }    internal var headerModel: ListHeaderView.Model?    public var spacing: CGFloat    public var itemSizeCacher: UICollectionItemSizeCaching?    public var onSelectItem: ((Int) -> Void)?    public var onDeselectItem: ((Int) -> Void)?    public var onWillDisplayCell: ((Cell) -> Void)?    public var onDidEndDisplayingCell: ((Cell) -> Void)?    public var onDidScroll: ((CGPoint) -> Void)?    public var onDidEndDragging: ((CGPoint) -> Void)?    public var onWillBeginDragging: (() -> Void)?    public var onDidEndDecelerating: (() -> Void)?    public var onDidEndScrollingAnimation: (() -> Void)?    public var onReorderIndexes: (((Int, Int)) -> Void)?    public var onWillBeginReorder: ((IndexPath) -> Void)?    public var onReorderEnter: (() -> Void)?    public var onReorderExit: (() -> Void)?    internal func subscribe(_ subscriber: AnyObject, onResize: @escaping ResizeCallback)    internal func unsubscribe(fromResize subscriber: AnyObject)    internal func subscribe(_ subscriber: AnyObject, onReady: @escaping ReadyCallback)    internal func unsubscribe(fromReady subscriber: AnyObject)    internal weak var collectionView: UICollectionView?    public internal(set) var items: [Model] { get set }    public func setup(collectionView: UICollectionView)    public func setHeader(_ model: ListHeaderView.Model)    public subscript(index: Int) -> Model? { get }    public func reload(items: [Model], needsRedraw: Bool = true)    public func insertItem(_ item: Model, at index: Int, allowDynamicModification: Bool = true)    public func appendItem(_ item: Model, allowDynamicModification: Bool = true)    public func deleteItem(at index: Int, allowDynamicModification: Bool = true)    public func deleteItemsIfNeeded(at range: PartialRangeFrom<Int>)    public func deleteItems(at indexes: [Int], allowDynamicModification: Bool = true)    public func updateItem(_ item: Model, at index: Int, allowDynamicModification: Bool = true)    public func reloadItems(_ newItems: [Model], at range: PartialRangeFrom<Int>, allowDynamicModification: Bool = true)    public func reloadItems(_ newItems: [Model], at indexes: [Int], allowDynamicModification: Bool = true)    public func reloadItems(_ newItems: [(index: Int, element: Model)], allowDynamicModification: Bool = true)    public func moveItem(at index: Int, to newIndex: Int)    public func performBatchUpdates(updates: @escaping (ListAdapter) -> Void, completion: ((Bool) -> Void)?)    public func performBatchUpdates(updates: () -> Void, completion: ((Bool) -> Void)?)    }public typealias ListAdapterCellConstraints = UICollectionViewCell & RegistrableView & AnimatedConfigurableViewpublic typealias VerticalListAdapterCellConstraints = ListAdapterCellConstraints & HeightMeasurableViewpublic typealias HorizontalListAdapterCellConstraints = ListAdapterCellConstraints & WidthMeasurableView

Таким образом, внутри конкретного экрана нужно выполнить только минимальную настройку. Благодаря этому код станет проще для восприятия.

Как можно увидеть из примера выше: сначала идёт блок typealias'ов для того, чтобы определить ограничения на используемые типы.

DragAndDropStyle отвечает за возможность менять местами ячейки внутри коллекции.

headerModel - модель, которая представляет заголовок коллекции

spacing - расстояние между элементами

Дальше идёт блок замыканий, которые позволяют подписаться на определённые изменения в коллекции.

Методы для подписки onReady и onResize позволяют понять, когда коллекция адаптера стала готова к работе, и когда изменился размер коллекции из-за добавления или удаления объектов, соответственно.

collectionView, setup(collectionView:) - непосредственно используемый экземпляр коллекции и метод для её установки

items - набор моделей для отображения

setHeader - метод для установки заголовка коллекции

itemSizeCacher - класс, реализующий кеширование размеров элементов списка. Дефолтная реализация представлена ниже:

final class DefaultItemSizeCacher: UICollectionItemSizeCaching {        private var sizeCache: [IndexPath: CGSize] = [:]        func itemSize(cachedAt indexPath: IndexPath) -> CGSize? {        sizeCache[indexPath]    }        func cache(itemSize: CGSize, at indexPath: IndexPath) {        sizeCache[indexPath] = itemSize    }        func invalidateItemSizeCache(at indexPath: IndexPath) {        sizeCache[indexPath] = nil    }        func invalidate() {        sizeCache = [:]    }    }

Остальную часть интерфейса представляют методы для обновления элементов.

Также есть конкретные реализации, которые, например, заточены под определенное расположение ячеек по оси.

AnyListAdapter

До тех пор, пока мы работаем с динамическим контентом, все хорошо. Но во введении мы не зря говорили про infinite-scroll дизайн. Что делать, если в таблице нужно одновременно отображать и ячейки динамического контента(данные из сети) и статические вью? Для этого нам послужит AnyListAdapter.

public typealias AnyListSliceAdapter = ListSliceAdapter<AnyListCell>public final class AnyListAdapter : ListAdapter<AnyListCell>, UICollectionViewDelegateFlowLayout {    public var dimensionCalculationMode: DesignKit.AnyListAdapter.DimensionCalculationMode    public let axis: Axis    public init<Cell>(dynamicCellType: Cell.Type) where Cell : UICollectionViewCell, Cell : DesignKit.AnimatedConfigurableView, Cell : DesignKit.HeightMeasurableView, Cell : DesignKit.RegistrableView    public init<Cell>(dynamicCellType: Cell.Type) where Cell : UICollectionViewCell, Cell : DesignKit.AnimatedConfigurableView, Cell : DesignKit.RegistrableView, Cell : DesignKit.WidthMeasurableView}public extension AnyListAdapter {    convenience public init<C1, C2>(dynamicCellTypes: (C1.Type, C2.Type)) where C1 : UICollectionViewCell, C1 : DesignKit.AnimatedConfigurableView, C1 : DesignKit.HeightMeasurableView, C1 : DesignKit.RegistrableView, C2 : UICollectionViewCell, C2 : DesignKit.AnimatedConfigurableView, C2 : DesignKit.HeightMeasurableView, C2 : DesignKit.RegistrableView    convenience public init<C1, C2, C3>(dynamicCellTypes: (C1.Type, C2.Type, C3.Type)) where C1 : UICollectionViewCell, C1 : DesignKit.AnimatedConfigurableView, C1 : DesignKit.HeightMeasurableView, C1 : DesignKit.RegistrableView, C2 : UICollectionViewCell, C2 : DesignKit.AnimatedConfigurableView, C2 : DesignKit.HeightMeasurableView, C2 : DesignKit.RegistrableView, C3 : UICollectionViewCell, C3 : DesignKit.AnimatedConfigurableView, C3 : DesignKit.HeightMeasurableView, C3 : DesignKit.RegistrableView    convenience public init<C1, C2>(dynamicCellTypes: (C1.Type, C2.Type)) where C1 : UICollectionViewCell, C1 : DesignKit.AnimatedConfigurableView, C1 : DesignKit.RegistrableView, C1 : DesignKit.WidthMeasurableView, C2 : UICollectionViewCell, C2 : DesignKit.AnimatedConfigurableView, C2 : DesignKit.RegistrableView, C2 : DesignKit.WidthMeasurableView    convenience public init<C1, C2, C3>(dynamicCellTypes: (C1.Type, C2.Type, C3.Type)) where C1 : UICollectionViewCell, C1 : DesignKit.AnimatedConfigurableView, C1 : DesignKit.RegistrableView, C1 : DesignKit.WidthMeasurableView, C2 : UICollectionViewCell, C2 : DesignKit.AnimatedConfigurableView, C2 : DesignKit.RegistrableView, C2 : DesignKit.WidthMeasurableView, C3 : UICollectionViewCell, C3 : DesignKit.AnimatedConfigurableView, C3 : DesignKit.RegistrableView, C3 : DesignKit.WidthMeasurableView}public extension AnyListAdapter {    public enum Axis {        case horizontal        case vertical    }    public enum DimensionCalculationMode {        case automatic        case fixed(constant: CGFloat? = nil)    }}

Как не трудно догадаться, AnyListAdapter абстрагируется от конкретного типа ячейки. Его можно проинициализировать несколькими типами ячеек, но они все должны быть либо для горизонтального лейаута, либо вертикального. Условием здесь выступает удовлетворение протоколу HeightMeasurableView и WidthMeasurableView.

public protocol HeightMeasurableView where Self: ConfigurableView {    static func calculateHeight(model: Model, width: CGFloat) -> CGFloat    func measureHeight(model: Model, width: CGFloat) -> CGFloat   }public protocol WidthMeasurableView where Self: ConfigurableView {    static func calculateWidth(model: Model, height: CGFloat) -> CGFloat    func measureWidth(model: Model, height: CGFloat) -> CGFloat}

У списка так же фиксируется алгоритм подсчета высоты:

• фиксированный(константа или статический метод расчета по модели)

• автоматический (на основе лейаута).

Сила вся внутри ячейки-контейнера AnyListCell спрятана.

public class AnyListCell: ListAdapterCellConstraints {        // MARK: - ConfigurableView        public enum Model {        case `static`(UIView)        case `dynamic`(DynamicModel)    }        public func configure(model: Model, animated: Bool, completion: (() -> Void)?) {        switch model {        case let .static(view):            guard !contentView.subviews.contains(view) else { return }                        clearSubviews()            contentView.addSubview(view)            view.layout {                $0.pin(to: contentView)            }        case let .dynamic(model):            model.configure(cell: self)        }        completion?()    }        // MARK: - RegistrableView        public static var registrationMethod: ViewRegistrationMethod = .class        public override func prepareForReuse() {        super.prepareForReuse()                clearSubviews()    }        private func clearSubviews() {        contentView.subviews.forEach {            $0.removeFromSuperview()        }    }    }

Такая ячейка конфигурируется двумя видами модели: статической и динамической.

Первая как раз отвечает за отображение в списке обычных вью.

Вторая же оборачивает в себя модель, конфигуратор и подсчет высоты, стирая при этом сам тип ячейки. В действительности отсюда и префикс в названии как ячейки, так и самого адаптера: Any.

struct DynamicModel {    public init<Cell>(model: Cell.Model,                    cell: Cell.Type) {            // ...    }    func dequeueReusableCell(from collectionView: UICollectionView, for indexPath: IndexPath) -> UICollectionViewCell    func configure(cell: UICollectionViewCell)    func calcucalteDimension(otherDimension: CGFloat) -> CGFloat    func measureDimension(otherDimension: CGFloat) -> CGFloat}

Ниже приведён пример наполнения списка результатов поиска разного рода данными: теги, операции и плейсхолдер для индикации отсутствия элементов.

private let listAdapter = AnyListAdapter(    dynamicCellTypes: (CommonCollectionViewCell.self, OperationCell.self))func configureSearchResults(with model: OperationsSearchViewModel) {    var items: [AnyListCell.Model] = []    model.sections.forEach {        let header = VerticalSectionHeaderView().configured(with: $0.header)        items.append(.static(header))        switch $0 {        case .tags(nil), .operations(nil):            items.append(                .static(OperationsNoResultsView().configured(with: Localisation.feed_search_no_results))            )        case let .tags(models?):            items.append(                contentsOf: models.map {                    .dynamic(.init(                        model: $0,                        cell: CommonCollectionViewCell.self                    ))                }            )        case .operations(let models?):            items.append(                contentsOf: models.map {                    .dynamic(.init(                        model: $0,                        cell: OperationCell.self                    ))                }            )        }    }    UIView.performWithoutAnimation {        listAdapter.deleteItemsIfNeeded(at: 0...)        listAdapter.reloadItems(items, at: 0...)    }}

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

Список по кускам

Только что мы рассмотрели экран, который натуральным образом поделен на секции. Возникает вопрос, на сколько удобно работать с секциями в плане индексации.

Сам по себе AnyListAdapter не дает удобного решения. Очень легко наткнуться на NSInternalInconsistencyException или удалить элемент не из той секции. Поиск причины этой ошибки может занять время.

Для того, чтобы обезопасить себя при работе с вставкой/удалением/обновлением элементов, мы используем концепцию слайсов по аналогии с ArraySlice, представленным в стандартной библиотеке языка Swift.

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

Приведем пример сложного экрана.

let subjectsSectionHeader = SectionHeaderView(title: "Subjects")let pocketsSectionHeader = SectionHeaderView(title: "Pockets")let cardsSectionHeader = SectionHeaderView(title: "Cards")let categoriesHeader = SectionHeaderView(title: "Categories")let list = AnyListAdapter()listAdapter.reloadItems([    .static(subjectsSectionHeader),    .static(pocketsSectionHeader)    .static(cardsSectionHeader),    .static(categoriesHeader)])

Теперь распределим эти секции по контроллерам. Для простоты рассмотрим лишь один, так как остальные будут похожими на него.

class PocketsViewController: UIViewController {    var listAdapter: AnyListSliceAdapter! {        didSet {reload()        }    }    var pocketsService = PocketsService()    func reload() {        pocketsService.fetch { pockets, error in            guard let pocket = pockets else { return }            listAdapter.reloadItems(                pockets.map { .dynamic(.init(model: $0, cell: PocketCell.self)) },                at: 1...            )        }    }    func didTapRemoveButton(at index: Int) {listAdapter.deleteItemsIfNeeded(at: index)    }}let subjectsVC = PocketsViewController()subjectsVC.listAdapter = list[1..<2]

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

public extension ListAdapter {    subscript(range: Range<Int>) -> ListSliceAdapter<Cell> {        .init(listAdapter: self, range: range)    }    init(listAdapter: ListAdapter<Cell>,               range: Range<Int>) {        self.listAdapter = listAdapter        self.sliceRange = range        let updateSliceRange: ([Int], [Int], Bool) -> Void = { [unowned self] insertions, removals, skipNextResize in            self.handleParentListChanges(insertions: insertions, removals: removals)            self.skipNextResize = skipNextResize        }        let enableWorkingWithSlice = { [weak self] in            self?.onReady?()            return        }        listAdapter.subscribe(self, onResize: updateSliceRange)        listAdapter.subscribe(self, onReady: enableWorkingWithSlice)    }}

Теперь работать с секцией списка можно ничего не зная об оригинальном списке и не беспокоясь о правильности индексации.

Кроме данных о рендже слайса, интерфейс слайс адаптера мало чем отличается от оригинального ListAdapter.

public final class ListSliceAdapter<Cell> : ListAdapterInput where Cell : UICollectionViewCell, Cell : ConfigurableView, Cell : RegistrableView {    public var items: [Model] { get }    public var onReady: (() -> Void)?    internal private(set) var sliceRange: Range<Int> { get set }    internal init(listAdapter: ListAdapter<Cell>, range: Range<Int>)    convenience internal init(listAdapter: ListAdapter<Cell>, index: Int)    public subscript(index: Int) -> Model? { get }    public func reload(items: [Model], needsRedraw: Bool = true)    public func insertItem(_ item: Model, at index: Int, allowDynamicModification: Bool = true)    public func appendItem(_ item: Model, allowDynamicModification: Bool = true)    public func deleteItem(at index: Int, allowDynamicModification: Bool = true)    public func deleteItemsIfNeeded(at range: PartialRangeFrom<Int>)    public func deleteItems(at indexes: [Int], allowDynamicModification: Bool = true)    public func updateItem(_ item: Model, at index: Int, allowDynamicModification: Bool = true)    public func reloadItems(_ newItems: [Model], at range: PartialRangeFrom<Int>, allowDynamicModification: Bool = true)    public func reloadItems(_ newItems: [Model], at indexes: [Int], allowDynamicModification: Bool = true)    public func reloadItems(_ newItems: [(index: Int, element: Model)], allowDynamicModification: Bool = true)    public func moveItem(at index: Int, to newIndex: Int)    public func performBatchUpdates(updates: () -> Void, completion: ((Bool) -> Void)?)}

Нетрудно догадаться, что внутри проксирующих методов происходит математика индексов.

public func deleteItemsIfNeeded(at range: PartialRangeFrom<Int>) {    guard canDelete(index: range.lowerBound) else { return }    let start = globalIndex(of: range.lowerBound)    let end = sliceRange.upperBound - 1    listAdapter.deleteItems(at: Array(start...end))}

При этом ключевую роль играет поддержка кусков внутри самого ListAdapter.

public class ListAdapter {    // ...    var resizeSubscribers = NSMapTable<AnyObject, NSObjectWrapper<ResizeCallback>>.weakToStrongObjects()}extension ListAdapter {public func appendItem(_ item: Model) {        let index = items.count               let changes = {            self.items.append(item)            self.handleSizeChange(insert: self.items.endIndex)            self.collectionView?.insertItems(at: [IndexPath(item: index, section: 0)])        }                if #available(iOS 13, *) {            changes()        } else {            performBatchUpdates(updates: changes, completion: nil)        }    }    func handleSizeChange(removal index: Int) {        notifyAboutResize(removals: [index])    }    func handleSizeChange(insert index: Int) {        notifyAboutResize(insertions: [index])    }    func notifyAboutResize(insertions: [Int] = [], removals: [Int] = [], skipNextResize: Bool = false) {        resizeSubscribers            .objectEnumerator()?            .allObjects            .forEach {                ($0 as? NSObjectWrapper<ResizeCallback>)?.object(insertions, removals, skipNextResize)            }    }    func shiftSubscribers(after index: Int, by shiftCount: Int) {        guard shiftCount > 0 else { return }        notifyAboutResize(            insertions: Array(repeating: index, count: shiftCount),            skipNextResize: true        )    }}

То есть при каждом добавлении и удалении элемента из исходного списка мы уведомляем всех подписчиков твиттера совета джедаев об изменении размера коллекции.

Выводы

Не помешает убедиться, что все это было не зря, поэтому освежим в памяти полученные бенифиты. Во-первых, мы получили единый интерфейс для разных видов списков. В том числе с разным лейаутом: горизонтальный и вертикальный. Если под капотом нас вдруг не устроит производительность (или баги новой iOS) у UICollectionView, то легко сможем поддержать тот же протокол и для таблиц.

И, что для ленивых самое важное - сетап экрана со списком занимает меньше 10 строк кода.

Если мы раньше боялись усложнять экран работой с таблицей для отображения разнородных данных, то сейчас смело пишем каждый третий экран( ~30%) на списках, вооружившись одним из нашего обширного арсенала адаптеров. А если хотите в модульную декомпозицию - то к вашим услугам адаптеры для куска списка.

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

Привет, Хабр!

В прошлой статье мы разобрались:

• Что такое ui-тесты и для чего они нужны;

• Как настроить окружение для тестов;

• Как находить ui-элементы в проекте и проставлять им accessibilityidentifier.

В этой статье мы разберем:

1. Как обращаться и инициализировать ui-элементы в ваших тестах;

2. Как взаимодействовать с ui-элементами приложения;

3. Как писать ассерты для проверки в автотесте ожидаемого результата.

Как обращаться и инициализировать ui-элементы

При наличии айдишника у ui-элемента, достаточно указать его при обращении.

XCUIApplication().buttons["Help"]

Если же у вас нет id у элемента, есть способ найти его при помощи XCUIElementQuery. Этот класс позволяет искать элемент несколькими способами.

// Находит все кнопки внутри scroll view (отобразит кнопки только прямого потомка scroll view)XCUIApplication().scrollViews["Main"].children(matching: .button)// Находит все кнопки внутри scroll view (отобразит кнопки прямого потомка scroll view, но также и его потомков)XCUIApplication().scrollViews["Main"].descendants(matching: .button)    // Находит четвертую кнопку на экранеXCUIApplication().buttons.element(boundBy: 3)// Находит в scroll view ui-элемент содержащий label = identifierXCUIApplication().scrollViews["Main"].containing(NSPredicate(format: "label == %@","identifier").element// Находит первую кнопку на экранеXCUIApplication().buttons.firstMatch

Немного про NSPredicate это класс, который позволяет фильтровать объекты по нужному вам условию. Статья с хорошим объяснением как использовать NSPredicate.

Пример иницилизации переменной:

let moneyTitle: XCUIElement = XCUIApplication().staticTexts["accessibilityID"]

Взаимодействия с ui-элементами приложения

Нажатие и удержание

Вы можете в своих тестах совершать: нажатие, удержание и drag&drop ui-элементов.

Перечень методов можно посмотреть здесь, раздел Tapping and Pressing.

// Совершаем нажатие на ui-элементXCUIApplication().buttons.element.tap()// Cовершаем двойное нажатие на ui-элементXCUIApplication().buttons.element.doubleTap()// Удерживаем нажатие в течение времени, которое передали в forDurationXCUIApplication().buttons.element.press(forDuration: 3)// Совершаем нажатие на ui-элемент и затем перетаскиваем его к другому ui-элементуXCUIApplication().buttons.element.press(forDuration: 3, thenDragTo: XCUIApplication().searchFields.element)

Ввод текста

Вы можете вводить текст по букве обращаясь к системной клавиатуре:

XCUIApplication().textFields.element.tap()XCUIApplication().keys["h"].tap()XCUIApplication().keys["e"].tap()XCUIApplication().keys["l"].tap()XCUIApplication().keys["p"].tap()

Либо вводить целую строку:

XCUIApplication().textFields.element.typeText("help")

Информация по методу typeText

Множественные нажатия

Вы можете совершать множественные нажатия в своих тестах.

// Совершаем нажатие двумя пальцами на ui-элементXCUIApplication().buttons.element.twoFingerTap()/*     Совершаем нажатие на элемент столько раз сколько передали     в withNumberOfTaps и столькими "пальцами" сколько передали     в numberOfTouches*/XCUIApplication().buttons.element.tap(withNumberOfTaps: 1, numberOfTouches: 1)

Перечень методов можно посмотреть здесь, раздел Multiple Taps.

Жесты

Вы можете совершать разные жесты в своих тестах.

// Совершаем свайп в указанном направленииswipeLeft()swipeRight()swipeUp()swipeDown()// Совершаем свайп в указанном направлении с заданной скоростьюswipeLeft(velocity: 0.5)swipeRight(velocity: 0.5)swipeUp(velocity: 0.5)swipeDown(velocity: 0.5)// Совершаем приближения ui-элемента (withScale указываем больше 1)XCUIApplication().images.element(boundBy: 0).pinch(withScale: 2, velocity: 1) // Совершаем отдаления ui-элемента (withScale указываем от 0 до 1)XCUIApplication().images.element(boundBy: 0).pinch(withScale: 0.5, velocity: 1)// Совершаем вращение ui-элементаXCUIApplication().images.element(boundBy: 0).rotate(0.5, withVelocity: 0.5)

Перечень методов можно посмотреть здесь, раздел Performing Gestures.

Взаимодействие с UISlider

UISlider это элемент управления для выбора одного значения из диапазона значений.

Когда мы хотим изменить положение ползунка в слайдере, мы не передаем значение, которое хотим установить. Вместо этого мы выбираем число в диапазоне от 0 до 1. Где 0 это минимальное значение в слайдере, а 1 максимальное. Представим, что у нас есть слайдер с максимальным значением 100 и нам нужно сдвинуть ползунок на значение 25. Это будет выглядеть так:

XCUIApplication().sliders.element.adjust(toNormalizedSliderPosition: 0.25)

Взаимодействие с UIPickerView и UIDatePicker

UIPickerView и UIDatePicker это ui-элементы, которые используют "колесики" для выбора необходимых значений.

XCUIElement имеет специальный метод для взаимодействия с UIPickerView и UIDatePicker:

• Для пикеров с одним колесом, мы можем получить доступ через element(), и указать значение, которое хотим выбрать;

• Для пикеров с несколькими колесами, мы можем обратиться к нужному колесу по индексу и указать значение, которое хотим выбрать.

// Пикер с одним колесомXCUIApplication().pickerWheels.element.adjust(toPickerWheelValue: "BMW")// Пикер с несколькими колесамиXCUIApplication().pickerWheels.elementBoundByIndex(0).adjust(toPickerWheelValue: "BMW")XCUIApplication().pickerWheels.elementBoundByIndex(1).adjust(toPickerWheelValue: "X6")

Взаимодействие с системным алертом

Системный алерт это объект, отображающий предупреждающее сообщение для пользователя.

Чтобы взаимодействовать с ним, вам понадобится использовать метод addUIInterruptionMonitor(withDescription:handler:)

Где вы передаете:

• withDescription заголовок алерта;

• handler - действие, которое хотите совершить.

Пример использования в тестах:

addUIInterruptionMonitor(withDescription: "Current Location Not Available") { alert in    alert.buttons["OK"].tap()    return true}

Взаимодействие с Navigation Bar

Navigation bar это панель навигации, отображается в верхней части экрана приложения под status bar и позволяет перемещаться по приложению.

Представим, что у нас есть две кнопки и текст по середине в Navigation Bar.

Вот пример того как можно их иницилизировать и в дальнейшем с ними взаимодействовать:

// Иницилизируем крайнюю левую кнопку в Navigation bar let leftNavBarButton = XCUIApplication().navigationBars.children(matching: .button).firstMatch// Иницилизируем тест посередине в Navigation bar let topicNavBar = XCUIApplication().navigationBars.children(matching: .staticTexts).firstMatch// Иницилизируем крайнюю правую кнопку в Navigation barlet rightNavBarButton = XCUIApplication().navigationBars.children(matching: .button).element(boundBy: 1)// Нажимаем на кнопки в Navigation bar leftNavBarButton.tap()rightNavBarButton.tap()// Проверяем заголовок в Navigation bar XCTAssertEqual(topicNavBar.title, "Topic")

Взаимодействие с Tab bar

Tab bar это панель вкладок, отображается в нижней части экрана приложения. Она даёт возможность быстро переключаться между различными разделами приложения.

Для переключения между вкладками достаточно тапать на индекс элемента в Tab bar.

// Открываем первую вкладку XCUIApplication().tabBars.buttons.element(boundBy: 0)// Открываем третью вкладкуXCUIApplication().tabBars.buttons.element(boundBy: 2)

Создание ассертов:

Ассерты это проверки необходимого условия.

Рассмотрим несколько вариантов их использования:

// Ассерт, что кнопка отображается на экранеXCTAssertTrue(XCUIApplication().buttons["Warning"].exists)// Ассерт, что кнопка не выделенаXCTAssertFalse(XCUIApplication().buttons["Warning"].isSelected)// Ассерт, что title кнопки равен - BuyXCTAssertEqual(XCUIApplication().buttons.element.title, "Buy")// Ассерт, что placeholder в textFields не равен - placeHolderXCTAssertNotEqual(XCUIApplication().textFields.element.placeholderValue, "placeHolder")// Ассерт, что value в textFields равно - valueXCTAssertEqual(XCUIApplication().textFields.element.value, "value")

Полный перечень возможных ассертов можно посмотреть здесь, раздел Test Assertions

Перечень возможных атрибутов ui-элементов можно посмотреть здесь

Заключение:

Взаимодействовать с ui-элементами во время теста не так сложно, как кажется на первый взгляд. Воспользовавшись примерами выше, можно быстро добавить необходимые методы в свой проект с ui-тестами.

В следующей статье мы расскажем про жизненый цикл тестового приложения:

• Как делать предусловия и послеусловия;

• Как сбрасывать статус пермишенов приложения перед запуском тестов (доступ к галерее, фото и так далее);

• Как запускать приложения по bundle identifier (например запуск сафари, документов и так далее);

• И многое другое.

Умение разбираться с нестабильными тестами критически важно в тестировании, потому что автотесты с плавающими результатами замедляют скорость всей разработки.

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

Данная статья призвана рассказать как бороться с каждой из причин.

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

• Сами тесты;

• Фреймворк для запуска тестов;

• Сервисы и библиотеки, от которых зависит тестируемая система и тестовый фреймворк;

• Операционная система и устройство с которым взаимодействует фреймворк автотестирования.

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

Однако в распределенной системе каждая служба приложения и службы, от которых она зависит, могут находиться в другом аппаратном / программном стеке, как и служба, выполняющая тест. Это проиллюстрировано на рисунке 2 как полная среда выполнения теста

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

Сами тесты

Сами тесты могут вызвать нестабильность. Типичные причины:

• Неправильная инциализация или очистка;

• Неправильно подобранные тестовые данные;

• Неправильное предположение о состоянии системы. Примером может служить системное время;

• Зависимость от асинхроных действий;

• Зависимость от порядка запуска тестов.

Фреймворк для запуска тестов

Ненадежный фреймворк для запуска тестов может привести к нестабильности. Типичные причины:

• Неспособность выделить достаточно ресурсов для тестируемой системы, что приводит к ее сбою;

• Неправильное планирование тестов, поэтому они "противоречат" и приводят к сбою друг друга;

• Недостаточно системных ресурсов для выполнения требований тестирования.

Сервисы и библиотеки, от которых зависит тестируемая система и тестовый фреймворк

Приложение (или тестируемая система) может быть источником нестабильности

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

В этой цепочки каждый сервис может послужить причиной возникновения нестабильных тестов.

Типичные причины:

• Состояние гонки;

• Непроинициализированные переменные;

• Медленный ответ или отсутствие ответа при запросе от теста;

• Утечки памяти;

• Избыточная подписка на ресурсы;

• Изменения в приложении и в тестах происходят с разной скоростью.

Среды тестирования называются герметичными, если они содержат всё, что необходимо для запуска тестов (т.е. нет внешних зависимостей, таких как серверы, работающие в прод окружении).

Герметичная среда менее подвержена нестабильности.

Операционная система и устройство с которым взаимодействует фреймворк автотестирования

Наконец, оборудование и операционная система могут быть источником нестабильности тестов. Типичные причины включают:

• Сбои или нестабильность сети;

• Дисковые ошибки;

• Ресурсы, потребляемые другими задачами / службами, не связанными с выполняемыми тестами.

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

В следующих статьях мы рассмотрим способы решения этих проблем.

Ссылки на источники

• Откуда берутся нестабильные тесты? (оригинал/ перевод статьи на хабре)

• Нестабильные тесты в Google и как мы их исправляем (оригинал)

• Мои тесты на Selenium не стабильны! (оригинал)

• Избегайте нестабильных тестов (оригинал)

Это продолжение серии статей о нестабильных тестах.

В первой статье(оригинал/перевод на хабре) говорилось о 4 компонентах, в которых могут возникать нестабильные тесты.

В этой статье дадим советы как избежать нестабильных тестов в каждом из 4 компонентов.

Компоненты

Итак 4 компонента в которых могут возникать нестабильные тесты:

• Сами тесты;

• Фреймворк для запуска тестов;

• Сервисы и библиотеки, от которых зависит тестируемая система и тестовый фреймворк;

• Операционная система и устройство с которым взаимодействует фреймворк автотестирования.

Это отображено на рисунке 1.

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

Сами тесты

Сами тесты могут быть нестабильными.

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

Таблица 1 Причины, варианты локализации проблемы и варианты решения нестабильности в самих тестах.

Фреймворк для запуска тестов

Ненадежный фреймворк для запуска тестов может привести к нестабильности

Таблица 2 Причины, варианта локализации проблемы, и варианты решения нестабильности в фреймворке для запуска тестов

Сервисы и библиотеки, от которых зависит тестируемая система и тестовый фреймворк

Приложение (или тестируемая система) может быть источником нестабильности.

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

В этой цепочки каждый сервис может послужить причиной возникновения нестабильных тестов.

Таблица 3 Причины, варианта локализации проблемы, и варианты решения нестабильности в приложении или тестируемой системе

Операционная система и устройство с которым взаимодействует фреймворк автотестирования

Наконец, оборудование и операционная система могут быть источником нестабильности тестов.

Таблица 4 Причины, варианта локализации проблемы, и варианты решения нестабильности в ОС и устройстве с которым взаимодействует фреймворк автотестирования

Заключение

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

Ссылки на источники

• Откуда берутся нестабильные тесты? (оригинал/ перевод статьи на хабре)

• Нестабильные тесты в Google и как мы их исправляем (оригинал)

• Мои тесты на Selenium не стабильны! (оригинал)

• Избегайте нестабильных тестов (оригинал)

• Нестабильные тесты одна из основных проблем автоматизированного тестирования(оригинал/ перевод статьи на хабре)

Кукусики!

Меня зовут Юля, и я Mobile QA в компании Vivid Money.

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

В этой статье я расскажу, КАК ОБЛЕГЧИТЬ ЖИЗНЬ ТЕСТИРОВЩИКУ ВО ВРЕМЯ РЕГРЕССА!

Расскажу по порядку:

1. Наши процессы (для полноты картины)

2. Основную проблему

3. Анализ

4. Методы решения, с полученными результатами

Немного о наших процессах

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

Регрессионное тестирование это набор тестов, направленных на обнаружение дефектов в уже протестированных, но затронутых изменениями, участках приложения.

Практически все позитивные сценарии проверки покрыты тест кейсами, которые ведутся в Allure TestOps.

У каждой платформы (я имею ввиду iOS, Android) своя документация и автотесты, но все хранится в одном месте. Любой QA из команды может посмотреть и отредактировать их. Если добавляются новые кейсы, то они обязательно проходят ревью. Тестировщик Android проводит ревью для iOS, и наоборот. Это актуально для ручных тестов.

Про тест план для регресса:

Для проведения регрессионного тестирования, составляется тест план с ручными тест кейсами и автотестами, отдельно для Android и iOS. Тестировщик собирает лаунч (запуск тест плана), в котором указывает версию релизной сборки и платформу. После создания лаунча, запускаются автотесты с выбранными кейсами, а ответственный за ручное тестирование назначает мануальные тест кейсы на себя. Каждый проходимый кейс отмечается статусом: Passed, Failed или Skipped. В ходе проверки сразу отображаются результаты.

По окончании проверки лаунч закрывается. А на основании результов выносится решение о готовности к релизу. Вроде все классно и логично, но конечно же есть проблемы из-за которых грустят тестировщики

Определим проблему

Увеличение объема тестируемого функционала при проведении регресса, и выход из временных рамок.
Или тест кейсов все больше и больше, а времени у нас только 8 часов максимум!

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

Анализ и решение

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

Расписав слабые места, мы решили доработать подход к автоматизации, а еще воспользовались импакт-анализом для выделения методов решения.

Impact Analysis (импакт анализ) это исследование, которое позволяет указать затронутые места в проекте при разработке новой или изменении старой функциональности.

Что же мы решили изменить, чтобы разгрузить ручное тестирование и сократить регресс:

1. Увеличение количества автотестов и разработка единого сценария перевода тест кейсов в автоматизацию

2. Разделение тестируемого функционала на фронтенд и бэкенд

3. Изменение подхода к формированию тест плана на регресс и смоук

4. Подключение автоматического анализа изменений, входящих в релизную сборку

Ниже я расскажу про каждый пункт более подробно и какие результаты были получены после введения.

Увеличение количества автотестов

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

Чтобы процесс был одинаковым для обеих платформ, была написана инструкция. В ней расписаны критерии перевода, шаги и инструменты. Я коротко распишу как происходит перевод тест кейсов в автоматизацию:

1. Определяется какие варианты проверок можно автоматизировать. Это делает ручной тестировщик самостоятельно, или обсудив с командой на митинге.

2. В Allure TestOps дорабатываются тест кейсы, например добавляется больше описания или json.

3. Переводятся соответствующие тест кейсы в статус need to automate (так же в Allure TestOps)

4. Создается задача в Youtrack. В ней описывается, что нужно автоматизировать. Прикладываются ссылки на тест кейсы из Allure TestOps. И назначается ответственный AQA.

5. Затем, задачи из Youtrack берутся в работу исходя из приоритетов. После того как изменения влиты в нужные ветки и прошли ревью, задачи закрываются, а тест кейсы в Allure переводятся в Automated со статусом Active. Ревью кода автотестов проводят разработчики.

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

Результаты:

• Сокращение нагрузки на ручное тестирование.

• Четкий и простой механизм перевода в автоматизацию. Все заняты - нет простоев.

• Больше функционала покрыто автотестами, которые гоняются каждый день. Раньше обнаруживаются баги.

Backend и frontend отдельно

Автоматизация тестирования у нас разделена для backend и frontend.

Но есть E2E тесты, которые тестируют взаимодействие.

E2E (end-to-end) или сквозное тестирование это когда тестируется вся система от начала до конца. Включает в себя обеспечение того, чтобы все интегрированные части приложения функционировали и работали вместе, как ожидалось.

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

Поработав в таком формате, мы решили, что много времени уходит на починку автотестов. И тогда E2E тесты приходится проходить вручную.

Было принято четко разделить функционал на модули с выделением логики на фронтенде и бэкенде. Оставить минимальное количество Е2Е тестов для ручного тестирования. Остальные сценарии упростить и автоматизировать. И так на бэкенде мы проверяем бизнес логику, а на клиенте корректное отображение данных от бэке и ui элементы.

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

Для наглядности вот табличка:

Результаты

После разделения:

• Стало проще локализовать проблему

• Раньше определяются проблемы и соответственно решаются быстрее

• Есть четкое разграничение зон ответственности. Нет лишних проверок на клиенте.

• Автотесты стали гораздо стабильнее, т.к. не завязаны на сервисы или моки, которые могут отваливаться в любой момент. (А этот любой момент обычно самый неподходящий)

• Сократилось время на реализацию автотестов, не нужно добавлять json в тест кейсы дополнительно при написании

Отфильтровали тест кейсы в тест плане на регресс

Формирование тест плана на регресс, исходя из того, в каких блоках были внесены изменения. А также выбор основных постоянных сценариев проверки.

Для того, чтобы проще было формировать план, мы стали использовать теги.

Пример: Regress_Deeplink, Regress_Profile, Regress_CommonMobile

Теперь, все тест кейсы у нас поделены на блоки, которые отмечены определённым тегом! Есть также обязательные кейсы, которые входят в каждый тест план на регресс и отдельные тест кейсы для smoke-тестирования на проде.

Это позволяет нам оперативно отфильтровать и быстро сформировать определённый план в соответствии с вносимыми изменениями, а не тратить время на проверку того, что не было затронуто.

Результаты

Введение дополнительного анализа, при формировании тест планов, помогло сократить общее время прохождения регрессионного тестирования всего до 2 часов с 8ми изначальных. У нас есть несколько тест планов full и light. Обычно мы проходим light и он состоит из 98 кейсов (автотестов+ручных). Как видно на скрине, полный план регресса состоит из 297 тест кейсов!

Время на прохождение Regress iOS light в среднем составляет около 2 часов, но когда изменения были только в паре модулей, то можно провести регресс и за час. Это большой плюс, потому что остается запас на багофиксы (если понадобится что-то срочно исправить). Также, в будущем, всегда есть возможность посмотреть по отчетам, в какой сборке что проверялось.

Разработали скрипт с анализом изменений и оповещением через Slack

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

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

Логически возникло следующее решение - сделать этот процесс автоматическим!

Был создан скрипт, который собирает информацию по коммитам. И далее, сформировав отчет о том, какие модули были затронуты, отправляет необходимую информацию в специальный канал Slack.

Скрипт работает просто:

• После каждой сборки получает изменения между предыдущей версией приложения и коммитам, из которого собрался билд

• Получает список файлов, которые отражают изменения в каком-то экране

• Группирует эти изменения по фичам и командам, чтобы упростить жизнь тестировщикам

• Посылаем сообщение в специальный Slack канал со всей информацией по изменениям

Результаты

Какие плюсы мы получили, подключив аналитику по сборкам:

• Сократили время разработчиков на ручной анализ внесенных изменений

• Снизили вероятность упустить из виду и недопроверить необходимый функционал

• Упростили коммуникацию по данному вопросу

Естественно, было затрачено время на написание скрипта, и интеграцию его работы в Slack. Но, в дальнейшем, всем стало проще отслеживать вышеописанный процесс.

Коротко о главном

1. Использование тегов в тест кейсах и при формировании тест планов сократило объем тест плана, соответственно и время на тестирование.

2. Разработка и использование скрипта для оповещение об изменения дало возможность четко понимать какие модули были затронуты при разработке задач для релиза. Или при исправлении багов. Так же тестировщики перестали отвлекать разработчиков с такими вопросами.

3. Автоматизацией было покрыто около 46% тест кейсов, что сильно облегчило ручное тестирование. К тому же остается время на актуализацию кейсов и написание новых.

   

4. Разделение тестирования на backend и frontend помогло заранее определять локализацию проблем и своевременное исправление.