एक नए JVM प्रोग्रामिंग भाषा का परिचय एक स्थापित उद्यम वातावरण में


11

कल्पना करें कि आपका वर्तमान कार्यस्थल एक जावा शॉप है। जावा भाषा के बारे में बहुत कुछ अंतर्निहित ज्ञान है और एक सहज और चुस्त तरीके से सब कुछ संभालने के लिए एक व्यापक निर्माण और परिनियोजन प्रक्रिया है।

एक दिन, एक प्रोजेक्ट आता है, जिसमें लिखा जाता है कि रूबी में लिखा है। केवल वरिष्ठ डेवलपर्स के पास रूबी के बारे में कोई सुराग है, लेकिन एक सामान्य धारणा है कि चूंकि JRM के लिए JRuby मौजूद है तो मौजूदा बुनियादी ढांचे का उपयोग और समर्थन जारी रखा जा सकता है। इसके अलावा, JRuby कम कोड के साथ वर्तमान अनुप्रयोगों को लागू करने के बेहतर तरीके को दिखा सकता है ताकि यह चल रहे प्रवास का प्रतिनिधित्व कर सके।

याद रखें कि JRuby केवल एक उदाहरण है, यह क्लोज़र या ग्रूवी या जो भी जेवीएम पर चलता है, उतना ही हो सकता है।

सवाल यह है कि आप इस तरह के बदलाव की शुरुआत कैसे करेंगे - अगर बिल्कुल भी?



1
कल्पना नहीं कर सकते हैं कि आप किस 'जावा' की दुकान के बारे में बात कर सकते हैं
गैरेथ डेविस

@ जोनास गुड लिंक - वहाँ पर चबाने के लिए बहुत कुछ।
गैरी रोवे

जवाबों:


15

डिस्क्लेमर: मैं पक्षपाती हूं क्योंकि मैं JVM (शमलेस प्लग !! - वेल-ग्राउंडेड जावा डेवलपर) पर पॉलीग्लॉट प्रोग्रामिंग पर एक किताब लिख रहा हूं :)

सबसे पहले, आपको केवल उस बदलाव को पेश करना चाहिए जहां यह वास्तव में वारंट है!

शुरुआत करने के लिए एक अच्छी जगह ओला बीनी की प्रोग्रामिंग भाषा पिरामिड पर विचार करना है। ओला स्थिर, गतिशील और डोमेन विशिष्ट भाषाओं के बारे में बात करता है।

जावा एक स्थिर भाषा है (सांख्यिकीय रूप से टाइप और प्रबंधित) और विभिन्न कारणों से (मैं बाद में जा सकता हूं यदि लोग रुचि रखते हैं) गतिशील परत परियोजनाओं (जैसे रैपिड वेब डेवलपमेंट) या डोमेन विशिष्ट परत परियोजनाओं (जैसे मॉडलिंग) के लिए एक आदर्श विकल्प नहीं है एंटरप्राइज़ इंटीग्रेशन पैटर्न डोमेन)। यदि आपके पास एक ऐसी परियोजना है जो उन परतों में से एक में फिट होती है तो वह शुरू करने के लिए एक अच्छी जगह हो सकती है।

यदि आप एक मूलभूत सुविधा है जो वैकल्पिक भाषा प्रदान करता है, तो जावा को बदलने के लिए स्थिर परत पर एक नई भाषा शुरू करने पर विचार कर सकते हैं। उदाहरण के लिए, Scala बस संक्षिप्त रूप में जावा से अधिक सुरक्षित और अधिक प्राकृतिक तरीके से काम करता है।

जैसा कि अनुरोध किया गया है, इस पर कुछ और। WRT जावा:

  • पुनर्नवीनीकरण श्रमसाध्य है
  • स्टेटिक टाइपिंग अनम्य हो सकती है और लंबे समय तक रिफैक्टरिंग समय तक ले जा सकती है
  • तैनाती एक भारी वजन प्रक्रिया है
  • DSL के उत्पादन के लिए जावा का सिंटैक्स प्राकृतिक रूप से फिट नहीं है

इस बिंदु पर, आप अपने आप से पूछ सकते हैं: “इन परतों के अंदर किस प्रकार की प्रोग्रामिंग चुनौतियाँ हैं? मुझे कौन सी भाषा चुननी चाहिए? ”, याद रखें कि कोई चांदी की गोली नहीं है, लेकिन मेरे पास कुछ मापदंड हैं जिन्हें आप अपनी पसंद का मूल्यांकन करते समय विचार कर सकते हैं।

डोमेन-विशिष्ट

  • निर्माण / सतत एकीकरण / सतत तैनाती
  • देव-ऑप्स
  • एंटरप्राइज इंटीग्रेशन पैटर्न मॉडलिंग
  • बिजनेस रूल्स मॉडलिंग

गतिशील

  • तीव्र वेब विकास
  • प्रोटोटाइप
  • इंटरैक्टिव प्रशासनिक / उपयोगकर्ता कंसोल
  • स्क्रिप्टिंग
  • टेस्ट ड्रिवेन डेवलपमेंट / बिहेवियर ड्रिवेन डेवलपमेंट

स्थिर

  • समवर्ती कोड
  • अनुप्रयोग कंटेनर
  • मुख्य व्यवसाय की कार्यक्षमता

एक छोटे से कम जोखिम वाले मॉड्यूल से शुरू करें (याद रखें, ये JVM भाषाएँ अक्सर मौजूदा जावा कोड को खूबसूरती से इंटरैक्ट करती हैं) या प्रोजेक्ट। यह स्पष्ट करें कि यह एक फेक प्रोटोटाइप होगा।

सुनिश्चित करें कि आपने उस भाषा के लिए प्रोग्रामिंग जीवनचक्र और टूलिंग पहलुओं की जांच की है। आप यह सुनिश्चित करना चाहेंगे कि आप टीडीडी बना सकते हैं, बिल्ड टूल्स और कंटीन्यूअस इंटीग्रेशन चला सकते हैं, शक्तिशाली आईडीई सपोर्ट और उन सभी अन्य कारकों को अपना सकते हैं। कुछ भाषाओं के लिए आपको बस यह स्वीकार करना होगा कि कुछ टूलींग नहीं है, या बहुत बुनियादी है। डेवलपर की ताकत और टूलिंग समर्थन एक भाषा की ताकत को पछाड़ सकता है।

सुनिश्चित करें कि एक जीवंत समुदाय है जो आपकी टीम की मदद कर सकता है जब वे फंस जाते हैं। स्थानीय उपयोगकर्ता समूह इसके लिए और भी बेहतर हैं।

सुनिश्चित करें कि डेवलपर्स को प्रारंभिक भाषा प्रशिक्षण मिलता है, खासकर यदि भाषा एक ओओ शैली की भाषा नहीं है (क्लोजर तक जाना गैर-तुच्छ है)।

इसके बारे में मुझे लगता है। मैंने व्यक्तिगत रूप से अपने विकास में जावा, एक्सएमएल प्रसंस्करण, त्वरित वेब साइटों के निर्माण और कुछ डेटा क्रंचिंग जैसे कार्यों के लिए जावा के साथ ग्रूवी, स्काला और क्लोजर का सफलतापूर्वक उपयोग किया है।


एक पूरी तरह से जवाब के लिए +1 - विशेष रूप से "क्लोजर पर जाना गैर-तुच्छ है"। मैं गतिशील परत / डोमेन विशिष्ट परत चयन मानदंड पर कुछ विस्तार की सराहना करूंगा। पुस्तक के साथ शुभकामनाएँ!
गैरी रोवे

@ गैरी रोवे - मैं चयन मानदंडों पर थोड़ा विस्तार करूंगा, 10-15 मिनट में फिर से जांच
करूंगा

@ अतिरिक्त जानकारी के लिए धन्यवाद, बहुत सराहना की।
गैरी रोवे

महान जवाब, मार्टिज़न, बहुत विस्तृत और अच्छी तरह से सोचा गया। शायद आपको इस सामान पर एक किताब लिखनी चाहिए! ;)
रीइन हेनरिक्स

@ अच्छी तरह से, मुझे यह स्वीकार करना होगा कि मैं अध्याय 7 के भाग को समझने में सक्षम था, जिसे इस प्रश्न पर चर्चा करने के लिए लिखा गया था;)
मार्टिज़न वर्बर्ग

3

मैं "अगर बिल्कुल" टिप्पणी के साथ उठाए गए विषय के बारे में कुछ विचार जोड़ना चाहूंगा। वास्तव में, टीम को अतिरिक्त भाषाओं का परिचय क्यों देना चाहिए? सच है, अगर आप किसी एक परियोजना को देख रहे हैं तो नई भाषा कार्य के लिए आदर्श उपकरण के रूप में सामने आ सकती है। लेकिन अगर आपके पास कई परियोजनाएं हैं, तो आप समय के साथ कुछ अतिरिक्त भाषाओं के साथ समाप्त हो सकते हैं। मुझे आपके रखरखाव चक्र और परियोजना संख्याओं के बारे में पता नहीं है, लेकिन संभावना है कि टीम को पहले की तुलना में अधिक भाषाओं में काफी विशेषज्ञता प्रदान करनी होगी।

व्यावसायिक दृष्टिकोण से, भाषाओं को जोड़ने का अर्थ है टीम में जटिलता और ज्ञान की आवश्यकताओं को जोड़ना। यह व्यावसायिक समायोजन की अवधि बढ़ाता है, आपकी टीम में विशेषज्ञों के अवकाश-आधारित (या स्थायी) प्रतिस्थापन को कठिन बनाता है और टीम के सदस्यों के लिए अतिरिक्त प्रशिक्षण की आवश्यकता होती है, जिसका अर्थ है अल्पावधि में धीमी गति से गिरावट।

मेरी नजर में, प्रस्तावना का स्वागत करने की रणनीति को विशुद्ध रूप से कार्यात्मक पहलुओं के अलावा ऐसे मुद्दों को स्वीकार करना चाहिए। क्या अतिरिक्त लाभ और मेरे द्वारा उल्लिखित लोगों की तरह नुकसान होने की उम्मीद है? यदि यह साबित किया जा सकता है, स्वीकृति दर बहुत अधिक हो सकती है। टीम के सदस्यों की योग्यता में उन अच्छे निवेशों की ओर इशारा करना भी मदद कर सकता है।


2

मैं कहता हूँ, किनारों के आसपास शुरू करो। कुछ गैर-उत्पादन कोड में भाषा दिखाएं जैसे कि स्क्रिप्ट, मावेन प्लगइन्स, रिपोर्ट रनिंग, आदि। एक बार जब वे उपयोगिता और सादगी देखते हैं, तो वे छोटे पैमाने पर प्रोजेक्ट और इतने पर अनुमति देने के लिए इच्छुक हो सकते हैं।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.