क्या टीम के प्रत्येक सदस्य को एक ही IDE का उपयोग करना चाहिए? [बन्द है]

Question

क्या आपको लगता है कि यह लागू करने के लिए समझ में आता है कि एक टीम के प्रत्येक सदस्य को एक ही आईडीई का उपयोग करना चाहिए?

उदाहरण के लिए, सभी इंजीनियर जो पहले से ही टीम में हैं, IDE X का उपयोग करते हैं। दो नए इंजीनियर आते हैं और इसके बजाय IDE Y का उपयोग करना चाहते हैं, क्योंकि अब वे कई वर्षों से उपयोग कर रहे हैं।

क्या आपके पास "मिश्रित आईडीई" टीमों के साथ कोई अनुभव है? यदि ऐसा है, तो ये क्या है?

Comments

मिश्रित-संपादक वातावरण के साथ मुझे जो समस्या हुई है वह कोड और टैब जैसी चीजों के उपचार के ऑटो-स्वरूपण की है। जब तक आपको वह सब सीधा मिलेगा, तब तक यह ज्यादा मायने नहीं रखेगा।

— माइकल कोहेन

Answer 1

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

Comments

यह सही जवाब है।

मुझे लगता है कि अगर आधिकारिक निर्माण प्रणाली एक आईडीई पर निर्भर करती है, तो एक समस्या है।

— एपीग्रामग्राम

जब आप टीम के अन्य सदस्यों के डेस्क पर बहुत समय बिताते हैं, तो इससे पहले कि आप उनकी मदद कर सकें उनके सेटअप का पता लगाना कष्टप्रद हो सकता है।

— डग टी।

हे भगवान!!! आंतरिक रूप से विकसित IDE ??? यह एक आपदा के लिए एक नुस्खा है, आंतरिक रूप से विकसित बग ट्रैकिंग सिस्टम की तरह।

— नौकरी

@Job, मैं Microsoft में काम करता हूं, इसलिए सख्ती से वीएस भी एक आंतरिक रूप से विकसित आईडीई है। हम आंतरिक रूप से विकसित बग ट्रैकिंग सिस्टम ... TFS और उत्पाद स्टूडियो :) का भी उपयोग करते हैं।

— JSB JS

Answer 2

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

Comments

यदि आपकी टीम कुछ भी गैर-तुच्छ के लिए आईडीई प्लगइन पर निर्भर करती है, तो आपके पास पहले से ही बड़े मुद्दे हैं।

— हेजमैज

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

— यूजीन

Answer 3

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

उस ने कहा, मैं अभी भी बहुत खुद का उपयोग करेंगे। बशर्ते आपकी जोड़ी केवल एक ही "ड्राइविंग" से खुश हो, विस्तारित अवधि के लिए यह ठीक है।

और मुझे पता है कि वीआईएल की तरह एक्लिप्स का काम करने के लिए प्लगइन्स हैं, लेकिन मैं जोड़ी बनाने के बारे में बात कर रहा हूं जहां मैं जाता हूं और किसी ऐसे व्यक्ति के साथ बैठता हूं जिसके पास एक्लिप्स काम करना पसंद है, इसलिए वे उस प्लगइन को इंस्टॉल नहीं करेंगे।

Answer 4

लिनक्स कर्नेल के प्रत्येक डेवलपर को एक ही आईडीई (या किसी भी आईडीई का उपयोग करने के लिए) को मजबूर करने के लिए बिल्कुल भी कोई मतलब नहीं होगा।

Answer 5

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

पेशेवरों

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

विपक्ष

• लाइसेंसिंग मुद्दे। यदि कई वाणिज्यिक आईडीई शामिल हैं, तो शायद यह अधिक महंगा है। कम से कम, यह ट्रैक रखने के लिए अधिक हो सकता है।
• लाइसेंसिंग के मुद्दे 2. अगर कोई फ्रेमवर्क या प्लग-इन हैं जो आईडीई या लैंगगॉज द्वारा लाइसेंस प्राप्त हैं, तो क्या यह एक समस्या होगी?
• जैसा कि डीज़ोर्डन ने उल्लेख किया है, कुछ प्लग इन अलग-अलग आईडीई के साथ संगत नहीं हो सकते हैं।
• यदि IDE में कोड जेनरेशन कंपोनेंट्स या स्टाइल फॉर्मेटिंग इंजन होते हैं जो चीजों को अलग तरह से करते हैं, तो इससे कुछ भ्रम हो सकता है।

Answer 6

एक कारण है जिसके लिए यह मजबूर हो सकता है। बस दृश्य स्टूडियो और emacs / विम पर विचार करें। जैसा कि विंडोज़ दृश्य स्टूडियो लाइन के अंत में एक अतिरिक्त \ r जोड़ देगा। यह emacs / विम में डिस्प्ले के साथ गड़बड़ करता है। इसके अलावा टैब समस्या पैदा करते हैं। हमारे साथ समस्या यह है कि हम डेवलपर्स लिनक्स में काम करते हैं लेकिन हमारे सॉफ्टवेयर आर्किटेक्चर दृश्य स्टूडियो में सहज हैं। वह एक बार हमें यह कहते हुए शाप देता है कि हम फ़ाइल को ठीक से प्रारूपित नहीं करते हैं। लेकिन तब जब उन्होंने पाया कि यह डिफ़ॉल्ट सेटिंग समस्या के कारण है, हम सभी एक ही प्रारूप के लिए सहमत हुए।
यदि कोई मुझे विशेष आईडीई का उपयोग करने के लिए मजबूर करता है, तो मुझे बुरा नहीं लगेगा। टीम के लिए जो भी अच्छा होगा मैं उसका सम्मान करूंगा और उसी के अनुसार समझौता करूंगा।

Comments

आप IDE उपयोग के साथ कोड स्वरूपण मानक को भ्रमित कर रहे हैं। यदि आप अपने इंडेंटेशन स्तर के लिए 3 रिक्त स्थान का उपयोग करने का निर्णय लेते हैं, तो आप विज़ुअल स्टूडियो या एमएसीएस (मुझे पता है, मैं उन दोनों का उपयोग करता हूं) में सेट कर सकता हूं। विंडोज, मैक और यूनिक्स में अलग-अलग लाइन एंडिंग जैसे अन्य मुद्दों को कस्टम चेक-इन / चेक-आउट स्क्रिप्ट द्वारा हल किया जा सकता है, अगर ओएस ==

— विंडोएज

Answer 7

आज के डेवलपर अपने स्वयं के उपकरण चुनना चाहते हैं।

हालांकि समय के साथ इसमें बदलाव आया है। 10 या 15 साल पहले उन जगहों पर उतने विकल्प नहीं थे जहाँ मैंने काम किया है। (हाँ बहुत सारे संपादक थे लेकिन वे 'पसंद' नहीं थे)। 15 साल पहले मैंने जिस दुकान पर काम किया था वह बहुत पुराना स्कूल था (तब भी!) और vi संपादक थे। कोई विकल्प नहीं। यह वास्तव में बहुत उपयोगी था, क्योंकि cussing और शपथ के पहले महीने के बाद मुझे वास्तव में यह पसंद आया।

आज, कई विकल्प हैं और प्रत्येक के कई फायदे हैं।

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

Answer 8

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

Answer 9

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

BTW, Emacs!

Answer 10

मुझे नहीं लगता कि सभी को "समान" आईडीई की आवश्यकता है, लेकिन यह अच्छा होगा कि सभी के पास "समर्थित" आईडीई था।

उदाहरण के लिए, यदि आपका आईडीई कोड समीक्षा प्रक्रिया में एकीकृत है जहां तक ​​टिप्पणी और अद्यतन कोड जाता है, तो यह सभी के लिए एक समर्थित मंच पर होने का अर्थ होगा।

यदि आपकी कंपनी एक सहयोगी वातावरण का उपयोग कर रही है जैसे कि तर्कसंगत टीम कॉन्सर्ट और एक या दो लोग एक असमर्थित आईडीई (या एक अलग संस्करण) का उपयोग करना चाहते हैं जबकि बाकी सभी संगत का उपयोग करते हैं, तो उन लोगों के लिए जीवन मुश्किल हो सकता है जिन्होंने चुना है समर्थन पाश के बाहर।

Answer 11

हमारे स्थान पर हम विजुअल स्टूडियो का उपयोग करके अपनी परियोजनाओं का निर्माण करते हैं। जब संपादन पाठ की बात आती है तो मैं Emacs पर स्विच कर देता हूं। आपकी कंपनी को तब तक देखभाल नहीं करनी चाहिए जब तक कि काम पूरा न हो जाए।

Answer 12

थोड़ा सा लगता है "हमने अपनी पुरानी नौकरी में इसका इस्तेमाल किया है"। खैर, वे अपने पुराने काम पर नहीं हैं।

यदि यह आपकी उपकरण श्रृंखला या स्रोत नियंत्रण प्लग.इन को प्रभावित नहीं करता है, तो शायद हाँ। तो फिर, क्या दो नए लोक एक स्पष्ट लाभ प्रदर्शित कर सकते हैं? क्या उन्होंने आपकी आईडीई का उपयोग किया है?

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

Comments

क्या कार्यस्थल पर लोगों की प्राथमिकताएं मायने नहीं रखतीं? क्या वरीयता बकवास है? क्या एक प्रोग्रामर कंपनी के लिए लाभ का संतोष नहीं है? मुझे खेद है लेकिन यह मेरे लिए "संकलन" नहीं है।

— daramarak

@daramarak: यह अहंकार में पार कहां जाता है या विशेष रूप से एक कॉर्पोरेट मानक के साथ बड़ी दुकानों के लिए एक प्राइम डोना है? याद रखें: एक नई कंपनी में चलने नए लोग कह "हम चाहते हैं इस" है अहंकार।

— gbn

Answer 13

हाँ! सिंगलटन आईडीई लागू करें।

प्रोजेक्ट की निर्भरता बदलने पर यह समस्याएँ खड़ी करता है। यदि कोई परियोजना के लिए एक नई निर्भरता का परिचय देता है, तो हर एक उस नई निर्भरता को पेश करने के लिए समय बर्बाद करेगा, और कुछ विफल हो सकता है और उस प्रक्रिया पर समय बर्बाद कर सकता है। समय के बड़े पैमाने पर।

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

Comments

एक आईडीई वास्तव में एक संपादक है। किसी भी तरह से एक संपादक परियोजना निर्भरता का गठन नहीं करता है। (मुझे पता है कि यह उत्तर व्यंग्यात्मक हो सकता है, हालाँकि, यह व्यंग्य के लिए जगह नहीं है)

— अरफांगियन

IDE वास्तव में एक संपादक नहीं है, क्योंकि आप "Notepad.exe" का उपयोग नहीं करते हैं। आपको आईडीई द्वारा किए गए अतिरिक्त काम की आवश्यकता है, और विचारधारा में मानक नहीं हैं, जिससे बाहरी क्षमता का उपयोग करना मुश्किल हो जाता है। और यदि आप कहते हैं कि हेक्स एडिट सिर्फ "टेक्स्ट एडिटर" है तो कोड सिर्फ टेक्स्ट नहीं है।

— डिस्प्ले नेम

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

— अरफांगियन

मुझे यहाँ लोग नहीं मिलते। वे कहते हैं कि एक आंतरिक विचारधारा खराब है, और एकसमान विचारधारा खराब है। इसलिए विचारक सभी प्रोग्रामर के लिए समान होना चाहिए, लेकिन सभी प्रोग्रामर के लिए नहीं जो एक ही प्रोजेक्ट पर काम करते हैं। हुह ?! मैं यह नहीं है!

— प्रदर्शन नाम

यह सिर्फ एक उपकरण है। किसी भी सक्षम प्रोग्रामर को अपने उपकरणों का उचित उपयोग करने में सक्षम होना चाहिए, और यदि उन्हें लगता है कि एक अलग आईडीई विकास के लिए अधिक उपयुक्त है, तो उन्हें ऐसा करना चाहिए।

— अराफंगियन