แนะนำภาษาการเขียนโปรแกรม JVM ใหม่ในสภาพแวดล้อมขององค์กรที่จัดตั้งขึ้น

ลองนึกภาพว่าที่ทำงานปัจจุบันของคุณคือร้านจาวา มีความรู้มากมายเกี่ยวกับภาษาจาวาและมีกระบวนการสร้างและปรับใช้ที่ครอบคลุมเพื่อจัดการทุกอย่างอย่างราบรื่นและคล่องตัว

อยู่มาวันหนึ่งโครงการก็มาพร้อมกับเสียงกรีดร้องออกมาว่าทับทิม เฉพาะนักพัฒนาอาวุโสเท่านั้นที่มีเบาะแสเกี่ยวกับ Ruby แต่มีความคิดทั่วไปที่ว่า JRuby นั้นมีอยู่สำหรับ JVM ดังนั้นโครงสร้างพื้นฐานที่มีอยู่จึงยังคงสามารถใช้และสนับสนุนได้ นอกจากนี้ JRuby ยังสามารถแสดงให้เห็นถึงวิธีการที่ดีกว่าในการนำแอปพลิเคชั่นปัจจุบันไปใช้กับรหัสที่น้อยลงดังนั้นนี่อาจเป็นตัวแทนของการย้ายข้อมูลอย่างต่อเนื่อง

โปรดจำไว้ว่า JRuby เป็นเพียงตัวอย่างมันอาจเป็น Clojure หรือ Groovy หรืออะไรก็ตามที่วิ่งบน JVM

คำถามคือคุณจะแนะนำการเปลี่ยนแปลงแบบนี้อย่างไร - ถ้าใช่?

ข้อความปฏิเสธความรับผิดชอบ: ฉันลำเอียงเพราะฉันเขียนหนังสือเกี่ยวกับการเขียนโปรแกรม Polyglot บน JVM (Shameless Plug !! - ผู้พัฒนา Java ที่มีเหตุผลดี) :)

ประการแรกคุณควรแนะนำการเปลี่ยนแปลงที่รับประกันอย่างแท้จริงเท่านั้น!

จุดเริ่มต้นที่ดีคือการพิจารณาปิรามิดภาษาการเขียนโปรแกรมของ Ola Bini Ola พูดถึงภาษาที่มีความเสถียรไดนามิกและโดเมนที่เฉพาะเจาะจง

Java เป็นภาษาที่มีเสถียรภาพ (พิมพ์แบบสแตติกและจัดการ) และด้วยเหตุผลต่าง ๆ (ฉันสามารถเข้าไปได้ในภายหลังหากผู้คนสนใจ) ไม่ใช่ตัวเลือกที่เหมาะสำหรับโครงการเลเยอร์แบบไดนามิก (เช่นการพัฒนาเว็บอย่างรวดเร็ว) หรือโครงการเลเยอร์เฉพาะโดเมน โดเมนรูปแบบการรวมเข้าด้วยกันขององค์กร) หากคุณมีโครงการที่เข้ากับเลเยอร์หนึ่งแล้วนั่นอาจเป็นจุดเริ่มต้นที่ดี

คุณยังสามารถพิจารณาการแนะนำภาษาใหม่ที่เสถียรเลเยอร์เพื่อแทนที่ Java หากมีคุณสมบัติพื้นฐานที่ภาษาทางเลือกให้ ยกตัวอย่างเช่น Scala จัดการกับภาวะพร้อมกันได้อย่างปลอดภัยและเป็นธรรมชาติมากกว่า Java

ตามที่ขอเพิ่มเติมเกี่ยวกับเรื่องนี้ Java WRT:

• การคอมไพล์ใหม่นั้นลำบากมาก
• การพิมพ์แบบสแตติกสามารถยืดหยุ่นและนำไปสู่การปรับเวลาให้ยาวนาน
• การปรับใช้เป็นกระบวนการหนา
• ไวยากรณ์ของ Java ไม่เหมาะกับการผลิต DSL

ณ จุดนี้คุณอาจถามตัวเองว่า:“ ความท้าทายในการเขียนโปรแกรมแบบใดที่อยู่ในเลเยอร์เหล่านี้? ฉันควรเลือกภาษาใด? "จำได้ว่าไม่มี bullet เงิน แต่ฉันมีเกณฑ์บางอย่างที่คุณสามารถพิจารณาได้เมื่อประเมินทางเลือกของคุณ

เฉพาะโดเมน

• การสร้าง / การรวมอย่างต่อเนื่อง / การปรับใช้อย่างต่อเนื่อง
• Dev-Ops
• แบบจำลองรูปแบบการรวมองค์กร
• การสร้างแบบจำลองกฎธุรกิจ

พลวัต

• การพัฒนาเว็บอย่างรวดเร็ว
• การสร้างต้นแบบ
• คอนโซลการดูแลระบบ / ผู้ใช้แบบโต้ตอบ
• การเขียนสคริปต์
• การทดสอบพัฒนาขับเคลื่อน / พฤติกรรมขับเคลื่อนพัฒนา

มีเสถียรภาพ

• รหัสพร้อมกัน
• แอพลิเคชันภาชนะ
• ฟังก์ชั่นธุรกิจหลัก

เริ่มต้นด้วยโมดูลความเสี่ยงต่ำ (จำไว้ว่าภาษา JVM เหล่านี้มักจะโต้ตอบกับโค้ด Java ที่มีอยู่อย่างสวยงาม) หรือโครงการ ทำให้ชัดเจนว่านี่จะเป็นต้นแบบการโยนทิ้ง

ตรวจสอบให้แน่ใจว่าคุณได้ตรวจสอบวงจรชีวิตการเขียนโปรแกรมและการใช้เครื่องมือสำหรับภาษานั้น คุณจะต้องแน่ใจว่าคุณสามารถใช้ TDD, รันเครื่องมือสร้างและบูรณาการอย่างต่อเนื่อง, มีการสนับสนุน IDE ที่มีประสิทธิภาพและปัจจัยอื่น ๆ ทั้งหมด สำหรับบางภาษาคุณต้องยอมรับว่าไม่มีการใช้เครื่องมือบางอย่างหรือพื้นฐานมาก จุดแข็งของนักพัฒนาและการสนับสนุนการใช้เครื่องมืออาจมีค่ามากกว่าความแข็งแกร่งของภาษา

ตรวจสอบให้แน่ใจว่ามีชุมชนที่มีชีวิตชีวาที่สามารถช่วยเหลือทีมของคุณเมื่อพวกเขาติดขัด กลุ่มผู้ใช้ภายในจะดียิ่งขึ้นสำหรับสิ่งนี้

ตรวจสอบให้แน่ใจว่าผู้พัฒนาได้รับการฝึกอบรมภาษาเบื้องต้นโดยเฉพาะอย่างยิ่งหากภาษานั้นไม่ใช่ภาษาสไตล์ OO (การย้ายไปที่ Clojure นั้นไม่ใช่เรื่องเล็กน้อย)

ฉันคิดว่าอย่างนั้นแหละ โดยส่วนตัวแล้วฉันใช้ Groovy, Scala และ Clojure ในการพัฒนาของฉันควบคู่ไปกับ Java สำหรับงานต่าง ๆ เช่นการประมวลผล XML การสร้างเว็บไซต์อย่างรวดเร็วและการทำ data crunching

ฉันต้องการที่จะเพิ่มความคิดบางอย่างเกี่ยวกับหัวข้อที่เกิดขึ้นด้วยคำพูด "ถ้าที่ทุกคน" แน่นอนทำไมเราควรแนะนำภาษาเพิ่มเติมให้กับทีม จริงถ้าคุณเพียงแค่ดูโครงการใด ๆ ภาษาใหม่อาจเป็นเครื่องมือที่เหมาะสำหรับงาน แต่ถ้าคุณจะมีหลายโครงการคุณอาจจบลงด้วยภาษาอื่น ๆ อีกไม่กี่ช่วงเวลา ฉันไม่รู้เกี่ยวกับรอบการบำรุงรักษาและหมายเลขโครงการของคุณ แต่โอกาสที่ทีมจะต้องให้ความเชี่ยวชาญในภาษามากขึ้นกว่า แต่ก่อน

จากมุมมองทางธุรกิจการเพิ่มภาษาหมายถึงการเพิ่มความซับซ้อนและข้อกำหนดด้านความรู้ให้กับทีม สิ่งนี้จะขยายช่วงเวลาของการปรับเปลี่ยนอาชีพทำให้การแทนที่ผู้เชี่ยวชาญ (หรือถาวร) ในช่วงวันหยุดของคุณยากขึ้นและจำเป็นต้องมีการฝึกอบรมเพิ่มเติมสำหรับสมาชิกในทีมซึ่งหมายถึงการชะลอตัวในระยะสั้น

ในสายตาของฉันกลยุทธ์ที่จะทำให้การเปิดตัวยินดีนั้นควรคำนึงถึงประเด็นดังกล่าวนอกเหนือจากการใช้งานอย่างหมดจดเช่นกัน การได้รับที่คาดหวังนั้นคุ้มค่ากับปัญหาพิเศษและข้อเสียเช่นเดียวกับที่ฉันได้กล่าวถึงข้างต้นหรือไม่ หากสามารถพิสูจน์ได้อัตราการยอมรับอาจสูงกว่านี้มาก การชี้ให้เห็นว่าการลงทุนที่ดีเหล่านี้ในคุณสมบัติของสมาชิกในทีมอาจช่วยได้เช่นกัน

ฉันจะบอกว่าเริ่มต้นรอบขอบ แสดงภาษาในโค้ดที่ไม่ใช้งานจริงเช่น build script, maven plugins, รายงานการทำงานเป็นต้นเมื่อพวกเขาเห็นยูทิลิตี้และความเรียบง่ายพวกเขาอาจมีแนวโน้มที่จะยอมให้โครงการขนาดเล็กและอื่น ๆ