- Особенности разработки iOS приложений
- Что такое автогенератор кода и как его использовать
- Как работают переиспользуемые абстрактные реализации
- Итоги
С шаблонным многострочным кодом в iOS-приложениях сталкиваются все современные программисты. Ниже мы расскажем о фишках, которые помогают разработчикам работать с ним.
Если вы хотите узнать больше о специфике этой профессии, советуем зарегистрироваться на курсы DevEducation.
Особенности разработки iOS приложений
Практически каждое приложение для системы iOS имеет табличный вид, вне зависимости от того, каким способом оно было реализовано. Однако в девяти из десяти случаев разработчикам приходиться писать шаблонный код снова и снова.
Речь идет о многоступенчатом процессе, который включает:
- создание табличного источника данных;
- работу над табличным делегатом;
- учет обратных сообщений касательно изменения данных;
- анализ стандартного кода по работе с разными видами коллекций и их модификация в соответствии с табличной структурой источника данных;
- повторение всех процессов.
Процесс подразумевает использование объемного шаблонного кода. На его разработку и тестирование уходит много времени.
Именно поэтому программисты создают различные микромодули для того, чтобы скрыть шаблонный код. Они представляют собой набор легких в реализации и универсальных абстрактных систем, которые подойдут 99% iOS-приложений. Их называют автогенератором кода.
Что такое автогенератор кода и как его использовать
Автогенератор кода для iOS-приложений помогает минимизировать время разработки и тестирования, а также выпустить более качественный продукт.
Но у стороны две медали. Среди ограничений автогенератора кода стоит выделить следующие:
- если код объемный, а количество измененных параметров в нем небольшое, то растет число повторяющихся фрагментов, как и размер файла;
- специалисту легко устать от монотонного процесса проверки объемных однотипных блоков кода, поэтому некоторые нюансы могут быть упущены. Это приводит к снижению качества проверки;
- все авто-сгенерированные коды должны быть проверены и протестированы, что влияет на рост количества дублей кодов и тестов;
- код, который был сгенерирован автоматически, хуже поддается идентичным модификациям и их проверкам;
- во время того как задается шаблон для автоматически сгенерированного кода, ошибки не проверяются, в том числе архитектурные, что приводит к рефакторингу;
- есть риск умножения всех вышеупомянутых проблем с кодами и коллекциями.
К счастью, есть альтернативные решения, которые мы представим ниже.
Как работают переиспользуемые абстрактные реализации
Как вы уже поняли, в шаблонном многострочном коде для iOS-приложений есть много недостатков. Поэтому нужно уменьшать так называемый time-to-market.
Многие разработчики применяют для этого улучшенный микромодуль переиспользуемых абстрактных реализаций с целью создания табличных представлений шаблонного кода.
Некоторые из модулей были созданы благодаря языку Swift, автором которого является компания Apple.
Правда, в опенсорсе его не встретишь, так как создателям необходимо переписать часть кода и уладить юридические аспекты этого вопроса.
Если вы возьмете в работу принцип абстрактных реализаций, то получите:
- единичное ревью, повышающее уровень его качества и минимизирует степень усталости разработчиков;
- объем выполняемого файла остается прежним в связи с одной реализацией функционала с зависимостью, инжектируемой снаружи;
- легкие тесты, которые пишутся единожды;
- если абстрактная реализация хорошо покрыта тестами, ее можно легко модифицировать с целью получения нового поведения по всему iOS-приложению;
- вероятность допущения ошибки в написании абстрактной реализации практически нулевая, что дает качественно структурированный код еще на этапе разработки;
- В связи с микро-модульной базой организации кода, есть возможность переиспользовать значительный объем кода между коллекциями и таблицами, ничего не меняя.
Все вышеперечисленные пункты облегчают работу. Следуя им, можно существенно минимизировать шаблонный код. При этом контроллер представления окажется практически пустым.
Чтобы создать очередной экран, нужна фабрика, которая связывает абстрактные модели между собой. Она должна инициализировать их с определенными параметрами, среди которых получение данных.
Тесты создаются при этом исключительно на очередные созданные компоненты и ни в коем случае не могут быть на переиспользуемых.
Таким образом, вы можете улучшить time-to-market при разработке, поддержке и внесении правок.
Но стоит вспомнить и о недостатках этого процесса. Среди них необходимость ознакомиться и изучить каждый переиспользуемый класс, если вы не знаете документации компании Apple относительно работы с таблицами и коллекциями.
Однако, это можно решить. Если классы полностью независимы друг от друга и могут функционировать по отдельности – считайте проблема решена. Вы можете для начала использовать привычный для себя подход, а потом подключить архитектуру переиспользуемого источника данных.
Если этот процесс будет завершен успешно, то в части экранов нужно будет подключить переиспользуемый Delegate и активировать обсервер. Это поможет облегчить мониторинг модификации изменения данных.
Прежде чем искать проблему в себе или в привычном принципе своего рабочего процесса, вернитесь к той же документации Apple. Многие опытные разработчики делают так, когда понимают, что что-то идет не по плану. Возможно, вспомнив важные детали вы найдете ответ на свой вопрос.
Итоги
Подход, описанный в сегодняшней статье помогает избавиться от шаблонного многострочного кода в iOS-приложении. Вы дойдете до реализации стандартного рабочего процесса с меньшим объемом повторяющихся фрагментов.
Важно иметь в арсенале полезные инструменты и архитектурные паттерны, ведь их комбинация упростит жизнь не только вам, но и всей команде. Особенно это важно в разработке мобильных приложений.
