Masalah (seperti pemeliharaan) dalam pengembangan dengan bahasa yang tidak populer

Saya mengembangkan beberapa aplikasi dengan clojure (lisp) sendirian di tim saya. Dimulai sebagai aplikasi kecil. Tidak masalah. Tetapi karena memiliki fitur dan memperluas area, itu menjadi program penting.

Saya khawatir tentang pemeliharaan atau sesuatu. Tidak seorang pun di tim saya yang tahu clojure atau cadel juga tidak tertarik pada bahasa seperti mereka.

Jadi, bukankah salah melakukan pemrograman dalam bahasa yang tidak populer? (untuk kesenangan saya sendiri?) Haruskah saya menggunakan bahasa yang lebih populer? (setidaknya seperti python)

Saya yakin jika saya meninggalkan tim, - tidak mengatakan saya akan pergi. :)) - tidak ada yang akan mempertahankannya. Program ini akan dihancurkan dan beberapa akan dikembangkan dengan bahasa lain.

Saya sangat menikmati berkembang dengan clojure, saya menemukan bahwa ini mungkin bukan untuk tim saya.

Apa yang Anda pikirkan tentang ini? Saya pikir banyak programmer yang menyukai bahasa tidak populer telah membahas masalah serupa.

Saya merasakan sakit Anda, saya ingin melakukan lebih banyak pengkodean dalam pemrograman fungsional (Haskell terlihat sangat menyenangkan!). Saya merasa seperti baru saja menggaruk permukaan karena saya belum menggunakannya dalam konteks bisnis.

Saya akan sangat menyarankan untuk tidak melakukannya . Jika Anda memprogram dalam bahasa hanya Anda yang tahu maka hanya Anda yang dapat mendukungnya. Kecuali jika Anda ingin berurusan dengan setiap masalah dukungan (Bahkan ketika Anda memiliki tenggat waktu / prioritas lain) maka kode dalam bahasa tim Anda tahu dan dapat mendukung. Apa yang terjadi ketika sesuatu rusak saat Anda berlibur? Apa yang terjadi jika Anda ingin dipromosikan?

Saya akan merekomendasikan Anda membawa setidaknya satu anggota tim lainnya ke dalam kapal. Tunjukkan pada mereka beberapa fitur bahasa keren. Dengan dua orang di dalamnya, itu menjadi bisa diterapkan dan Anda tidak akan dimuat dengan semua dukungan.

Saya yakin jika saya meninggalkan tim, - tidak mengatakan saya akan pergi. :)) - tidak ada yang akan mempertahankannya.

Mungkin salah.

Jika program memiliki nilai, dan manajemen melihat nilai, mereka akan menugaskan seseorang untuk mempelajari Clojure dan memeliharanya.

Terjadi sepanjang waktu.

Program ini akan dihancurkan dan beberapa akan dikembangkan dengan bahasa lain.

Selalu benar. Jadi mengapa khawatir?

Semua program pada akhirnya harus diganti.

Saya tepat berada di tempat Anda membayangkan penerus Anda berada. Saya ditugaskan untuk menambahkan fitur ke program lawas yang menggunakan Clojure dan Erlang untuk melakukan pencarian tidak sinkron dan mengubahnya menjadi program yang mendistribusikan pencarian tidak sinkron. Ketika saya masuk ke pekerjaan ini, yang saya tahu hanyalah Python dan Java.

Saran saya kepada Anda: gunakan alat terbaik untuk pekerjaan itu . Jika alat itu adalah Clojure, maka jadilah itu. Bahasa pemrograman tidak terlalu sulit untuk dipelajari. Kode yang ditulis dengan baik dalam bahasa yang sesuai dengan tugas yang ada selalu lebih mudah dibaca daripada kode yang mencoba melakukan sesuatu yang tidak dirancang untuk dilakukan oleh bahasa tersebut. Akan lebih mudah bagi penerus Anda untuk membaca Clojure yang bersih daripada Java yang hancur.

Mengadopsi bahasa baru atau bahasa " berdiri sendiri " oleh beberapa tugas merupakan risiko tinggi dalam suatu proyek.

Jika bagian sistem itu memiliki masalah atau bagian itu harus diberhentikan, Anda harus mencari seorang programmer yang harus mempelajari keterampilan tentang bahasa itu. Dalam kedua kasus Anda kehilangan banyak waktu.

Dalam beberapa kasus masalah ini dapat digunakan untuk meningkatkan dan mendiversifikasi keterampilan tim dengan tugas di masa depan.

Clojure mungkin memiliki basis instalasi kecil saat ini (muncul pada tahun 2007) tetapi hampir tidak populer - bahkan itu mungkin bahasa baru "terpanas" di sekitar. Saya akan terkejut jika Anda tidak dapat menemukan orang lain tertarik untuk mempelajarinya.

Bagaimanapun, apakah akan mengadopsi bahasa baru namun harus selalu menjadi keputusan berdasarkan nilai pada bisnis . Anda dapat berdiskusi dengan manajer Anda di sepanjang baris berikut:

Keuntungan mengadopsi Clojure:

• Lebih produktif daripada bahasa lain yang digunakan - sebagaimana dibuktikan oleh jumlah fungsionalitas berguna yang Anda kirimkan dalam waktu yang sedikit dan dengan lebih sedikit baris kode
• Kami sudah memiliki satu aplikasi penting (milik Anda) yang ditulis dalam Clojure sehingga perlu untuk membangun keterampilan Clojure untuk mempertahankannya (daripada melakukan penulisan ulang yang mahal)
• Penggunaan Clojure akan dianggap inovatif dan mungkin cara yang baik untuk memotivasi pengembang berbakat untuk bergabung / menginap di perusahaan.

Kerugian mengadopsi Clojure

• Satu bahasa tambahan untuk mendukung
• Pengembang mungkin perlu lebih banyak pelatihan dan waktu untuk mempercepat

Jika saya adalah seorang manajer yang mengevaluasi keputusan ini, saya mungkin akan menyukai gagasan produktivitas yang lebih tinggi dari Clojure sehingga memungkinkan beberapa eksperimen terbatas, dan menunda keputusan itu sampai jelas seberapa baik tim mengambilnya. Dalam hal itu, Anda mungkin perlu menjadi advokat, bertindak sebagai guru yang baik dan membantu membawa yang lain masuk.

Jangan khawatir, bahagia.

Jelas program memiliki nilai, atau Anda tidak akan memperpanjangnya. Selamat atas proyek yang sukses. Mungkin Anda memilih Clojure karena menghemat waktu dan karenanya menghemat uang majikan Anda. Jika Anda telah menulisnya di Jawa, program itu akan menjadi lebih sulit untuk dikelola. Sekalipun kolega Anda dapat lebih mudah memahami program ini baris demi baris, apakah mereka dapat mempertahankan dan memperluasnya?

Saya akan mengatakan lebih banyak kekuatan untuk Anda! Lisp adalah Grandaddy bahasa komputer dan masih relevan saat ini; fakta bahwa itu tidak begitu populer saya pikir ini disebabkan oleh fakta bahwa itu tidak memiliki IDE yang lembut dari C # dan Java dan implementasi kompiler utama di Windows hanya berjalan di bawah Cygwin (yuk!). Pengembangan tampaknya berlangsung di Emacs dan saya kira itu bermain lebih baik dengan Linux atau Mac.

Kompetisi pengkodean ini dimenangkan oleh program Lisp pada 2010: http://planetwars.aichallenge.org/

Jauh di hari mereka bisa men-debug-nya langsung dari sekitar 100 juta mil: http://www.flownet.com/gat/jpl-lisp.html

Anda pasti mengesampingkan bendera merah pemeliharaan, tetapi menganggapnya sebagai memberikan kesempatan belajar bagi orang lain. Jika Anda menggunakan bahasa mimpi buruk (seperti MUMPS) atau bahasa yang membosankan (seperti TCL) maka saya pikir pertanyaan harus ditanyakan. Tapi saya pikir Anda harus dianggap sebagai seorang pria yang berusaha untuk menjunjung tinggi yang terbaik dari tradisi lama :)

Ada banyak jawaban bagus tapi saya ingin menambahkan satu poin.

Saya berada dalam situasi yang sama tetapi dengan bahasa yang berbeda. Saya harus belajar semuanya dengan cara yang sulit yaitu melalui metode coba-coba karena kurangnya bimbingan. Apa yang saya pelajari dari pengalaman saya ketika Anda menunjukkan pemeliharaan / ekstensibilitas akan menjadi masalah karena orang mungkin tidak mengetahui pendekatan yang efektif karena kurangnya bimbingan.

Saya sarankan Anda berbicara dengan manajer Anda untuk bantuan yang memadai sehingga Anda dapat menghindari masalah apa pun di masa depan.

Semoga berhasil!

Dalam beberapa kasus, bahasa seperti Lisp dapat membuatnya lebih cepat atau lebih mudah untuk mengimplementasikan fungsionalitas yang akan sangat sulit dalam bahasa yang berbeda. Ini juga memengaruhi cara Anda melihat masalah, memberi Anda perspektif yang mungkin tidak dimiliki orang lain di tim Anda. Memiliki berbagai kemampuan yang lebih luas dan pandangan yang lebih luas tentang apa yang mungkin bisa sangat berharga bagi perusahaan yang dapat memahami dan menggunakannya. Namun, harga untuk kemampuan itu adalah kurangnya standarisasi.

Banyak perusahaan mencoba untuk membakukan pada satu atau dua bahasa karena memberi mereka lebih banyak fleksibilitas organisasi: mereka dapat memindahkan pengembang dari satu proyek ke proyek lain tanpa harus melatih ulang mereka, mereka memiliki cadangan pengetahuan built-in tentang bahasa yang mereka gunakan, dan manajer tidak harus mempertimbangkan kekuatan dan kelemahan menggunakan satu bahasa atau lainnya untuk proyek tertentu. Ketika semua yang Anda miliki adalah palu, semuanya tampak seperti paku.

Seperti yang telah saya jelaskan, kedua pendekatan memiliki manfaat dan kelemahan tertentu. Seperti yang sering terjadi, tidak ada pendekatan yang benar atau salah. Anda hanya memperdagangkan satu set manfaat dan kelemahan untuk yang lain. Perusahaan tidak harus pergi sepenuhnya ke satu arah atau yang lain, baik. Sangat masuk akal untuk melakukan sebagian besar pekerjaan di C ++ atau Java, tetapi celupkan jari ke Lisp atau Python dari waktu ke waktu untuk mencobanya dan melihat apa yang berhasil. Sepertinya itu yang dilakukan perusahaan Anda.

Jadi maju (tapi jangan Keempat), pelajari sebanyak mungkin, dan jadilah ahli Clojure yang bisa diandalkan manajer Anda untuk mendapatkan wawasan yang mungkin tidak dimiliki rekan kerja Anda. Dan jangan merasa buruk tentang itu ... mengkhawatirkan hal-hal organisasi adalah pekerjaan manajer Anda.

Saya akan merekomendasikan untuk mulai menulis ulang program Anda dalam bahasa yang berbeda (lebih nyaman) ketika Anda mulai merasa bahwa pemeliharaan memiliki peluang besar untuk mendominasi masalah.

Jika Anda berhasil menulisnya secara tertutup (yang Anda tidak tahu kapan Anda mulai membuat aplikasi, seperti yang saya mengerti), maka tidak akan ada masalah untuk menulis ulang menggunakan bahasa yang lebih akrab / nyaman. Penutupan menggunakan konsep yang sangat berbeda dan karena itu implementasi mungkin sulit untuk ditransfer ke bahasa lain. Tetapi masalahnya adalah jika Anda bersenang-senang dengan menulis aplikasi baru di penutupan, maka Anda mungkin merasa tertarik untuk mentransfer konsep dan ide yang Anda gunakan ke bahasa lain yang nyaman. Mungkin menyenangkan untuk membandingkan berbagai bahasa dan kemampuan mereka. Saya pikir kasus Anda sangat cocok untuk eksperimen seperti itu.

Tentu saja tidak salah melakukan pemrograman dalam bahasa "tidak populer". Mengapa Anda benar-benar peduli apakah mereka populer atau tidak? Saya sepenuhnya setuju dengan @quanticle tentang ini. Jika Clojure atau bahasa non-mainstream lainnya adalah alat terbaik untuk masalah yang Anda selesaikan, Anda harus mengambilnya.

Saya tidak melihat mengapa pemeliharaan akan menjadi masalah. Jika Anda menerapkan Unit, Integrasi, dll. Menguji dan mendokumentasikan kode Anda, programmer mana pun yang berminat pada pemrograman fungsional akan dapat mempertahankan program Anda. IMHO fakta bahwa kolega Anda tidak peduli tentang Clojure bukanlah argumen yang baik untuk tidak menggunakannya, kecuali jika itu adalah kebijakan perusahaan yang harus Anda hormati.

Apakah program ini dilanjutkan atau tidak setelah keberangkatan Anda tidak menjadi perhatian Anda dalam pandangan saya. Anda dapat menggunakan bahasa pemrograman Anda untuk membuat sesuatu yang disukai bos Anda, kedengarannya cukup bagus bagi saya. Khawatir tentang kelanjutan adalah sesuatu yang harus dilakukan bos Anda.

Atur tutorial atau sesi pelatihan. Jika anggota tim Anda tidak ingin bertindak seperti profesional dan menambah pengetahuan mereka, terutama jika programnya menjadi lebih penting, itu tidak ada di tangan Anda. Dalam kasus terburuk, Anda dapat berbicara dengan manajemen dan mereka mungkin dapat mengamanatkan sesi pelatihan semacam ini. Anda mungkin terlihat seperti orang brengsek, tetapi setidaknya Anda tidak akan menjadi satu-satunya yang harus mempertahankan program. Pilihan lainnya adalah menyarankan agar programmer ke-2 yang tahu clojure ditambahkan ke tim.