ФРАГМЕНТЫ МАСШТАБИРУЕМОЙ АРХИТЕКТУРЫ ПРИЛОЖЕНИЯ IOS

Зло в генерации кода в Swift

Недостатки автоматизации и сгенерированного кода

Как умный разработчик, вы уже знаете модное кредо:

Все автоматизируйте!

Действительно? Все? 🤨

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

Что это обозначает?

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

Кроме того, каждая система автоматизации обычно нуждается в обслуживании, потому что со временем что-то меняется. Следующее крупное обновление API уже не за горами.

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

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

Умный разработчик прикидывает это заранее. А опытный разработчик даже наполовину прав со сметой. 😜

Инструменты автоматизации

Если вы разрабатываете приложения для iOS, рано или поздно вы столкнетесь с такими инструментами автоматизации, как следующие:

Скоростная полоса

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

Звучит круто, и это так. По крайней мере, до тех пор, пока конвейер снова не сломается, потому что что-то застряло на сервере CI. Теперь вам придется потратить еще один день, два или три, возясь. В какой-то момент это превращается в постоянную работу. 😉

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

Но поговорим о генераторах исходного кода. 🧐

SwiftGen

С SwiftGen вы можете автоматически генерировать Swift-код. Например, инструмент просматривает папку ресурсов и создает типобезопасные константы для строк, цветов, шрифтов и т. Д. Вы даже можете использовать свои собственные шаблоны трафаретов для индивидуализации кода. 🤓

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

R.swift

R.swift делает почти то же самое, что и SwiftGen. Инструмент просматривает ресурсы и создает типобезопасные константы. Однако недостатком является то, что в нем не используются шаблоны, которые можно настраивать. Это означает, что либо вы берете инструмент таким, какой он есть, либо он просто не подходит, и вы берете другой инструмент, например SwiftGen. 😕

Лично я предпочитаю R.swift SwiftGen, потому что это проще и результат достаточно хорош. Настроить SwiftGen так, чтобы он давал мне больше, чем R.swift из коробки, потребовал бы непропорционально больших усилий, особенно при обслуживании. Поэтому я пока останусь с R.swift. ☺️

Источники

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

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

Ткачиха

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

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

Swagger Codegen

При работе с REST API велика вероятность, что внутренний разработчик также предоставит документацию в формате OpenAPI / Swagger. С помощью Swagger Codegen вы можете автоматически преобразовать этот стандартизованный формат спецификации в код Swift.

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

Проблемы с автоматически сгенерированным кодом

Код создается автоматически. Экономит время. Что в этом плохого? 🤨

Тренировочное время

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

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

В зависимости от инструмента

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

Затем вы должны искать альтернативы и замечать, что каждый инструмент создает код по-своему. Один инструмент создает один класс, следующие два класса, третий работает с протоколами и фабриками, а четвертый инструмент называет все совершенно по-другому. Вы угадали: теперь вам нужно адаптировать интерфейс. 😕

Поддержание генераторных ресурсов

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

Результат не всегда оптимальный

Вы редко бываете на 100% удовлетворены сгенерированным кодом. Хорошо, если вы можете настроить шаблон, но и у этого есть ограничения. Однако обычно код создается не так, как если бы вы написали его чисто вручную. По крайней мере, интерфейс выглядел бы иначе. Это приводит к компромиссам. Однако это означает, что экономия времени достигается за счет качества кода. 😟

Заключение

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

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

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

Кстати, это статья из серии Фрагменты масштабируемой архитектуры iOS-приложения.