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

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

В предыдущей части мы рассмотрели, что такое домен и какими принципами можно руководствоваться при его модуляризации. В этой части сконцентрируемся на типах связей между модулями и различиях в проектировании ООП и UDF-кода. Приятного чтения!

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

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

В предыдущей статье мы сформулировали нашу главную проблему при масштабировании Unidirectional Data Flow (UDF) — модуляризацию. Сегодня существует много UDF-фреймворков на Swift, но мало кто уточняет, как их масштабировать на большое, многомодульное приложение. Мы решили поделиться, с какими сложностями столкнулись и к каким решениям пришли. 

В статье рассмотрим 3 проблемы, с которыми столкнулись, и сравним, как разные фреймворки их решают. Для сравнения мы выбрали одни из самых популярных — ReSwift и The Composable Architecture (TCA). В конце расскажем, какое решение мы в итоге реализовали. Приступим!

Привет, я Антон, iOS-разработчик в inDriver. Год назад я присоединился к компании и стал одним из первых разработчиков в новой платформенной команде. Перед платформенными командами, в отличии от продуктовых, стоят задачи по разработке, а не по продукту как таковому. Мы выделили основные направления: создание общих компонент и стандартов разработки, а также развитие и поддержка архитектуры проекта. В этой статье остановимся на архитектуре. Разберем, с какими проблемами столкнулись в процессе ее масштабирования, какие ошибки допустили и как исправили. Обо всем по порядку.

UPD: технические детали подробнее рассказаны во второй части.