2009-02-26 8 views
5

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

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

आप कितनी बार नए आईडीई, संपादक, बग टकिंग टूल्स, डिबगर्स का प्रयास करते हैं? या अपने स्वयं के नए संस्करणों में अपडेट करें?

+0

हेक आईडीई के प्रोग्रामिंग से संबंधित कोई विषय नहीं है? –

उत्तर

1

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

+0

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

4

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

ध्यान दें कि परियोजनाओं के बीच बड़े बदलाव हो सकते हैं - एक नई परियोजना बिना किसी महत्वपूर्ण लागत के पूरी तरह से अलग वास्तुकला और टूलचेन पर व्यवस्थित हो सकती है। लेकिन यहां खून बहने वाले किनारे पर जाने के लिए सावधानी बरतनी चाहिए। एक ऐसे सेटअप के चयन को रोकने के लिए एक मूल्यांकन प्रक्रिया की आवश्यकता है जो परियोजना को बाद में परियोजना का समर्थन नहीं करेगा क्योंकि परियोजना जटिलता में बढ़ती है।

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

-Adam

3

मेरे लिए, उन्नयन घटना पर ही आधारित है। मैं अपने कान को नए उपकरण (पुस्तकालय, आईडीई, केस उपकरण इत्यादि) के लिए जमीन पर रखता हूं और उनका मूल्यांकन करता हूं क्योंकि वे मेरे रडार पर दिखाई देते हैं।

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

2

काम पर, हम एक उपकरण को अपग्रेड करते हैं जब हमारा संस्करण समर्थन जीवनकाल के अंत तक पहुंच जाता है। हम अगले पुराने संस्करण में अपग्रेड करते हैं।

घर पर, जैसे ही मैं नई चीज़ की प्रतिलिपि मुफ्त में प्राप्त कर सकता हूं (यानी कुछ सौदों जहां 3 वेबकास्ट में भाग लेना आपको बनाम 2008 std संस्करण, उपयोगकर्ता समूह इत्यादि की एक प्रति भेज देगा)।

3

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

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

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

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

आशा है कि मेरा $ 0.02 उपयोगी था।

1

IDEs - यह मुश्किल हो सकता है, लेकिन मैं पिछले कुछ वर्षों में कुछ अलग प्रगति के माध्यम से चले गए हैं। कभी-कभी किसी प्रोजेक्ट या विशिष्ट सुविधा पर होने पर अपग्रेड ट्रिगर हो सकता है। उदाहरण के लिए, किसी ने LINQ का उपयोग करके एक सुविधा लागू की है, इसलिए एएसपी.Net 2.0 प्रोजेक्ट क्या था, रातोंरात 3.5 प्रोजेक्ट बन गया। अन्य बार, यह वही है जो वर्तमान में उपयोग में है। यहां एक मुद्दा यह है कि एक परिवर्तन पूरी टीम को प्रभावित कर सकता है, इसलिए यह हल्के ढंग से बदलाव नहीं किया जा सकता है।

बग ट्रैकिंग टूल - यह भी केंद्रीकृत सामान की उस भूमि में है जिसे ध्यान से प्रबंधित किया जाना है। चूंकि यह एक क्यूए उपकरण है, इसलिए मुझे उम्मीद है कि उनकी अपनी नीतियां कितनी बार अपडेट की तलाश करेंगी और उन्हें इंस्टॉल करने के लिए जब कभी-कभी नई सुविधाएं प्राप्त करने के लिए ठंडा हो सकता है। विकी को अद्यतन करने के लिए देव टीम बराबर होगी।

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

ओएस - इस का हिस्सा एक विभाग के आधार पर नियंत्रित किया जा सकता है, वहीं काफी अलग टुकड़े अद्यतन करने के लिए है कि कभी कभी मैं अपने ही पर एक अद्यतन चलाने होगा। मुझे यकीन नहीं है कि जब हम विंडोज 7 पर जाएंगे, क्योंकि मुझे पता है कि हम Vista नहीं जा रहे हैं और मुझे लगता है कि हम किसी बिंदु पर XP को बंद कर देंगे क्योंकि मैं अब लगभग 5 वर्षों तक XP पर रहा हूं इससे पहले कि मैं विंडोज 2000 प्रोफेशनल पर कुछ साल और एनटी 4.0 से पहले था।

पीसी - एक नीति है कि हर 3 साल में हमें नई मशीनें मिलती हैं, मुझे विश्वास है। जब मैंने शुरू किया, तो मैं अब पी 4 बॉक्स पर था, इसलिए एक ड्यूल-कोर बॉक्स में अपग्रेड बहुत अच्छा था और 2 जीबी से 4 जीबी तक एक अच्छा रैम बूस्ट था।

संबंधित मुद्दे