पर्ल ओओ

Question

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

मेरा प्रश्न है: क्या मैं (यदि ऐसा है) उन्हें सादा पर्ल ओओ से म्यू (से) में स्विच करने पर विचार करने के लिए मना कर सकता हूं? इसके क्या फायदे हैं? उन पर विचार करने के लिए मुझे वास्तव में अच्छे कारणों की आवश्यकता है।

क्या उन मॉड्यूल का उपयोग करने के साथ एक बड़ी लागत प्रदर्शन-वार है? मुझे अनुभव से पता है कि यह उन मॉड्यूल का उपयोग करने में बहुत सहज है (गुण भी वास्तव में अच्छे हैं), लेकिन मुझे डर है कि वे प्रदर्शन कारणों से स्विचिंग से इनकार कर देंगे।

तो। क्या कोई फायदा है और आप इसे पर्ल डेवलपर्स को कैसे वर्णन करेंगे, जो पूर्व 2000 युग में फंस गए हैं?

Answer 1

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

किसी को 'ओओ जाने' के लिए आश्वस्त करना अगर उन्होंने अपनी पर्ल समझ को बैश स्क्रिप्टिंग से पेर्ल हैकिंग में बनाया है ... एक चुनौती हो सकती है। वे अच्छी तरह से सही ढंग से हो सकते हैं - यह इंगित करते हैं कि स्विच करने के फायदे हैं, "सबसे कम आम denominator" लागू है। 'मूस' को जानने वाले लोगों की तुलना में बहुत से लोग 'गैर-मूस' पर्ल जानते हैं।(यह आपके पक्ष में गिना जा सकता है - यह इंगित करें कि यह एक उपयोगी तकनीकी विशेषज्ञता है जो भविष्य की नियोक्तायता में सुधार करता है)

आखिरकार, शैल स्क्रिप्ट का उपयोग आज भी क्यों किया जाता है - ऐसा इसलिए है क्योंकि वे एक सरल हैं, तत्काल समस्या के लिए सीधा और सुलभ समाधान।

तो पहले बंद करें - अपने कंप्यूटर विज्ञान सिद्धांतों को पेश करें। अपने सहयोगियों को उन चीज़ों में 'इन' खरीदने के लिए प्राप्त करें जिन्हें आप रेखांकित करते हैं। इसमें समय लगेगा। शायद बहुत समय। यदि कोड शैली 15 वर्षों तक नहीं बदली है, तो इसका मतलब है कि कोडर वहां चीजों के साथ सहज हैं।

फिर, आपको अपने सहयोगियों को साबित करने की आवश्यकता है कि 'आपका रास्ता' उनके लिए सीखने के लिए परेशान क्यों है। नई 'सामान' हर समय आती है, और हमेशा कोई ऐसा व्यक्ति होता है जो एक नई और अच्छी चीज को आजमाने की कोशिश करता है। आप उन्हें इस व्यक्ति की तरह दिखेगा। जहां तक ​​वे चिंतित हैं, वर्तमान 'घर शैली' ठीक काम करता है।

आप पाते हैं कि आपकी नई शैली में कुछ नया लागू करना विश्वासजनक है। अवधारणा के सबूत के रूप में इसे करने के लिए उन्हें 'खरीद' करने के लिए प्राप्त करें। आपको विचार जैसे कई अन्य कोडर भी मिल सकते हैं।

परवाह किए बिना - आपको बहुत वास्तविक संभावना को स्वीकार करना होगा कि कोई भी 'विरासत' के तकनीकी ऋण का भुगतान नहीं करना चाहता है जिसे आप ऐसा करके बनायेंगे। आपके संगठन में उपयोग में कोडिंग प्रतिमानों का सीमित सेट होने के कारण बहुत से व्यापार लाभ हैं। आपको इस बारे में सोचना होगा कि सेवा में दोनों कैसे काम कर रहे हैं।

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

Answer 2

मूस के लिए विशेष रूप से, PerlMonks और Stackoverflow पर प्रदर्शन की कुछ रोचक चर्चाएं हैं। ऐसा लगता है कि मूस के पास एक महत्वपूर्ण स्टार्टअप जुर्माना है, लेकिन उसके बाद बहुत कुछ नहीं है।

हालांकि, मुझे लगता है कि यहां एक बड़ा सवाल है: आपको मौजूदा कोड को फिर से लिखना चाहिए?

जब एक नया उपकरण/विधि को चुनने पर विचार करने के लिए दो विभिन्न द्वार हैं:

1. उपकरण/विधि XYZ फायदेमंद है, इसलिए हमने इसे इस्तेमाल करना चाहिए जब नए कोड लिखने।
2. टूल/विधि XYZ इतना फायदेमंद है कि हमें इसका उपयोग करने के लिए मौजूदा कोड को फिर से लिखना होगा।

कई, कई लोगों ने अपने पसंदीदा प्रतिमान का उपयोग करके पूरी तरह से अच्छे कोड के पूरे समूह को फिर से लिखने की गलती की है, जब मौजूदा प्रतिमान ठीक था। न केवल यह बर्बाद काम है, इसे नई बग पेश करने और अंतिम उत्पाद को इससे पहले की तुलना में खराब बनाने का खतरा है।

ऑब्जेक्ट सिस्टम को बदलना जो मौजूदा कोड बेस का उपयोग कोड के मौलिक पुनर्लेखन के करीब है। यह एक बड़ी लागत और जोखिम है, और आपको ऐसा करने के लिए बहुत अच्छे कारण की आवश्यकता है। सिर्फ "मूस कोड लिखने के लिए अच्छा है" से अधिक।

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