अलोकप्रिय भाषा के साथ विकास में समस्याएं (जैसे रखरखाव)


31

मैं अपनी टीम में क्लोजर (लिस्प) के साथ कुछ एप्लिकेशन विकसित कर रहा हूं। यह छोटे अनुप्रयोग के रूप में शुरू होता है। कोई बात नहीं। लेकिन जैसा कि यह विशेषताएं हैं और क्षेत्र का विस्तार करते हुए, यह महत्वपूर्ण कार्यक्रम बन रहा है।

मैं रखरखाव या कुछ के बारे में चिंतित हूं। मेरी टीम में कोई भी क्लोजर या लिस्प को नहीं जानता है और न ही उनकी जैसी भाषाओं में दिलचस्पी है।

तो, क्या अलोकप्रिय भाषाओं में प्रोग्रामिंग करना गलत नहीं है? (अपनी मस्ती के लिए?) क्या मुझे अधिक लोकप्रिय भाषाओं का उपयोग करना चाहिए? (कम से कम जैसे कि अजगर)

मुझे यकीन है कि अगर मैं टीम छोड़ दूंगा, तो यह नहीं कहूंगा कि मैं जा रहा हूं। :) - कोई इसे बनाए नहीं रखेगा। यह कार्यक्रम नष्ट हो जाएगा और कुछ अन्य भाषा के साथ विकसित होंगे।

मुझे क्लोज़र के साथ विकसित होने में बहुत मज़ा आ रहा है, हालांकि, मुझे इस बात की जानकारी थी कि यह मेरी टीम के लिए नहीं हो सकता है।

आप इस बारे में क्या सोचते हैं? मुझे लगता है कि अलोकप्रिय भाषाओं से प्यार करने वाले कई प्रोग्रामर इसी तरह के मुद्दे से संबंधित हैं।


2
क्या आपके पास स्थानीय विकास के लिए भाषाओं के उपयोग के बारे में स्थानीय प्रोग्रामिंग मानक नहीं हैं?
मोहतरमा

नहीं, ऐसा कोई मानक नहीं है। मैंने सिर्फ अपने बॉस को बताया और इसे बिना किसी टिप्पणी के स्वीकार कर लिया गया। मुझे लगता है कि मेरे बॉस ने मेरे फैसले का सम्मान किया और अनुमति दी।
हाइब्रिड

12
"अलोकप्रिय" बड़ी समस्या नहीं है। "असमर्थित" बहुत बुरा है। जैसे लिस्प वीबी 6.0 हाथ नीचे मारता है।
एमएसएलटर्स

1
यदि एप्लिकेशन इतना महत्वपूर्ण है, तो वे आपको किसी ऐसे व्यक्ति से बदल देंगे जो जानता है कि वे क्या कर रहे हैं। सिर्फ इसलिए कि आपकी वर्तमान टीम सीमित है इसका मतलब यह नहीं है कि वे किसी को भी नहीं पा सकते हैं जो इस भाषा को जानता है।
जेफ़ओ

जवाबों:


22

मुझे आपका दर्द महसूस हो रहा है, मैं कार्यात्मक प्रोग्रामिंग में अधिक कोडिंग करना पसंद करूंगा (हस्केल बहुत मजेदार लगता है!)। मुझे ऐसा लगता है कि मैंने केवल सतह को खरोंच दिया है क्योंकि मुझे अभी तक इसे व्यावसायिक संदर्भ में उपयोग करना है।

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

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


8
मुझे असहमत होना पड़ेगा। यदि कोई भिन्न भाषा कार्य के लिए सही उपकरण है, तो उसका उपयोग करें। आधुनिक सॉफ्टवेयर विकास में बहुत सी आकस्मिक जटिलता प्रोग्रामर से आती है जिससे उनका पूरा आवेदन एक भाषा में फिट हो जाता है। उदाहरण के लिए, यदि आपकी भाषा खराब रूप से संक्षिप्त है, तो संदेश पासिंग को संभालने के लिए किसी अन्य भाषा का उपयोग करना काफी उपयुक्त हो सकता है।
19

@quanticle ओपी कहता है "तो, क्या अलोकप्रिय भाषाओं में प्रोग्रामिंग करना गलत नहीं है? (मेरी खुद की मजाक के लिए?)" यदि किसी अन्य भाषा जैसे कि संगामिति का उपयोग करने के लिए एक मजबूत मामला है तो मैं मानता हूं कि यह समर्थन समस्याओं के लायक होगा।
टॉम स्क्वायर्स

1
@quanticle: इसका विपरीत सत्य है: बहुत सी भाषाएं (यानी एक से अधिक) अतिरेक, नकली प्रयासों और अनावश्यक रूप से पहिए को फिर से मजबूत करने की ओर ले जाती हैं।
थॉमसएक्स

सही, समर्थन निश्चित रूप से महत्वपूर्ण है। मुझे बोर्ड पर टीम के अन्य सदस्यों को मिल रहे आपके सुझाव से प्यार है। मैं इस तरह के बारे में गहराई से सोचूंगा।
हाइब्रिड

17

मुझे यकीन है कि अगर मैं टीम छोड़ दूंगा, तो यह नहीं कहूंगा कि मैं जा रहा हूं। :) - कोई इसे बनाए नहीं रखेगा।

संभवतः मिथ्या है।

यदि कार्यक्रम का मूल्य है, और प्रबंधन मूल्य देखता है, तो वे किसी को क्लोजुर सीखने और इसे बनाए रखने के साथ काम करेंगे।

हमेशा होता है।

यह कार्यक्रम नष्ट हो जाएगा और कुछ अन्य भाषा के साथ विकसित होंगे।

अटल सत्य। तो इसकी चिंता क्यों?

सभी कार्यक्रमों को अंततः प्रतिस्थापित किया जाना चाहिए।


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

2
@DanNeely - आपको लगता है कि एक वैध रखरखाव पथ एक (बहुत ही शांत) होमब्रेव परियोजना के माध्यम से आईएल को क्लोजर संकलित कर रहा है और फिर उस कोड को सी # में अपघटित कर रहा है? मैं पूरी तरह से आश्वस्त नहीं हूं कि भाषा सीखने के लिए किसी से पूछना आसान है।

@ TheMouthofaCow मुझे संदेह है, विशेष रूप से एक बड़े आवेदन के लिए, क्लोझर सीखना आसान होगा; लेकिन बड़ा हथौड़ा दृष्टिकोण जिद्दी मोनो-लिंगुअल प्रोग्रामर को पूर्ण पुनर्लेखन की आवश्यकता के बिना संशोधन करने देगा। अंतत: रिफ्लेक्टिंग रिफ्लेक्टिंग क्रॉफ़्ट को हटाने से संभवतः एक वास्तविक तथ्य फिर से लिखना होगा; लेकिन पहले नई सुविधा को जोड़ने से पहले इसे पूरा करने की आवश्यकता के बजाय कई संशोधनों पर लागत को फैलाना।
डैन नीली

धन्यवाद। यह मेरे दिमाग में बहुत सहायक है। जैसा कि मैं किसी भी तरह इस स्थिति से गुजरता हूं, मुझे ऐसे आशावादी विचारों को भी ध्यान में रखना चाहिए।
हाइब्रिड

1
" सभी कार्यक्रमों को अंततः प्रतिस्थापित किया जाना चाहिए। " ओह, क्या यह सच था। बहुत से COBOL कोड चल रहे हैं जो डिस्क स्टोरेज के बहुत महंगे होने पर वापस लिखे गए थे, और जो Y2K (याद Y2K?) को जीवित रखने के लिए पैच किए गए थे, और वह अभी भी चल रहा है। वास्तव में, अधिकांश कार्यक्रम या तो युवा-अपाहिज से मर जाते हैं, या अनिवार्य रूप से हमेशा के लिए जीवित रहते हैं। इसलिए प्रौद्योगिकी का चुनाव वास्तव में बहुत महत्वपूर्ण है। क्योंकि आपकी संतान इन कार्यक्रमों को बनाए रख सकती है।
रॉस पैटरसन

10

मैं वास्तव में आप अपने उत्तराधिकारी की कल्पना कर रहे हैं। मुझे एक विरासत कार्यक्रम में सुविधाओं को जोड़ने का काम सौंपा गया था जो कि एसिंक्रोनस खोज करने के लिए क्लोजर और एरलांग का उपयोग करता था और इसे एक कार्यक्रम में बदल देता है जो अतुल्यकालिक खोज वितरित करता है। जब मैं इस नौकरी में आया, तो मुझे पता था कि अजगर और जावा।

आपको मेरी सलाह: नौकरी के लिए सबसे अच्छा उपकरण का उपयोग करें । अगर वह उपकरण क्लोजर है, तो ऐसा ही हो। प्रोग्रामिंग भाषाओं को सीखना मुश्किल नहीं है। किसी भाषा में लिखित कोड जो हाथ में कार्य के लिए उपयुक्त है, हमेशा उस कोड की तुलना में पढ़ना आसान होता है जो कुछ ऐसा करने का प्रयास करता है जिसे भाषा करने के लिए डिज़ाइन नहीं किया गया था। यह आपके उत्तराधिकारी के लिए आसान होगा कि वह क्लोज्ड जावा की तुलना में क्लीज को पढ़ें।


5

नई भाषाओं को अपनाना या किसी कार्य द्वारा " स्टैंड अलोन " भाषा को एक परियोजना में एक उच्च जोखिम है।

यदि सिस्टम के उस हिस्से में कोई समस्या है या उस हिस्से को खारिज कर दिया जाना चाहिए, तो आपको एक प्रोग्रामर ढूंढना होगा, जिसे उस भाषा के बारे में कौशल सीखना होगा। दोनों ही मामलों में आपने बहुत समय गंवा दिया।

कुछ मामलों में इस समस्या का उपयोग भविष्य के कार्य द्वारा एक टीम के कौशल में सुधार और विविधता लाने के लिए किया जा सकता है।


मैं मानता हूं, हालांकि मैं क्लोजर में विकसित होने वाले फायदों में से एक को अपनी टीम को प्रभावित कर रहा हूं। मैं यह भी मानता हूं कि यह एक उच्च जोखिम है। मुझे सावधान रहना चाहिए। धन्यवाद।
हाइब्रिड

4

क्लोजर का वर्तमान में एक छोटा स्थापित आधार हो सकता है (यह 2007 में दिखाई दिया) लेकिन यह शायद ही अलोकप्रिय है - वास्तव में यह संभवतः "सबसे गर्म" नई भाषा है। अगर आप इसे सीखने में दिलचस्पी रखने वाले अन्य लोगों को नहीं पा सकते हैं तो मुझे आश्चर्य होगा।

फिर भी, चाहे एक नई भाषा को अपनाना हो, लेकिन हमेशा व्यापार के लिए मूल्य के आधार पर निर्णय होना चाहिए । आप अपने प्रबंधक के साथ निम्नलिखित पंक्तियों पर चर्चा कर सकते हैं:

लौंग को अपनाने के फायदे:

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

क्लोजर अपनाने के नुकसान

  • समर्थन करने के लिए एक अतिरिक्त भाषा
  • गति बढ़ाने के लिए डेवलपर्स को अधिक प्रशिक्षण और समय की आवश्यकता हो सकती है

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


3

चिंता मत करो, खुश रहो।

स्पष्ट रूप से कार्यक्रम का मूल्य है, या आप इसे विस्तारित नहीं करेंगे। एक सफल परियोजना के लिए बधाई। संभवतः आपने क्लोजर को चुना क्योंकि ऐसा करने से समय की बचत हुई और इसलिए आपके नियोक्ता ने पैसा बचाया। यदि आपने इसे जावा में लिखा था, तो कार्यक्रम को बनाए रखना और भी कठिन होगा। यहां तक ​​कि अगर आपके सहकर्मी प्रोग्राम लाइन-बाय-लाइन को अधिक आसानी से समझ सकते हैं, तो क्या वे इसे बनाए रखने और इसका विस्तार करने में सक्षम होंगे?


2

मैं तुम्हें और अधिक शक्ति कहना चाहता हूँ! लिस्प कंप्यूटर भाषाओं का दादा है और आज भी प्रासंगिक है; तथ्य यह है कि यह इतना लोकप्रिय नहीं है कि मुझे लगता है कि इस तथ्य के कारण है कि इसमें C # और जावा के गर्म शराबी IDE नहीं हैं और विंडोज में मुख्य कंपाइलर कार्यान्वयन केवल Cygwin (yuk!) के तहत चलता है। विकास Emacs में जगह लेता है और मुझे लगता है कि यह लिनक्स या एक मैक के साथ बेहतर खेलता है।

इस कोडिंग प्रतियोगिता को 2010 में एक लिस्प प्रोग्राम द्वारा जीता गया था: http://planetwars.aichallenge.org/

जिस दिन वे इसे 100 मिलियन मील से जीवित कर सकते हैं उसी दिन वापस आएँ: http://www.flownet.com/gat/jpl-lisp.html

आप निश्चित रूप से एक रखरखाव लाल झंडा का इंतजार कर रहे हैं, लेकिन इसे किसी और के लिए सीखने का अवसर प्रदान करने के रूप में सोचें। यदि आप कुछ दुःस्वप्न भाषा (जैसे MUMPS) या कुछ थकाऊ भाषा (जैसे TCL) का उपयोग कर रहे थे तो मुझे लगता है कि प्रश्न पूछे जाने चाहिए। लेकिन मुझे लगता है कि आपको पुरानी परंपराओं का सबसे अच्छा पालन करने की कोशिश करने वाले व्यक्ति के रूप में सोचा जाना चाहिए :)


Tcl एक अच्छी भाषा है, मैं इसे थकाऊ नहीं कहूंगा। बस देखने के लिए टिंकर (अजगर में) देखें कि यह जानने के लिए एक अच्छा उपकरण है।
फ्रांसेस्को

@Francesco - मुझे कहना चाहिए कि मैंने कहा Tcl नहीं Tcl / Tk। चित्रमय टूलकिट महान हो सकता है। मैंने कहा कि Tcl उबाऊ था क्योंकि मैं कुछ साल पहले एक नौकरी के लिए इंटरव्यू के लिए गया था जो केवल Tcl का उपयोग करता है (वे जूनियर प्रोग्रामर में लेते हैं और फिर उन्हें छोड़ने के लिए एक बहुत ही बेकार भाषा सिखाते हैं) और नौकरी को ठुकरा दिया क्योंकि टीईसी थकाऊ लग रहा था। मैं यह नहीं कह रहा हूं कि यह कार्यात्मक नहीं है (यह हो सकता है) मैंने अभी सोचा था कि मैं अपनी बाहों को चबाना समाप्त कर दूंगा अगर मुझे कुछ दिनों से अधिक के लिए टीईसीएल लिखना पड़ा। मैं उसी से खड़ा हूं।

2

बहुत सारे अच्छे उत्तर हैं, लेकिन मैं एक बिंदु जोड़ना चाहूंगा।

मैं ऐसी ही स्थिति में रहा हूं लेकिन एक अलग भाषा के साथ। मुझे मार्गदर्शन की कमी के कारण परीक्षण और त्रुटि पद्धति के माध्यम से कठिन तरीके से सब कुछ सीखना पड़ा। मेरे अनुभव से मैंने जो सीखा '' जैसा कि आपने बताया कि रखरखाव / एक्स्टेंसिबिलिटी एक मुद्दा बन जाएगा क्योंकि मार्गदर्शन की कमी के कारण कोई भी प्रभावी दृष्टिकोण नहीं जान सकता है।

मेरा सुझाव है कि आप अपने प्रबंधक से पर्याप्त सहायता के लिए बात करें ताकि आप भविष्य में किसी भी समस्या से बच सकें।

सौभाग्य!


2

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

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

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

इसलिए आगे बढ़ें (लेकिन फोर्थ नहीं), जितना हो सके सीखें, और क्लूजुर विशेषज्ञ बनें जो आपके प्रबंधक अंतर्दृष्टि पर भरोसा कर सकते हैं जो आपके सहयोगियों के पास नहीं हो सकता है। और इसके बारे में बुरा मत मानना ​​... संगठनात्मक सामान के बारे में चिंता करना आपके प्रबंधकों का काम है।


1

मैं आपके कार्यक्रम को अलग (अधिक सुविधाजनक) भाषा में फिर से लिखना शुरू करने की सलाह दूंगा जब आप महसूस करना शुरू करेंगे कि रखरखाव में समस्या हावी होने की उच्च संभावना है।

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


मैं इसे काफी कम करता हूं। मैं लिखता हूँ कि पर्ल या एरलैंग में वन-शॉट उपयोगिता की तरह क्या लगता है, फिर यह अक्सर पर्याप्त उपयोग हो जाता है कि यह एक उपयोगिता बन जाता है, इसलिए मैं इसे प्रोजेक्ट की मुख्य भाषा (जावा या सी #) का उपयोग करके फिर से लिखता हूं।
TMN

1

"अलोकप्रिय" भाषाओं में प्रोग्रामिंग करना निश्चित रूप से गलत नहीं है। अगर आप लोकप्रिय हैं या नहीं तो आपको वास्तव में परवाह क्यों है? मैं इस पर @quanticle से पूरी तरह सहमत हूं। यदि क्लोजर या कोई अन्य गैर मुख्यधारा की भाषा आपके द्वारा हल की जा रही समस्या का सबसे अच्छा साधन है, तो आपको इसे चुनना चाहिए।

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


0

आपके जाने के बाद भी कार्यक्रम जारी रहता है या नहीं, इससे आपको मेरे विचार में कोई चिंता नहीं है। आप प्रोग्रामिंग भाषा का उपयोग कर सकते हैं जो आप अपने बॉस को पसंद करते हैं, मुझे बहुत अच्छा लगता है। निरंतरता के बारे में चिंता करना कुछ ऐसा है जो आपके बॉस को करना चाहिए।


3
निरंतरता की चिंता करना आपके बॉस का काम है। लेकिन यह सुनिश्चित करना आपका काम है कि बॉस को उन मुद्दों के बारे में पता होना चाहिए जिनके बारे में उन्हें चिंता करनी चाहिए। आपको बॉस के साथ इस पर बात करनी चाहिए।
मार्कज

मैं सहमत हूं, हालांकि ओपी को इस बारे में चिंता नहीं करनी चाहिए कि क्या बॉस कुछ नहीं करने का फैसला करता है।
पॉल हैमस्ट्रा 12

0

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

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