Представьте, что ваше текущее рабочее место - магазин Java. Существует много накопленных знаний о языке Java, и существует комплексный процесс сборки и развертывания, чтобы все было гладко и гибко.
Однажды появляется проект, который просто кричит, скажем, на Ruby. Только старшие разработчики имеют представление о Ruby, но есть общее мнение, что, поскольку JRuby существует для JVM, существующая инфраструктура может продолжать использоваться и поддерживаться. Кроме того, JRuby мог бы показать путь к лучшему способу реализации текущих приложений с меньшим количеством кода, чтобы это могло представлять непрерывную миграцию.
Помните, что JRuby - это просто пример, в равной степени это может быть Clojure или Groovy или что-то еще, что работает на JVM.
Вопрос в том, как бы вы внедрили такие изменения - если вообще?
источник
Ответы:
Отказ от ответственности: я пристрастен, поскольку я пишу книгу о программировании Polyglot на JVM (Бесстыдный плагин !! - Обоснованный Java-разработчик) :)
Во-первых, вы должны вносить изменения только там, где это действительно необходимо!
Хорошее место для начала - рассмотреть языковую пирамиду Олы Бини. Ола говорит о стабильных, динамических и предметно-ориентированных языках.
Java является стабильным языком (статически типизированным и управляемым), и по разным причинам (я могу перейти к ним позже, если кому-то интересно) не является идеальным выбором для проектов с динамическим уровнем (например, Rapid Web Development) или проектов уровня, специфичного для предметной области (например, моделирование). домен Enterprise Integration Pattern). Если у вас есть проект, который вписывается в один из этих слоев, то это может быть хорошим местом для начала.
Вы также можете рассмотреть вопрос о введении нового языка на стабильном уровне для замены Java, если есть фундаментальная особенность, которую предлагает альтернативный язык. Например, Scala просто обрабатывает параллелизм более безопасным и естественным образом, чем Java.
По просьбе, еще немного об этом. WRT Java:
В этот момент вы можете спросить себя: «Какие проблемы программирования подходят для этих слоев? Какой язык (языки) я должен выбрать? », Помните, что серебряной пули нет, но у меня есть некоторые критерии, которые вы могли бы учитывать при оценке своего выбора.
Предметно-ориентированные
динамический
стабильный
Начните с небольшого модуля низкого риска (помните, что эти языки JVM часто прекрасно взаимодействуют с существующим кодом Java) или проекта. Дайте понять, что это будет одноразовый прототип.
Убедитесь, что вы изучили жизненный цикл программирования и аспекты инструментов для этого языка. Вам нужно убедиться, что вы можете использовать TDD, запускать инструменты сборки и непрерывную интеграцию, иметь мощную поддержку IDE и все эти другие факторы. Для некоторых языков вам просто нужно признать, что определенного инструментария нет или он очень простой. Сила разработчика и инструментальная поддержка могут перевесить силу языка.
Убедитесь, что есть активное сообщество, которое может помочь вашей команде, когда они застрянут. Локальные группы пользователей даже лучше для этого.
Убедитесь, что разработчики проходят начальную языковую подготовку, особенно если язык не является языком стилей OO (переход на Clojure не тривиален).
Вот об этом я думаю. Лично я успешно использовал Groovy, Scala и Clojure в своей разработке вместе с Java для таких задач, как обработка XML, создание быстрых веб-сайтов и выполнение некоторого перебора данных.
источник
Я хотел бы добавить некоторые соображения по теме, поднятой с замечанием «если вообще». Действительно, зачем вводить дополнительные языки в команду? Правда, если вы просто смотрите на какой-то один проект, новый язык может оказаться идеальным инструментом для решения этой задачи. Но если у вас будет много проектов, со временем у вас может появиться немало дополнительных языков. Я не знаю о ваших циклах обслуживания и количестве проектов, но есть вероятность, что команде придется предоставить достаточно много знаний по большему количеству языков, чем раньше.
С точки зрения бизнеса, добавление языков означает добавление в команду требований к сложности и знаниям. Это продлевает периоды профессиональной адаптации, усложняет праздничные (или постоянные) замены специалистов в вашей команде и требует дополнительной подготовки для членов команды, что означает замедление в краткосрочной перспективе.
На мой взгляд, стратегия, направленная на то, чтобы приветствовать вступление, должна затрагивать и такие вопросы, помимо чисто функциональных аспектов. Означает ли ожидаемый выигрыш дополнительные хлопоты и недостатки, подобные тем, о которых я упоминал выше? Если это может быть доказано, показатели приемлемости могут быть намного выше. Также может помочь указание этих хороших инвестиций в квалификацию членов команды.
источник
Я бы сказал, начать по краям. Продемонстрируйте язык в некоторых непроизводственных кодах, таких как сценарии сборки, плагины maven, запуск отчетов и т. Д. Как только они увидят полезность и простоту, они могут быть более склонны к включению в мелкомасштабный проект и так далее.
источник