Bayangkan tempat kerja Anda saat ini adalah toko Java. Ada banyak pengetahuan yang dibangun tentang bahasa Jawa dan ada proses membangun dan penempatan yang komprehensif untuk menangani semuanya dengan lancar dan Agile.
Suatu hari, sebuah proyek datang yang hanya berteriak untuk ditulis, katakanlah, Ruby. Hanya pengembang senior yang memiliki petunjuk tentang Ruby tetapi ada anggapan umum bahwa karena JRuby ada untuk JVM maka infrastruktur yang ada dapat terus digunakan dan didukung. Juga, JRuby dapat menunjukkan jalan ke cara yang lebih baik dalam mengimplementasikan aplikasi saat ini dengan kode yang lebih sedikit sehingga ini dapat mewakili migrasi yang berkelanjutan.
Ingat bahwa JRuby hanyalah sebuah contoh, bisa juga Clojure atau Groovy atau apa pun yang berjalan di JVM.
Pertanyaannya adalah bagaimana Anda memperkenalkan perubahan semacam ini - jika memang demikian?
sumber
Jawaban:
Penafian: Saya bias karena saya menulis buku tentang pemrograman Polyglot di JVM (Shameless Plug !! - Pengembang Java yang Beralasan Baik) :)
Pertama, Anda hanya harus memperkenalkan perubahan yang benar-benar dijamin!
Tempat yang baik untuk memulai adalah mempertimbangkan piramida bahasa pemrograman Ola Bini. Ola berbicara tentang bahasa yang stabil, dinamis dan spesifik domain.
Java adalah bahasa yang stabil (diketik secara statis & dikelola) dan karena berbagai alasan (saya bisa membahasnya nanti jika orang tertarik) bukan pilihan ideal untuk proyek lapisan dinamis (mis. Pengembangan Web Cepat) atau proyek lapisan khusus domain (mis. Pemodelan domain Pola Integrasi Perusahaan). Jika Anda memiliki proyek yang cocok dengan salah satu lapisan itu maka itu bisa menjadi tempat yang baik untuk memulai.
Anda juga dapat mempertimbangkan memperkenalkan bahasa baru pada layer stabil untuk menggantikan Java jika ada fitur mendasar yang ditawarkan bahasa alternatif. Sebagai contoh, Scala hanya menangani konkurensi dengan cara yang lebih aman dan lebih alami daripada Java.
Seperti yang diminta, beberapa lagi tentang ini. WRT Java:
Pada titik ini, Anda mungkin bertanya pada diri sendiri: “Apa jenis tantangan pemrograman yang cocok di dalam lapisan-lapisan ini? Bahasa mana yang harus saya pilih? ”, Ingat tidak ada peluru perak, tetapi saya memang memiliki beberapa kriteria yang dapat Anda pertimbangkan ketika mengevaluasi pilihan Anda.
Khusus domain
Dinamis
Stabil
Mulailah dengan modul kecil risiko rendah (ingat, bahasa-bahasa JVM ini sering berinteraksi dengan kode Java yang ada dengan indah) atau proyek. Jelaskan bahwa ini akan menjadi prototipe yang dibuang.
Pastikan Anda telah menyelidiki siklus hidup pemrograman dan aspek tooling untuk bahasa itu. Anda akan ingin memastikan Anda dapat TDD, menjalankan alat membangun dan Integrasi Berkelanjutan, memiliki dukungan IDE yang kuat dan semua faktor lainnya. Untuk beberapa bahasa Anda hanya harus menerima bahwa alat tertentu tidak ada, atau sangat mendasar. Kekuatan pengembang dan dukungan tooling dapat melebihi kekuatan bahasa.
Pastikan ada komunitas yang bersemangat yang dapat membantu tim Anda saat mereka macet. Grup pengguna lokal bahkan lebih baik untuk ini.
Pastikan pengembang mendapatkan pelatihan bahasa awal, terutama jika bahasa tersebut bukan bahasa gaya OO (pindah ke Clojure adalah non-sepele).
Itu saja yang saya pikir. Secara pribadi saya telah berhasil menggunakan Groovy, Scala, dan Clojure dalam pengembangan saya bersama Java untuk tugas-tugas seperti pemrosesan XML, membangun situs web cepat dan melakukan beberapa pengelompokan data.
sumber
Saya ingin menambahkan beberapa pemikiran tentang topik yang diangkat dengan komentar "jika sama sekali". Memang, mengapa orang harus memperkenalkan bahasa tambahan ke tim? Benar, jika Anda hanya melihat proyek tunggal bahasa baru mungkin menonjol sebagai alat yang ideal untuk tugas tersebut. Tetapi jika Anda akan memiliki banyak proyek, Anda mungkin berakhir dengan beberapa bahasa tambahan dari waktu ke waktu. Saya tidak tahu tentang siklus pemeliharaan dan jumlah proyek Anda, tetapi kemungkinan tim harus memberikan cukup banyak keahlian dalam lebih banyak bahasa daripada sebelumnya.
Dari sudut pandang bisnis, menambahkan bahasa berarti menambah kompleksitas dan persyaratan pengetahuan bagi tim. Ini memperpanjang periode penyesuaian kejuruan, membuat penggantian spesialis yang berlandaskan liburan (atau permanen) di tim Anda menjadi lebih sulit dan membutuhkan pelatihan tambahan untuk anggota tim, yang berarti perlambatan dalam jangka pendek.
Di mata saya, strategi untuk membuat perkenalan disambut harus mengatasi masalah seperti itu selain dari aspek fungsional murni juga. Apakah keuntungan yang diharapkan sebanding dengan masalah ekstra dan kerugian seperti yang saya sebutkan di atas? Jika ini bisa dibuktikan, tingkat penerimaan mungkin jauh lebih tinggi. Menunjukkan investasi yang bagus dalam kualifikasi anggota tim dapat membantu juga.
sumber
Saya akan mengatakan, mulailah dari tepi. Pamerkan bahasa dalam beberapa kode non-produksi seperti skrip build, maven plugins, report running, dll. Begitu mereka melihat utilitas dan kesederhanaannya, mereka mungkin lebih condong ke proyek skala kecil dan sebagainya.
sumber