Введення нової мови програмування JVM у створене корпоративне середовище

Уявіть, що ваше поточне робоче місце - це магазин Java. Існує багато вбудованих знань про мову Java, і є всебічний процес збирання та розгортання, щоб обробляти все плавно і спритно.

Одного разу приходить проект, який просто кричить, щоб його написали, скажімо, Рубі. Тільки старші розробники мають якусь підказку про Ruby, але існує загальне уявлення, що оскільки JRuby існує для JVM, то наявна інфраструктура може продовжувати використовуватися та підтримуватися. Крім того, JRuby може показати шлях до кращого способу реалізації поточних додатків з меншим кодом, щоб це могло представляти собою триваючу міграцію.

Пам’ятайте, що JRuby - це лише приклад, він однаково може бути Clojure або Groovy або будь-що інше, що працює на JVM.

Питання полягає в тому, як би ви почали впроваджувати такі зміни - якщо взагалі?

Відмова: Я упереджений, коли пишу книгу про програмування поліглотів на JVM (Shameless Plug !! - Добре заземлений Java Developer) :)

По-перше, вам слід ввести зміни лише там, де це справді виправдано!

Гарне місце для початку - розглянути піраміду мови програмування Ола Біні. Ola розповідає про стабільні, динамічні та доменні мови.

Java - це стабільна мова (статично набрана та керована), і з різних причин (я можу піти на них пізніше, якщо люди зацікавлені) не є ідеальним вибором для проектів динамічного рівня (наприклад, швидка веб-розробка) або проектів, що стосуються доменного шару (наприклад, моделювання домен шаблону інтеграції підприємств). Якщо у вас є проект, який вписується в один із цих шарів, то це може бути гарним місцем для початку.

Ви також можете розглянути можливість введення нової мови на стабільному шарі для заміни Java, якщо є основна функція, яку пропонує альтернативна мова. Наприклад, Scala просто обробляє сумісність безпечнішим і природнішим способом, ніж Java.

Як вимагається, ще дещо з цього приводу. WRT Java:

• Рекомпіляція трудомістка
• Статичне введення тексту може бути негнучким і призводити до тривалих часів рефакторингу
• Розгортання - це важкий процес
• Синтаксис Java не є природним придатним для створення DSL

На цьому етапі ви можете запитати себе: “Який тип програмних проблем відповідає цим шарам? Яку (-ю) мову я обрати? », Пам’ятайте, що немає срібної кулі, але у мене є деякі критерії, які ви можете врахувати, оцінюючи свій вибір.

Доменний

• Побудова / безперервна інтеграція / безперервне впровадження
• Дев-опс
• Моделювання моделей інтеграції підприємств
• Моделювання бізнес-правил

Динамічний

• Швидкий веб-розвиток
• Прототипування
• Інтерактивні адміністративні / користувацькі консолі
• Сценарій
• Тест-керований розвиток / Поведінка

Стабільний

• Паралельний код
• Контейнери для додатків
• Основна функціональність бізнесу

Почніть з невеликого модуля низького ризику (пам’ятайте, що ці мови JVM часто прекрасно взаємодіють з існуючим кодом Java) або проекту. Дайте зрозуміти, що це буде викинутим прототипом.

Переконайтесь, що ви дослідили аспекти життєвого циклу програмування та інструменти для цієї мови. Ви хочете переконатися, що можете TDD, запускати інструменти побудови та постійну інтеграцію, мати потужну підтримку IDE та всі ці інші фактори. Для деяких мов вам просто доведеться визнати, що певного інструментарію немає або є дуже базовим. Сила розробника та підтримка інструментів можуть переважати міцність мови.

Переконайтеся, що є яскрава спільнота, яка може допомогти вашій команді, коли вони застрягнуть. Місцеві групи користувачів для цього ще кращі.

Переконайтеся, що розробники отримують початкову мовну підготовку, особливо якщо мова не є мовою стилю OO (перехід на Clojure нетривіальний).

Саме про це я думаю. Я особисто успішно використовував Groovy, Scala та Clojure у своїй розробці разом із Java для таких завдань, як обробка XML, створення швидких веб-сайтів та певне стискання даних.

Я хотів би додати кілька думок щодо теми, порушеної із зауваженням "якщо взагалі". Дійсно, чому варто вводити додаткові мови в команду? Щоправда, якщо ви просто дивитесь на будь-який окремий проект, нова мова може залишатися ідеальним інструментом для виконання завдання. Але якщо у вас буде багато проектів, з часом ви можете створити досить багато мов. Я не знаю про ваші цикли технічного обслуговування та номери проектів, але, швидше за все, команді доведеться надати досить багато знань з мов, ніж раніше.

З точки зору бізнесу, додавання мов означає додавання команді вимог до складності та знань. Це подовжує періоди професійної адаптації, ускладнює обмінні (або постійні) заміни фахівців у вашій команді і вимагає додаткової підготовки членів команди, що означає уповільнення скорочення в короткостроковій перспективі.

На моїх очах, стратегія привітання вступу повинна також вирішувати такі питання, окрім суто функціональних аспектів. Чи варто очікувати додаткового прибутку додаткових клопотів та недоліків, як ті, про які я згадував вище? Якщо це можна довести, рівень прийняття може бути набагато вищим. Вказуючи, що ці приємні інвестиції в кваліфікацію членів команди також можуть допомогти.

Я б сказав, почніть по краях. Продемонструйте мову у такому невиробничому коді, як сценарії побудови, плагіни Maven, запуск звітів тощо. Після того, як вони побачать утиліту та простоту, вони можуть бути більш схильні дозволу на невеликі проекти тощо.