Кодогенерация в Uber08.06.2018 14:18

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

Данная статья написана на основе расшифровки доклада Зака Свирса (Zack Sweers), разработчика мобильных приложений Uber, с которым он выступил на конференции MBLT DEV в 2017 году.

В Uber около 300 разработчиков мобильных приложений. Я работаю в команде, которая называется «mobile platform». Работа моей команды заключается в том, чтобы максимально упростить и улучшить процесс разработки мобильных приложений. В основном мы работаем над внутренними фреймворками, библиотеками, архитектурами и так далее. Из-за большого штата нам приходится делать масштабные проекты, которые понадобятся нашим инженерам в будущем. Это может быть завтра, а может быть в следующем месяце или даже году.

Кодогенерация для автоматизации

Мне хотелось бы продемонстрировать ценность процесса кодогенерации, а также рассмотреть несколько практических примеров. Сам процесс выглядит примерно так:

FileSpec.builder("", "Presentation")
   .addComment("Code generating your way to happiness.")
   .addAnnotation(AnnotationSpec.builder(Author::class)
       .addMember("name", "%S", "Zac Sweers")
       .useSiteTarget(FILE)
       .build())
   .build()

Это пример использования Kotlin Poet. Kotlin Poet — библиотека с хорошим API, которая генерирует Kotlin-код. Итак, что же мы здесь видим?

1. FileSpec.builder создаёт файл с именем »Presentation».
2. .addComment () — добавляет комментарий в сгенерированный код.
3. .addAnnotation () — добавляет аннотацию с типом Author.
4. .addMember () — добавляет переменную »name» с параметром, в нашем случае это »Zac Sweers». %S — тип параметра.
5. .useSiteTarget () — устанавливает SiteTarget.
6. .build () — завершает описание кода, который будет генерироваться.

После кодогенерации получается следующее:

Presentation.kt
// Code generating your way to happiness.
@file:Author(name = "Zac Sweers")

Результат кодогенерации — файл с названием, комментарием, аннотацией и именем автора. Сразу возникает вопрос: «Зачем мне нужно генерировать этот код, если я могу сделать это в пару простых действий?» Да, вы правы, но что, если мне нужна тысяча таких файлов с различными вариантами конфигураций? Что произойдёт, если мы начнём изменять значения в этом коде? Что, если у нас есть множество презентаций? Что, если нам предстоит множество конференций?

conferences
   .flatMap { it.presentations }
   .onEach { (presentationName, comment, author) ->
       FileSpec.builder("", presentationName)
           .addComment(comment)
           .addAnnotation(AnnotationSpec.builder(Author::class)
               .addMember("name", "%S", author)
               .useSiteTarget(FILE)
               .build())
           .build()
   }

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

Кодогенерация без ошибок

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

Рассмотрим простой пример. Есть класс Person:

class Person(val firstName: String, val lastName: String)

Допустим, мы хотим добавить к нему сериализацию в JSON. Делать это будем с помощью библиотеки Moshi, так как она достаточно проста и отлично подходит для демонстрации. Создаём PersonJsonAdapter и наследуемся от JsonAdapter с параметром типа Person:

class Person(val firstName: String, val lastName: String)

class PersonJsonAdapter : JsonAdapter() {
}

Далее реализуем метод fromJson. Он предоставляет reader для считывания информации, которая в конце будет возвращена в Person. Затем заполняем поля с именем и фамилией и получаем новое значение Person:

class Person(val firstName: String, val lastName: String)

class PersonJsonAdapter : JsonAdapter() {
 override fun fromJson(reader: JsonReader): Person? {
   lateinit var firstName: String
   lateinit var lastName: String

   return Person(firstName, lastName)
 }
}

Далее смотрим данные в формате JSON, проверяем их и заносим в нужные поля:

class Person(val firstName: String, val lastName: String)

class PersonJsonAdapter : JsonAdapter() {
 override fun fromJson(reader: JsonReader): Person? {
   lateinit var firstName: String
   lateinit var lastName: String
   while (reader.hasNext()) {
     when (reader.nextName()) {
       "firstName" -> firstName = reader.nextString()
       "lastName" -> lastName = reader.nextString()
     }
   }
   return Person(firstName, lastName)
 }
}

Это сработает? Да, но есть нюанс: внутри JSON должны содержаться объекты, которые мы считываем. Для того, чтобы фильтровать лишние данные, которые могут прийти от сервера, добавим ещё одну строчку кода:

class Person(val firstName: String, val lastName: String)

class PersonJsonAdapter : JsonAdapter() {
 override fun fromJson(reader: JsonReader): Person? {
   lateinit var firstName: String
   lateinit var lastName: String
   while (reader.hasNext()) {
     when (reader.nextName()) {
       "firstName" -> firstName = reader.nextString()
       "lastName" -> lastName = reader.nextString()
       else -> reader.skipValue()
     }
   }
   return Person(firstName, lastName)
 }
}

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

Рассмотрим другой пример:

class Person(val firstName: String, val lastName: String)
class City(val name: String, val country: String)
class Vehicle(val licensePlate: String)
class Restaurant(val type: String, val address: Address)
class Payment(val cardNumber: String, val type: String)
class TipAmount(val value: Double)
class Rating(val numStars: Int)
class Correctness(val confidence: Double)

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

У кодогенерации есть и другие преимущества. Например, она выдаёт информацию о коде или подсказывает, если что-то идёт не так. Кодогенерация будет полезна на стадии тестирования. Если вы используете генерируемый код, то сможете увидеть, как действительно будет выглядеть рабочий код. Вы даже можете запускать кодогенерацию во время тестов, чтобы упростить себе работу.

Вывод: стоит рассмотреть кодогенерацию в качестве возможного решения для избавления от ошибок.

Теперь рассмотрим программные инструменты, которые помогают с кодогенерацией.

Инструменты

1. Библиотеки JavaPoet и KotlinPoet для Java и Kotlin соответственно. Это эталоны кодогенерации.
2. Шаблонизация. Популярный пример шаблонизации для Java — Apache Velocity, а для iOS — Handlebars.
3. SPI — Service Processor Interface. Он встроен в Java и позволяет создать и применить интерфейс, а затем объявить его в JAR. Когда программа выполняется, вы можете получить все готовые реализации интерфейса.
4. Compile Testing — библиотека от Google, которая помогает проводить тестирование компиляции. В рамках кодогенерации это означает: «Вот то, что я ожидал, а вот то, что я в итоге получил». Запустится компиляция в памяти, а затем система сообщит вам, был ли завершён этот процесс или какие ошибки возникли. Если компиляция была завершена, вам будет предложено сравнить результат с вашими ожиданиями. Сравнение проводится на основе скомпилированного кода, поэтому не стоит беспокоиться о таких вещах, как форматирование кода или о чем-то ещё.

Инструменты для сборки кода

Для сборки кода есть два основных инструмента:

1. Annotation Processing (Обработка аннотаций) — вы можете написать аннотации в коде и запросить у программы дополнительную информацию о них. Компилятор выдаст информацию ещё до того, как закончит работать с исходным кодом.
2. Gradle — система сборки приложений со множеством хуков (хук — перехват вызова функций) в её жизненном цикле сборки кода. Она широко применяется при разработке на Android. Также она позволяет применить кодогенерацию к исходному коду, который не зависит от текущих исходников.

Теперь рассмотрим несколько примеров.

Butter Knife

Butter Knife — это библиотека, которую разработал Jake Wharton. Он является достаточно известной фигурой в сообществе разработчиков. Библиотека очень популярна среди Android-разработчиков, потому что она помогает избежать большого количества рутинной работы, с которой сталкивается практически каждый.

Обычно мы инициализируем view таким образом:

TextView title;
ImageView icon;

void onCreate(Bundle savedInstanceState) {
 title = findViewById(R.id.title);
 icon = findViewById(R.id.icon);
}

С помощью Butterknife это будет выглядеть так:

@BindView(R.id.title) TextView title;
@BindView(R.id.icon) ImageView icon;

void onCreate(Bundle savedInstanceState) {
 ButterKnife.bind(this);
}

И мы легко сможем добавлять любое количество view, при этом метод onCreate не будет обрастать boilerplate кодом:

@BindView(R.id.title) TextView title;
@BindView(R.id.text) TextView text;
@BindView(R.id.icon) ImageView icon;
@BindView(R.id.button) Button button;
@BindView(R.id.next) Button next;
@BindView(R.id.back) Button back;
@BindView(R.id.open) Button open;

void onCreate(Bundle savedInstanceState) {
 ButterKnife.bind(this);
}

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

В Butter Knife классно то, что она проанализирует код и сгенерирует вам все его аналогичные участки. Она также имеет прекрасную масштабируемость для новых данных. Поэтому если появляются новые данные, нет необходимости снова применять onCreate или отслеживать что-либо вручную. Эта библиотека также отлично подходит для удаления данных.

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

У нас есть вот такое поле:

@BindView(R.id.title) TextView title;

Судя по этим данным, они применяются в некой FooActivity:

// FooActivity
@BindView(R.id.title) TextView title;

У неё имеется свое значение (R.id.title), которое выступает в роли целевого объекта. Обратите внимание, что во время обработки данных этот объект становится постоянным значением внутри системы:

// FooActivity
@BindView(2131361859) TextView title;

Это нормально. Это то, к чему Butter Knife должна иметь доступ в любом случае. В качестве типа имеется компонент TextView. Само поле называется title. Если мы, например, сделаем из этих данных класс-контейнер, то получится что-то вроде этого:

ViewBinding(
 target = "FooActivity",
 id = 2131361859,
 name = "title",
 type = "field",
 viewType = TextView.class
)

Итак, все эти данные можно без труда получить во время их обработки. Это также очень похоже на то, чем занимается Butter Knife внутри системы.

В результате у нас генерируется вот такой класс:

public final class FooActivity_ViewBinding implements Unbinder {
 private FooActivity target;

 @UiThread
 public FooActivity_ViewBinding(FooActivity target, View source) {
   this.target = target;

   target.title = Utils.findRequiredViewAsType(source,
       2131361859, // R.id.title
       "field 'title'",
       TextView.class);
 }
}

Здесь мы видим, что все эти кусочки данных собираются воедино. В итоге, мы имеем целевой класс ViewBinding из java-библиотеки Underscore. Внутри, эта система устроена таким образом, что каждый раз при создании экземпляра класса, она тут же выполняет всю эту привязку к той информации (коду), который вы сгенерировали. И всё это предварительно статически генерируется во время обработки аннотаций, а значит, это технически правильно.

Вернёмся к нашему программному конвейеру:

Во время обработки аннотации система считывает эти аннотации и генерируется класс ViewBinding. А затем во время выполнения метода bind мы производим идентичный поиск одного и того же класса простым способом: мы берём его название и дописываем ViewBinding в конце. Сам по себе участок с ViewBinding в процессе обработки переписывается в указанную область при помощи JavaPoet.

RxBindings

Сама по себе RxBindings не отвечает за кодогенерацию. Она не занимается обработкой аннотаций и не является плагином Gradle. Это обычная библиотека. Она предоставляет статические фабрики, основанные на принципе реактивного программирования для Android API. Это значит, что, например, если у вас есть setOnClickListener, то появится метод для клика, который будет возвращать поток (Observable) событий. Он выступает в роли моста (шаблон проектирования).

Но на самом деле в RxBinding есть кодогенерация:

В этой директории под названием buildSrc есть задача Gradle, которая называется KotlinGenTask. Это означает, что всё это на самом деле создается путём кодогенерации. RxBinding имеет реализации на Java. У неё также есть артефакты Kotlin, которые содержат функции-расширения для всех целевых типов. И всё это очень жёстко подчиняется правилам. Например, вы можете сгенерировать все функции-расширения Kotlin, и вам не придётся контролировать их по отдельности.

Как это выглядит на самом деле?

public static Observable