Котлин
Kotlin - это относительно новый язык JVM, и Jetbrains активно развивается с 2011 года.
За эти годы язык получил все больше внимания в сообществе Android и стал самой горячей темой в разработке Android после конференции Google IO 2017. Конференция объявила, что Android официально поддерживает Kotlin.
К сожалению, хотя уже есть много статей о котлине, объективной информации не так много, и многие разработчики все еще думают о том, является ли переход на котлин правильным путем.
В остальной части этой статьи я постараюсь предоставить более полный список вещей, которые следует учитывать при оценке котлина как альтернативы Java.
Субъективное сравнение между Kotlin и Java
«Котлин лучше, чем Java», «Котлин более читабелен, чем Java», «скорость развития Kotlin быстрее, чем Java», в таких заявлениях не хватает поддержки соответствующих точных данных, поэтому все они классифицируются как субъективные представления.
Субъективная точка зрения формируется, когда отдельный разработчик выносит одно или несколько субъективных суждений по темам, связанным с котлин или Java.
Есть проблемы со следующими субъективными суждениями разработчиков:
Нет количественных показателей, связанных с субъективным суждением.
Есть большие предубеждения в субъективном суждении.
Предвзятость субъективного суждения сильно варьируется среди разработчиков.
Поскольку не существует количественных показателей, связанных с субъективными суждениями, перспективы, основанные на этих суждениях, отражают только предубеждения, которые разработчики имели ранее. У разных разработчиков могут быть очень разные предубеждения, поэтому это не означает, что другие разработчики тоже так думают.
Более того, поскольку нет никаких объективных показателей, субъективные различия не могут быть объективно устранены, что часто приводит к «войне слов».
Ошибка субъективного суждения
Чтобы проиллюстрировать недоразумения, к которым могут привести субъективные суждения, давайте внимательно рассмотрим очень распространенный субъективный взгляд:
Котлин более читабелен, чем Java - бесчисленные статьи в Интернете
Теоретически, можно попытаться спроектировать эксперимент, который измеряет разницу в чтении между котлином и Java, но, насколько я знаю, никто не проводит такой эксперимент. Поэтому на данный момент эта точка зрения не имеет поддержки данных.
Синтаксис Котлина - одна из причин, по которой многие разработчики хвалили его читаемость. Их логика заключается в следующем:
Котлин имеет лучший синтаксис, поэтому он более читабелен - бесчисленные статьи в Интернете
В этом предложении «Лучшая грамматика» является еще одним субъективным суждением, которое само по себе спорно, но чтобы избежать аргументов, мы предполагаем, что грамматика Котлина действительно лучше. Однако означает ли это, что Котлин более читабелен?
Чтобы наблюдать за влиянием синтаксиса на читабельность, прочитайте этот абзац «Текст»:
Вначале этот «текст» трудно понять, но медленно его становится легче читать. Если вы прочитаете это два или три раза, вы не заметите, что он состоит из нестандартных букв. Чтобы быть точным, замена букв не является синтаксическим изменением, но она показывает, что внешний вид редко становится барьером для читаемости для квалифицированных читателей.
Мы также можем расширить этот пример на естественный язык. Я понимаю три совершенно разных языка. Хотя они сильно различаются, мне очень трудно читать текст на любом языке, когда я не понимаю слова, используемые в тексте. Как только я узнал слова, которые составляют текст и стали знакомы с контекстом - независимо от того, на каком языке он был, мне не было трудно читать его.
Поэтому для меня выбор языка не влияет на читаемость, просто понимайте содержание и контекст.
То же самое относится и к языкам программирования.
Когда мы начнем использовать новый язык, у нас будет некоторое время трудности в понимании исходного кода и нам необходимо тщательно понимать каждую синтаксическую структуру. Однако, когда мы читаем и пишем код для конкретного языка все больше и больше, мы постепенно знакомы с синтаксисом этого языка, и в какой -то момент мы больше не будем обращать внимание на синтаксическую структуру.
У меня был этот опыт в нескольких языках сам: Verilog, Bash, Perl, TCL, LISP, Java.
Основываясь на моем опыте работы с вышеуказанными языками, я могу сказать вам: если человек адаптируется к коду LISP и больше не замечает скобки, то синтаксис Котлина не может оказать ненадлежащее влияние на читабельность по сравнению с Java, даже если он «лучше».
Поскольку мы обсуждаем эту тему, я поделюсь своим субъективным суждением о факторах, которые влияют на читабельность исходного кода.
После прочтения кода, написанного другими разработчиками, на многих языках (приведенные выше перечислены только языки, на которых я опытный на определенном этапе; я использовал больше языков, чем это), я пришел к следующему выводу: если разработчики могут писать код, который является как читаемым, так и понятным на одном языке, они обычно могут писать код, как читаемый, и понятный и в других языках.
Таким образом, субъективное суждение, которое я вынес на основе моего собственного опыта, заключается в том, что читаемость исходного кода не имеет ничего общего с выбранным языком, и это зависит от навыков автора кода и навыков читателей (навыки писателя более важны).
Если вы все еще думаете, что субъективные взгляды являются представительными, по крайней мере, прочитайте и подумайте о том, что Роберт «дядя Боб» Мартин думает в этом сообщении в блоге.
Объективное сравнение между Kotlin и Java
В отличие от субъективных сравнений, объективные сравнения используют количественные показатели для измерения или оценки того, где Kotlin имеет преимущества перед Java.
Идея объективного доказывания, лучше ли язык программирования лучше, чем другой с одним набором стандартов, очень привлекательна, но есть проблема: насколько я знаю, нет общих объективных показателей, связанных с языками программирования.
Учитывая, что мы не можем провести точные и прямые сравнения, можем ли мы объективно сравнить Kotlin и Java? способный! Мы по -прежнему можем оценить степень позитивного и обмена сообщениями о переходе с Java на котлин, затем сравнить результаты и обсудить их влияние.
Чтобы оценить наилучшие результаты, которые может дать Котлин, мы сделаем следующие предположения:
Разработчики могут немедленно переключиться на котлин;
После перехода на Котлин разработчики не теряют никаких навыков (например, разработчики с двумя годами опыта развития Java могут магически получить два года опыта развития Kotlin);
Котлин такой же стабильный, как Java;
Инструменты Kotlin так же зрелы, как и инструменты Java.
На самом деле, ни одно из вышеперечисленных предположений не является разумным, но в начале есть идеальная обстановка для легкого объяснения. Затем мы отложим эти предположения и обсудим влияние реальных эффектов.
Оценки лучших результатов Kotlin
Следуя модели, предложенной Стивом Макконнеллом в Code Complete, мы можем разбить мероприятия по строительству программного обеспечения на три субэффективности: подробный проектирование, кодирование и отладка, а также разработка и тестирование.
Kotlin мало влияет на детальную разработку суб-активности (эта деятельность обычно не зависит от выбранного объектно-ориентированного языка программирования), поэтому Котлин и Java должны приложить те же усилия в этом разделе.
Насколько я знаю, Котлин не предложил ничего революционного о субъективности теста на разработку. Следовательно, то же самое относится и к разработке тестирования.
Вся кодировка и отладка оставлены субъективностью.
Если мы заменим Java на Kotlin, какую работу я могу сэкономить на кодировании и отладке? На этот вопрос трудно ответить, и на это значение сильно различается между программистами (некоторые программисты используют Java более эффективно). Однако теперь, когда мы оцениваем лучшую ситуацию, мы можем также предположить, что переход с Java на котлин может повысить производительность разработчика в среднем на 10% на этапах кодирования и отладки.
Повышение производительности на 10% является удивительно нереалистичным ценностью. Даже если мы вручную введем весь код в текстовом редакторе, это нереально. Учитывая текущие функции IDE, это значение еще более нереально. Учитывая, что некоторые разработчики используют Java более эффективно, это значение не имеет смысла.
Я не против использовать такую ценность, которая является одновременно нереалистичной и благоприятной для оценки Котлина, потому что я знаю, что независимо от того, насколько нереально положительно он оказывает на результаты оценки, как только мы отложили некоторые из «идеальных предположений» в нем, полученные негативные последствия будут компенсировать эти положительные последствия.
Итак, с точки зрения кодирования и отладки, мы увеличились на 10% - как быстро мы доставляем наши продукты нашим клиентам?
Следующая картина получена из кода книги, показывая долю различных действий программных проектов:
Небольшой проект картины фокусируется на строительных мероприятиях. Более крупные проекты требуют большего количества архитектуры, интеграции и тестирования системы, чтобы гарантировать успех проекта. Эта картина не показывает требования, потому что, в отличие от других действий, работа по требованиям не является прямой программой функцией. (Albrecht 1979; Glass 1982; Boehm, Grey и Seewaldt 1984; Boddie 1987; Card 1987; McGarry, Waligora и McDermott 1989; Brooks 1995; Jones 1998; Jones 2000; Boehm et al. 2000)
Код завершен, второе издание
Согласно этому изображению из Code Complete, в более крупном программном проекте (более 10 тыс. Линий), учетная запись кодирования и отладки составляет менее 20% от общей рабочей нагрузки проекта.
Следовательно, в более крупном программном проекте, мы предполагаем, что эффективность кодирования и отладки составляет 10%, что может снизить общую рабочую нагрузку, необходимую для завершения проекта на 2%.
Например, проект, который занимает 5 человек в течение многих лет (это относительно большой проект Android), 2% от общей рабочей нагрузки составляют:
5 человек - год * 12 * 4 * 5 * 0,02 = 24 (люди - день)
Если бы мы действительно могли бы сократить рабочую нагрузку проекта на 24 человека, это было бы хорошей причиной перехода с Java на котлин. Тем не менее, мы должны помнить, что вышеуказанная положительная оценка была получена в идеальных ситуациях и была основана на нереалистичных предположениях.
В реальном мире переход на другой язык программирования оказывает неизбежное влияние, которое мы будем оценивать и сравнивать с идеализированной оценкой, упомянутой выше.
Подготовка разработчика
Чтобы оценить лучший сценарий, мы предполагаем, что разработчики могут немедленно переключиться с Java на котлин.
На самом деле, хотя Котлин очень похож на Java, разработчикам все еще нужно потратить некоторое время на обучение, а затем потратить некоторое время на настройку практики и инструментов развития. Время подготовки варьируется от человека к человеку: некоторые разработчики могут переключаться между тремя или четырьмя днями, в то время как другие могут занять 10 дней или более.
Давайте будем оптимистично, в среднем каждый разработчик может переключиться с Java на котлин всего за 5 дней.
Проект, который занимает 5 человек, будет иметь от 3 до 5 разработчиков (в лучшем случае). Среднее время переключения для каждого разработчика составляет 5 дней, так что в общей сложности проект занимает от 15 до 25 человек.
Усилия, сохраненные путем перехода на Kotlin (оптимистическая оценка), по -видимому, примерно так же, как общее усилие, необходимое для переключения.
Потеря навыков разработчика
Способность эффективно работать на конкретном языке программирования является навыком.
Мы обсудили один аспект этого навыка (читаемость кода), но есть много других. При переходе с одного языка на другой, некоторые навыки, связанные со старым языком программирования, могут применяться к новому языку, но другие части навыка теряются.
Чтобы оценить влияние потери навыков языка программирования на рабочую нагрузку проекта, мы будем использовать фактор «Язык и инструмент», полученный из модели оценки COCOMO2:
Язык и инструмент опыта (LTEX)
Этот показатель используется для измерения опыта проектных команд, разработанных программных систем или подсистем с использованием языков программирования и программных инструментов. Разработка программного обеспечения включает в себя использование инструментов для выполнения требований, проектирования и анализа выражения, управления конфигурацией, извлечения документов, управления библиотеками, стиля программы и форматирования, проверки согласованности, планирования и контроля и т. Д. В дополнение к опыту языка программирования проекта, опыт инструментов поддержки проекта также может повлиять на усилия по разработке. Опыт ниже 2 месяцев получит очень низкий рейтинг, а опыт менее 6 месяцев или лет получит очень высокий рейтинг, см. Таблицу ниже:
Я не знаю, что это за снижение, сколько проектов повлияло, но мой мозг автоматически перевел комбинацию «значительного снижения производительности» в потерю впустую много часов развития ».
Кроме того, если вы прочитаете комментарии о заметках по публикации, вы заметите, что многие люди имеют проблемы с миграцией. В комментариях к версии 1.1.2 некоторые даже указали, что этот «выпуск« патча »представил разрушительные (обратные несовместимые) модификации.
В отличие от этого, если вы прочитаете заметки о выпуске Oracle JDK8, вы обнаружите, что это относительно стабильно. Большинство модификаций являются улучшениями безопасности.
Поэтому Котлин - это нестабильный и незрелый язык по сравнению с Java - что будет миграция в Котлин в проекте? Чтобы ответить на этот вопрос, я буду использовать рабочую коэффициент «волатильности платформы» из модели оценки Cocomo 2:
Волатильность платформы (PVOL) Здесь термин «платформа» относится к сложному аппаратному и программному обеспечению (ОС, СУБД и т. Д.), Которые вызываются, когда программный продукт выполняет задачи. Если разработанное программное обеспечение является операционной системой, то платформа является компьютерным оборудованием. Если разработана система управления базой данных, то платформа является аппаратной и операционной системой. Если сетевой текстовый браузер разработан, то платформа - это сеть, компьютерное оборудование, операционная система и библиотека распределенной информации. Платформа включает компиляторы или сборщики, необходимые для поддержки разработки программных систем. Как показано в следующей таблице, если платформа изменяется только один раз каждые 12 месяцев, рейтинг будет очень низким, и если каждые 2 недели произойдет значительное изменение, рейтинг будет очень высоким:
Руководство по определению модели COCOMO2
Возможно, вы заметили, что язык программирования не появляется непосредственно в описании этого рабочего фактора, но появляются компиляторы и сборщики. На мой взгляд, это описание явно не включает в себя язык программирования, потому что все проекты, которые выводят модель Cocomo2, используют стабильный язык.
Поскольку компиляторы и сборщики принадлежат этому рабочему факту, мы также можем вывести языки программирования и связанные с ними инструменты.
Основываясь на этом диапазоне волатильности платформы, Java должна быть «очень страшной», в то время как котлин должен быть «низким» или выше. Котлин может иметь более высокий рейтинг, поскольку он внутренне опирается на другие инструменты, что увеличивает риск проблем совместимости.
Поскольку «очень странный» не обеспечивает рабочий фактор, нам нужна оценка.
Глядя на уменьшение правила фактора от «очень высокого» до «низкого», я думаю, что мы можем с уверенностью предположить, что оценка «очень страновочного» не выше 0,82.
Основываясь на этих предположениях (в пользу Kotlin), если проект требует рейтинговой рабочей нагрузки в 5 человек в год, то использование Kotlin составит 1044 человека в день, в то время как общая рабочая нагрузка на Java составляет 984 человека в день.
Выбор для реализации такого проекта с использованием Kotlin вместо Java увеличит общую рабочую нагрузку на 60 человек.
Дополнительная работа, вызванная языком и нестабильностью инструмента, более чем в два раза больше, чем работа уменьшается путем перехода на котлин.
Объединение всех факторов
Проект, который я обсуждал в качестве примера, требует рейтинговой рабочей нагрузки в 5 человек в год.
Согласно вышеуказанной оценке, если проект реализован с использованием Java разработчиком со средним 1 год опыта разработки Java, общая рабочая нагрузка составляет:
5 человек-год*ltex (java)*pvol (java) = 984 (день людей)
Если тот же проект реализован с использованием Kotlin разработчиком с небольшим опытом в разработке Kotlin, общая рабочая нагрузка:
5 человек-год*ltex (kotlin)*pvol (kotlin)*0,98+t_ramp_up = 1115+5*n_developers (человеческий-тов.
По оценкам, дополнительная рабочая нагрузка, вызванная выбором Kotlin для замены Java, составляет 131+5*n_developers (Man-Day).
Оценки мер предосторожности
Во время обсуждения в оценке мы придумали удобную одноточечную стоимость для рабочей нагрузки, связанной с Kotlin и Java.
Но на самом деле, одноточечные значения вообще не являются оценками - они просто догадываются. Реальная оценка должна иметь связанную неопределенность. Другими словами, оценки представляют собой диапазоны возможностей, а не единичные значения точек.
В итоге мы использовали единую точечную значения вместо диапазонов, потому что я выбрал наиболее благоприятное значение для котлина из диапазона оценки и преобразовал все оценки в одноцелевые значения.
Например, при обсуждении влияния Kotlin на деятельность по кодированию и отладки я выбрал максимальное значение повышения производительности на 10%от предполагаемого диапазона возможностей [-5%, 10%]. В других случаях, когда мы обсуждаем среднее время, когда разработчик переключается на Котлин, я выбрал наименьшие 5 дней из предполагаемого диапазона возможностей [5 дней, 21 дня].
Кроме того, мы использовали рабочий фактор, посвященный модели оценки COCOMO2. Эти факторы не являются универсальными истинами, и в самом общем случае также должна быть связанная неопределенность. Я присвоил Котлин более высокий рейтинг, чем я на самом деле думал, что это заслуживает, и я надеюсь убрать эту неопределенность таким образом.
Излишне говорить, что единственное значение, которое мы получаем, не является на 100% правильным. Чтобы получить более полную оценку, мы можем использовать реальную оценку для моделирования Монтекарло. Благодаря этой методике мы можем наблюдать распределение возможных результатов и выяснить, какие результаты наиболее вероятно произойдут.
Помните, что, поскольку мы сжимаем оценки в одно точечное значение, которое наиболее выгодно для Kotlin, другие возможные результаты будут показывать более высокие накладные расходы на коммутацию Kotlin. Следовательно, из всех возможных результатов, единственное значение точки, которое мы описали выше, наиболее выгодно для котлина.
краткое содержание
В начале статьи мы показываем некоторые субъективные суждения, которые могут вводить в заблуждение с сравнением разработчиков языков программирования.
Затем мы обсуждаем трудности в объективном сравнении языков программирования и проводим ряд оценок, чтобы выяснить общую рабочую нагрузку, необходимую для стека Kotlin и Java Stack для завершения программного проекта. При выполнении оценки мы всегда используем наиболее выгодное значение котлина в диапазоне оценки.
Благодаря нашему анализу переход с Java на котлин, по -видимому, приводит к увеличению общей рабочей нагрузки, необходимой для завершения программного проекта.
Большая работа означает, что предприятиям нужно потратить больше денег, чтобы переключиться на Котлин, чтобы получить те же функции, в то время как пользователи должны дольше ждать, чтобы получить продукт.
Некоторые разработчики могут быть удивлены и обнаружили, что этот результат нелегко принять.
После рассмотрения всех ситуаций, Google наконец решил поддержать развитие KotlinArroid. Google может понадобиться значительные инвестиции в это - нет ли в команде Google Cloud Platform, чтобы сделать аналогичный анализ, чтобы выяснить негативное влияние переключения на новый язык?
Я думаю, что сотрудники Google-все очень умные люди, и я считаю, что они провели очень углубленный анализ, прежде чем они решили поддержать Котлин.
Выше приведено все содержание этой статьи о субъективном и объективном сравнении и анализе котлин и Java. Я надеюсь, что это будет полезно для всех. Заинтересованные друзья могут продолжать ссылаться на другие связанные темы на этом сайте. Если есть какие -либо недостатки, пожалуйста, оставьте сообщение, чтобы указать это!