Як ви заохочуєте вашу організацію перейти з Java на Scala? [зачинено]

Чи чиясь організація розпочала міграцію з Яви до Скали? Якщо так, то як це робити? Що я можу зробити, щоб заохотити колег зробити те саме?

Напевно, найпростіший спосіб - спочатку використовувати Scala лише для тестування. У цьому випадку, можливо, вам навіть не доведеться говорити своєму начальникові :-) Якщо він попросить, скажіть йому, "це лише мій приватний тестовий випадок, так набагато простіше і швидше використовувати Scala для цього". Як тільки у вас (і вашої організації) є достатній досвід роботи з Scala, ви можете почати використовувати її для «реального» коду.

З точки зору компаній, краще залишатися з Java, якщо немає явної переваги, яку вони отримають, переходячи до Scala. Їм легше найняти програмістів Java для створення та підтримки програми. Ви можете просто піти після впровадження всього в Scala :-) Без правопорушень :-)

Нехай ваш начальник читає такі переживання:

1. Наразі більшість моїх речей я зараз роблю в Скалі. (Я мушу зазначити, що я вважаю, що Scala - найкраща річ з часу створення колеса. :-D)

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

   Дивлячись на мови, які раніше заявляли щось подібне, я в основному бачу два конкуруючі табори мовного дизайну:

   • Ті з об'єктно-орієнтованої сторони, які бачили, що функціональне програмування останнім часом набуло певної тяги і подумали: "Ну, ми не дуже розуміємо цю функціональну річ, але давайте додамо до нашої мови якийсь симпатичний синтаксичний цукор, тому ми можемо стверджувати, що вона функціональна теж! " (приклади: Java, Python)

   • Тоді ті з функціональної сторони, які подумали: "Ну, наш функціональний підхід набагато перевершує будь-що інше, і це об'єктно-орієнтована нісенітниця дратує, але давайте вкладемо кілька додаткових ключових слів на нашу мову, які змусять нашу мову вийти з академічних наук напевно ! " (приклади: F #, OCaml)

   Дизайнери Scala уніфікували багато підходів, що виходили з обох сторін, і створили якусь добре розроблену мову, що є, на мою скромну думку, найбільшою відмінністю від інших мов, які вирішили застосувати "Франкенштейнський" підхід до розробки мови програмування.

2. Робивши з Ліфтом лише дрібніші речі та лише поверхневий досвід з Рейлами та Джанго, я мушу визнати, що більшість часу, коли я замислювався, чому щось у Ліфті працювало інакше, ніж я очікував, це було пов’язано з тим, що мої сподівання були помилка і підхід Ліфта перевершує.

   Ліфт, безумовно, не є легким вступом до Scala, але вивчення того, як працює Lift, було майже таким же корисним, як і вивчення Scala до цього.

   Можливість мати «чистий» погляд без будь-якої логіки в ньому - це велике вдосконалення для інших рамок, які стверджували те саме, але його не вистачало. Підтримка XML в прямому сенсі дозволяє перевірити чітко сформовану відповідь: компілятор докаже, що під час компіляції ви лише випромінюєте добре сформований XML клієнту.

3. Ліфт - це життєздатна технологія і на даний момент єдиний реальний підхід, якщо ви хочете створювати веб-додатки, які виглядають, відчувають себе та ведуть себе як "справжні" настільні додатки, не пишучи самих шалених кодів.

[ Джерело ]

Протягом останніх двох років ми просунулися на цьому шляху в Guardian.co.uk - наша відкрита платформа побудована на Scala, наша основна CMS (спочатку на Java) поступово включає все більше Scala (ми незабаром переходимо від Maven до SBT для нашого побудови), і це було чудовим досвідом - дійсно бадьорить наших дияволів, деякі з яких стали дещо заплутані від Java :)

Я б закликав вас прочитати ці дві статті про наш перехід і, можливо, використати їх як допоміжні докази зі своїми чіткими волоссям:

http://skillsmatter.com/podcast/home/how-we-moved-from-java-to-scala

http://www.infoq.com/articles/guardian_scala

Кілька швидких порад:

• Почніть з написання тестів у Scala - таким чином ви зможете ознайомитись з мовою, підвищити впевненість у ній і не потрібно перемогти будь-які побоювання, які можуть виникнути безпосередньо щодо додавання часу виконання на виробничі сервери.

• Не вимагайте дозволу на тестування нових технологій. Краще попросити пробачення, якщо доведеться :-)

Це питання голубці в іншому питанні. Тобто для яких видів чи проектів перехід на Scala надає додаткової вартості? Я займаюся Явою щоденною роботою, але мрію про день, коли я можу використовувати Скалу "в гніві".

Пара відповідає на моє власне питання:

• Проблеми, для яких одночасність базування акторів принесла б велику користь (Akka)

• Веб-додатки, ніж дані, що передаються до них через COMET (Lift)

Будь-які інші погляди чи ще краще досвід?

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

Я також почав робити прототипи і викидати POCs в Scala в основному виключно. Я намагаюся якомога більше усвідомити менеджерів та наглядачів, що я використовував Scala для цих одноразових підкреслень, і підкреслюю, що мені вдалося щось швидко почати працювати і працювати через Scala. Нам знадобився (ну, потрібний вид) веб-додаток для відстеження нашої відпустки гри білого слона - 1,5 години разом із Scalatra та MongoDB, і весь мій відділ бачить цей додаток і запитує про це. Подивимося, ми ніколи не дінешся, описуючи менеджерам, наскільки виразнішою є мова чи що її паралельна модель набагато краща. Але якщо ви їх покажете, то можете швидше зробити більше, ви отримаєте позицію.

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

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

Мені цікаво, чому вибирати те чи інше? Чому вирішили викинути Яву у двері та йти Скалою всю дорогу?

Немає такого ідеального інструменту для роботи. Немає підстав викидати експертизу з однієї мови повністю у двері та замінювати її іншою.

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

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

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

Звичайно, не очікуйте, що міграція відбудеться за один день. Ви можете недооцінити багато проблем: крива навчання, наявна база коду тощо.