Разработка мобильных приложений на основе заглушек
В течение последнего месяца я разрабатывал приложение, в значительной степени основанное на серверном API. Весь процесс был беспорядочным. Вот как выглядит типичное утро: я начинаю работать над функцией в пользовательском интерфейсе, понимаю, что у меня есть ошибка в моем сетевом уровне, исправляю ее, продолжаю работать над функцией, понимаю, что мне нужны данные, которых нет на сервере ответ, скажите обслуживающему персоналу, что он отсутствует, пообедайте, а затем забудьте, что я делал, потому что я работаю сразу над пятью делами! Так жить нельзя.
Так что у меня появилась идея. Почему бы просто не сделать бэкэнд-заглушку. То есть создайте поддельную версию службы, на которую опирается ваше приложение, еще до того, как вы начнете работать над одной функцией. Если ваше приложение использует какой-то серверный API для получения данных, напишите класс, который будет выдавать вам данные-заглушки. Сделайте так, чтобы этот класс реализовал интерфейс, а затем заставьте остальную часть вашего приложения взаимодействовать с интерфейсом.
Почему?
Более легкая разработка
Я, вероятно, потратил около 20% времени на разработку этого приложения, просматривая весь поток приложения, пока не дойду до точки, которую хочу протестировать, просто потому, что так устроен наш бэкэнд. Если бы я с самого начала работал с фиктивными данными и заглушками, я бы смог тестировать каждую часть приложения отдельно и полностью контролировать весь процесс.
Более быстрая разработка
Накладные расходы не всегда означают медленнее. Строителям, работающим над вашим зданием, наверняка будет тяжелее без строительных лесов. В этом случае (обычно небольшое) время, необходимое для написания фиктивной сетевой службы, минимально по сравнению с количеством времени, которое вы будете ждать, пока ваша бэкэнд-команда исправит ошибку на стороне сервера.
Стоимость перехода
Программист, кодирующий на полном ходу, держит в своей голове множество вещей одновременно: все, от имен переменных, структур данных, важных API-интерфейсов, имен служебных функций, которые они написали и часто вызывают, даже имени подкаталога, в котором они хранить их исходный код. Если вы отправите этого программиста на Крит в трехнедельный отпуск, они все забудут. - Джоэл Спольски
Это настоящая вещь. Это означает, что люди более эффективно работают над одним делом за раз, потому что нам нужно время, чтобы привыкнуть к новым способам мышления. Постоянное переключение с работы на сетевом уровне на написание новой функции на уровне представления означает, что вы всегда находитесь на этапе «начала работы».
Заблаговременное определение функциональности
Ранний сбой - мертвая программа обычно наносит намного меньше повреждений, чем поврежденная. - Прагматичный программист
Это популярная поговорка в программировании. Но это относится не только к дизайну, но и ко всему процессу разработки. Вы хотите определить свою архитектуру как можно раньше. И тогда, независимо от того, насколько вы хороши, вы совершите массу ошибок. Вот почему вы начинаете с заглушки и делаете свое приложение на ее основе. Это покажет вам недостатки того, как вы разработали свое приложение на ранней стадии, и даст вам возможность очень легко изменить его.
Параллельная разработка
Если вы правильно настроили свою архитектуру (слои отделены друг от друга и используют интерфейсы для связи), вашему приложению на самом деле все равно, будет ли это сервер или класс из собственного пакета, предоставляющий данные. Итак, ваша бэкэнд-команда может работать со своей стороны, а вы можете работать со своей, а когда придет время, вы просто объедините усилия.
Заставляет вас думать о будущих изменениях
Разработка программного обеспечения - это целый ряд изменений. Весь смысл использования SVN - отслеживать изменения. Итак, вы хотите внести изменения как можно проще и безболезненно. Использование заглушек заставит вас спроектировать свою архитектуру таким образом, чтобы вы могли изменить базовую модель и сетевой сервис, не изменяя уровень пользовательского интерфейса. В будущем это сделает вашу жизнь намного проще.
Готовит вас к тестированию пользовательского интерфейса
UI-тестирование - это огромная заноза в заднице. Но это также и огромная палочка-выручалочка. Использование заглушек сделает ваши тесты пользовательского интерфейса намного быстрее, и вы получите гораздо больший контроль над ними.
Как?
- Создайте интерфейс (протокол), который должен реализовывать объект (только один объект), который будет взаимодействовать с сервером.
- Сделайте реализацию для счастливого пути (возвращайте фиктивные данные, обрабатывайте запросы с правильным ответом и т. Д.)
- Сделайте реализацию для печального пути (не возвращайте данные, мусор, неправильные ответы и т. Д.)
- Создайте свое приложение. Никогда не разговаривайте напрямую с приведенными выше реализациями, всегда используйте интерфейс.
- Переключайтесь между счастливой и грустной реализациями, чтобы проверить, правильно ли ваше приложение обрабатывает и то, и другое.
- Когда вы закончите работу с приложением, создайте свою настоящую сетевую услугу.
- Wohoo! 🎊
Наслаждайтесь процессом разработки без стресса!
Марин - разработчик iOS в COBE, блогер на marinbenc.com и студент компьютерных наук в FERIT, Осиек. Ему нравится программировать, узнавать о разных вещах, а потом писать о них, ездить на велосипедах и пить кофе. В основном, однако, он просто вызывает сбои SourceKit. У него есть пухлый кот по имени Амиго. Не он сам писал эту биографию.
