В этой статье подводится итог первой части моего исследования о влиянии Kotlin на компании и частных лиц, которые уже вложили средства в Java.

Поскольку существует так много влияний, эта первая часть коснется только того, как Kotlin влияет на чтение и понимание кода, поскольку именно на него мы проводим 90% нашего времени. Хотя это звучит сложно, требуется много часов, чтобы найти дефект, чтобы понять, что нужно исправить пару строк. Аналогичный процесс происходит при добавлении новых возможностей в существующую кодовую базу, особенно когда изменения влияют на существующие функциональные возможности.

Соотношение времени, потраченного на чтение и на письмо, намного больше 10: 1 (источник).

Хорошие программисты тратят большую часть остальных 90% на размышления, исследования и эксперименты, чтобы найти лучший дизайн (источник).

Вкратце: я старший разработчик, которому нравилось работать с Java, и я также использовал его в своих личных побочных проектах. Хотя количество строк не является хорошим показателем производительности, я мог бы превышать 1000 строк чистого кода в день, если бы у меня был четкий план атаки. Я говорю это только для того, чтобы указать, что, с моей точки зрения, я не чувствовал, что я чего-то упускаю. Мое расследование началось, когда Google объявил о первоклассной поддержке Kotlin.

Введение в Котлин

Kotlin - это бесплатный язык программирования с открытым исходным кодом, разработанный JetBrains. Он находится в разработке с 2010 года и готов к использованию в производстве с февраля 2016 года. Фактически, многие уважаемые компании уже включили Kotlin в свои производственные приложения. JetBrains отметила, что внедрение приложений для Android и серверных приложений JVM составляет примерно 50/50. Фактически, уровень принятия настолько высок, что, по прогнозам, в течение года он превзойдет Java для разработки под Android. Это повлияет на тип навыков, которые будут востребованы.

Kotlin компилируется в байт-код Java и работает на JVM, поэтому он подходит для всех сред, в которых используется Java. Это включает в себя Android, а также серверные приложения. Kotlin также совместим с Java в обоих направлениях. Это позволяет компаниям использовать свои существующие вложения в Java, а также большую коллекцию библиотек Java с открытым исходным кодом без необходимости что-либо переписывать. Классы Kotlin могут работать вместе с классами Java, и, хотя это не обязательно, классы Java даже могут быть автоматически преобразованы в Kotlin, что обеспечивает очень щадящую кривую обучения. При работе внутри класса Java классы Kotlin открываются дружественным к Java способом, и наоборот.

Kotlin также может компилироваться в собственный (например, для iPhone), JavaScript или WebAssembly для внешнего интерфейса, и даже скрипты сборки Gradle теперь могут быть написаны на Kotlin. Идея реализации back-end, front-end и build скрипта на одном языке очень многообещающая. Хотя Kotlin на интерфейсе сначала звучит странно, преимущества аналогичны тому, почему компании выбирают TypeScript, но с гораздо большим количеством гарантий.

Вы даже можете определить предметно-ориентированные языки (DSL), которые могут гарантировать правильность во время компиляции для пользовательских шаблонов или форматов. Например, вы можете определить DSL для SQL-запросов, HTML или XML, которые предотвратят создание искаженного содержимого SQL, HTML или XML. В качестве побочного эффекта вы также получаете подсказки IDE, автозаполнение и возможности рефакторинга, которые обычно недоступны за пределами языков программирования.

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

Рамки для количественной оценки воздействия на производительность

Прежде чем делать какие-либо числовые утверждения, мы сначала определим структуру, которая позволит нам количественно оценить влияние на производительность.

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

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

Возможное повышение производительности зависит от накладных расходов, связанных с узкими местами, и от того, насколько мы можем их уменьшить. Например, если действие занимает 60 минут из-за 40-минутного узкого места (40/60 = 67% накладных расходов), полное устранение этого узкого места (коэффициент сокращения 100%) увеличит наше доступное продуктивное время с 20 минут до полных 60. минут, поэтому потенциально мы могли бы выполнить 3 из этих действий за то же время. В качестве альтернативы, если мы уменьшим накладные расходы на 75% (с 40 до 10 минут), производительность в этом примере может удвоиться. Обобщая эти примеры, мы имеем:

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

Размер и сложность кода Kotlin

Ожидается, что преобразование Java-приложения в Kotlin сократит количество строк на 40% согласно Jetbrains. Обратите внимание, что это не достигается за счет добавления большего количества кода в каждую строку, так как средняя длина строки также уменьшается. В совокупности это означает, что общий объем кода может быть уменьшен более чем на 50% при использовании возможностей Kotlin.

Есть три основных причины сокращения кода. Первая причина связана с более кратким языком (например, классы данных Kotlin могут заменить 50 классов строк одной строкой). Вторая причина заключается в том, что стандартная библиотека Kotlin расширяет существующие классы Java с помощью расширений, упрощающих обычное использование (например, разделение коллекции элементов на основе некоторого настраиваемого условия или проверка, содержит ли коллекция элемент с определенными качествами и т. Д.). Последняя причина очень удивительна. Kotlin фактически обеспечивает более высокие уровни повторного использования кода, что совершенно невозможно в Java, даже при использовании функций Java 8. Хотя оба языка являются полными по Тьюрингу, Kotlin позволяет извлекать больше шаблонов для повторного использования, чем позволяет Java.

В качестве примера, который невозможен в Java, Kotlin позволяет вам использовать оператор return внутри встроенных лямбда-выражений, чтобы он возвращался так же, как и из чего-то вроде цикла for. В Java возврат из лямбда-выражения вводит в заблуждение, поскольку на самом деле он не возвращается из текущей функции, в которой вы находитесь. Высокоуровневое значение оператора return зависит от контекста Java (возврат из метода или возврат из этот кусок кода). Эта возможность Kotlin выглядит так, будто вы определяете новые языковые конструкции, которые делают ваши служебные функции очень естественными для использования. В качестве примера можно привести что-то вроде попытки использования ресурсов, которую нам нужно было подождать, пока Java 7 не будет реализована с помощью простой служебной функции в Kotlin. Это позволяет вам писать естественно выглядящую бизнес-логику, абстрагируясь от общих шаблонов, таких как обработка исключений или получение и снятие блокировок. Более того, в отличие от проблем с масштабируемостью, которые могут возникнуть при использовании некоторых функций Java 8 (например, создание лямбда-выражений в цикле), встроенные лямбда-выражения в Kotlin не влияют на производительность или память.

В язык включены многие передовые практики и шаблоны проектирования, поэтому вам никогда не придется реализовывать их самостоятельно. Это также устраняет многие категории дефектов. Некоторыми примерами являются синглтоны, делегирование, классы данных и т. Д. Java требует, чтобы вы нашли время, чтобы прочитать, понять и проверить правильность реализации шаблонов, тогда как многие из них являются частью языка и гарантированно являются правильными. Они читаются как концепции, а не как серия инструкций, как в Java. Кроме того, были устранены многие антипаттерны Java, что устраняет когнитивные накладные расходы, связанные с необходимостью следить за ними. Существуют дополнительные гарантии, которые сокращают количество предположений или соображений, которые необходимо сделать при чтении кода (например, может ли эта логическая переменная когда-либо быть нулевой и будет ли это случайно интерпретировано как ложь?).

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

Следовательно, преобразование Java-приложения в Kotlin и использование преимуществ Kotlin уменьшает размер кода на 50%. Код также намного легче понять, потому что дополнительные возможности Kotlin позволяют вам думать, используя концепции более высокого уровня. Возможные состояния приложения в любой заданной точке также уменьшаются, что снижает возможности, которые необходимо учитывать, тем самым уменьшая когнитивные усилия. Объединив уменьшение размера кода с уменьшением усилий для чтения, я обнаружил, что время, необходимое для чтения и понимания кода, сокращается вдвое. Это позволяет нам начать производство раньше, что снижает производительность. Таким образом, Kotlin позволяет нам работать в 1 / (1 - 0,9 * 0,5) = 1,8 раза более продуктивно, поскольку именно здесь мы проводим более 90% нашего времени.

Понимая, что время, затрачиваемое на создание, также сокращается, легко увидеть, как Kotlin может удвоить производительность только за счет этих воздействий!

Я также заметил, что, поскольку мой код ближе к концептуальному уровню в Kotlin, это приводит к более чистому коду, поэтому будущие накладные расходы на обслуживание / устойчивость также сокращаются.

Я был искренне шокирован своей продуктивностью после знакомства с языком, поскольку не ожидал, что он окажет заметное влияние (в основном я думал о снижении количества дефектов). Только после выполнения большого задания в Котлине я понял, что мои карьерные перспективы навсегда изменятся. Как бы мне ни нравилось работать с Java в прошлом, когда я испытал такой прагматичный и продуктивный язык, я просто не могу позволить себе сдерживаться так сурово сейчас, когда вижу, что возможно.

Какими бы удивительными ни были эти результаты, их влияние на количество дефектов гораздо шокирует, особенно с учетом количества времени и бюджета, затраченного на эту область (подсказка: предотвращается гораздо больше категорий дефектов в дополнение к нулевой безопасности). Еще один сюрприз заключается в том, что приложения Kotlin в целом более безопасны, чем приложения Java (я, возможно, напишу об этом подробнее позже).

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