एक बेहतर बग-फिक्सर बनना


24

मुझे प्रोग्रामर बनना बहुत पसंद है। वहां, मैंने कहा। हालांकि, उस के साथ, मैं हाल ही में महसूस किया है कि मैं वास्तव में बग फिक्सिंग बर्दाश्त नहीं कर सकता । बिलकुल।

वास्तव में, जब मैं कुछ विकसित कर रहा हूं, मेरी उत्पादकता बहुत अधिक है। यहां तक ​​कि जब यूनिट-परीक्षण लिखना और मेरे विकास का स्वयं परीक्षण करना, मैं आमतौर पर वास्तव में उत्पादक हूं। मैं अच्छी तरह से ध्यान केंद्रित कर सकता हूं, और मैं काम पूरा कर सकता हूं।

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

बगफिक्सिंग करते समय मैं अपनी उत्पादकता और प्रेरणा कैसे सुधार सकता हूं? क्या यह कुछ ऐसा है जिससे अधिकांश प्रोग्रामर निपटते हैं?


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

10
अपने कोड में बग न लिखें ... समस्या हल हो गई।
माइकल ब्राउन

3
मैं लगभग नए कोड लिखने के लिए बग फिक्स करना पसंद करता हूं। मैं विशेष रूप से इसे इकाई परीक्षण लिखने के लिए पसंद करता हूं। शायद मैं अजीब हूँ।
पॉल टॉम्बलिन

1
@PaulTomblin मैं समझता हूं कि आप क्या कह रहे हैं। मुझे पता है कि कुछ डेवलपर्स जो विकास को पसंद करते हैं ... मुझे गैर-यूआई कोड सबसे अच्छा लगता है। नया कोड लिखना कई बार कठिन होता है क्योंकि आपको कभी-कभी "लेखक का ब्लॉक" मिल जाता है
माइकल ब्राउन

1
बग-फिक्सिंग की "उत्पादकता" को मापना मुश्किल है क्योंकि आप यह जानने में बहुत समय बिता सकते हैं कि "समस्या नहीं" क्या है, ठीक उसी तरह जैसे एडिशन को कहा जाता है कि उसने पाया "1000 तरीके से प्रकाश बल्ब बनाने के लिए नहीं है" ", और मुझे लगता है कि गैर-फिक्स अक्सर आपको सिखाने में शिक्षाप्रद होते हैं कि क्या सुराग महत्वपूर्ण हैं और वर्तमान (और भविष्य) बग-फिक्सिंग कार्य।
ज़ेके हंसल

जवाबों:


21

यह बिल्कुल भी मज़ेदार नहीं है, जब आपको मामूली बदलाव करने हों और 30 सेकंड से 3 मिनट तक इंतजार करना हो, यह देखने के लिए कि क्या उन्होंने काम किया या नहीं

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

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

प्रतिक्रिया के लिए इतने लंबे समय तक इंतजार करना उबाऊ और नीरस है, न कि कीड़े को ठीक करने का कार्य।


कभी पौराणिक मानव-महीना पढ़ा? बस चित्र प्रतीक्षा 'अगली सुबह तिल और स्टैक डंप / रजिस्टर सामग्री का विश्लेषण करने की कोशिश कर रहा है जो विफलता के समय मौजूद थे ...
sq33G

@ sq33G या इससे भी बदतर, भारत में आपकी परीक्षण टीम है कि आप केवल ईमेल (वास्तविक कहानी) के माध्यम से बात करते हैं।
गैरेट हॉल

13

बग फिक्सिंग एक अत्यंत महत्वपूर्ण कौशल है जिसे आपको सीखना चाहिए। मैंने कहीं पढ़ा है कि आम तौर पर एक आवेदन में 20% मुद्दों को ठीक करने में 80% समय व्यतीत होता है।

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


1
आप जो लिखते हैं वह सच है; हालाँकि, आपका 80% / 20% केवल सच है क्योंकि जंगली में इतना भद्दा कोड है। गंदे से मेरा तात्पर्य है, अंडर-डिज़ाइन या ओवर-आर्किटेक्चरेड या मिस-आर्किटेक्टेड या सिर्फ सादे मैला व्यवहार (क्रैक-हेड प्रोग्रामिंग)। कहा जा रहा है, बग फिक्सिंग के विकास को प्राथमिकता देने वाले एक डेवलपर के साथ कुछ भी गलत नहीं है। इस तथ्य में जोड़ें कि अधिकांश सॉफ़्टवेयर प्रारंभ से खराब डिज़ाइन किए गए हैं और आप पहले से ही विफलता के लिए सबसे बग-फिक्सर्स सेट कर रहे हैं।
विल् मूर III

@wilmoore: आप भद्दे कोड के साथ सही हैं, और बदलती आवश्यकता भी है।
मनुक्प

6

व्यक्तिगत रूप से, मैंने बग को 'छोटी चीज़ों' के रूप में सोचना बंद करने में मददगार पाया है, लेकिन बड़े शोस्टॉपर्स के रूप में, जो बहुत बड़ी विशेषताओं के रूप में महत्वपूर्ण हैं, भले ही वे डीबगिंग के घंटों के बाद कोड की कुछ पंक्तियों को बदलने में शामिल हों। इस तरह, 3 बग ट्रैकर प्रविष्टियों को मारने के लिए एक पूरा दिन बिताने का तरीका कम निराशाजनक है (यह दृष्टिकोण आपकी व्यक्तिगत क्षमता पर थोड़ा निर्भर करता है कि वह खुद पर विश्वास कर सके :-)।

हो सकता है कि यह इसे एक खेल बनाने में मदद करता है, उदाहरण के लिए अपने सहकर्मियों के साथ मिलकर ( जो एक दिन में सबसे अधिक कीड़े को ठीक करता है? या इससे भी बदतर, जिसने एक दिन में सबसे कम संख्या में पुनर्निर्माण किया था? )


मैं इसे एक दिन में सबसे अधिक कीड़े, या उस की पसंद को ठीक करने का खेल बनाने से दृढ़ता से असहमत हूं। कुछ कीड़े अलग करने और उन्हें ठीक करने के लिए तुच्छ होते हैं जब आप जानते हैं कि उन्हें कैसे ट्रिगर किया जाए: उस विशेष मूल्य को इस क्षेत्र में पेस्ट करें, और देखें: शेष लंबाई अब गलत है। (हो सकता है कि आप वर्णों के बजाय बाइट्स गिन रहे हों और ऊपर की जगह के बारे में भूल गए हों, कहते हैं, U + 007F मैदान में होते हैं। वे दोनों बग ट्रैकर में केवल एक प्रविष्टि दर्ज करते हैं, हालांकि।
बजे एक CVn

इस तरह के कीड़े को समान रूप से गिनने का मतलब होगा कि हर कोई साधारण कीड़े को ठीक करने के बजाय यानी दौड़ की स्थिति से निबटेगा। :-) सरल चीजों के पक्ष में 'कठिन' बगों को शांत नहीं होने देना बिल्कुल अलग विषय है।
अलेक्जेंडर गेसलर

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

5

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

डिबगिंग बहुत थकाऊ हो सकती है, विशेष रूप से जटिल कोड के साथ जो आपने नहीं लिखा। एक लक्ष्य के साथ आओ, "शुक्रवार तक बग फिक्स 13533"। यदि आप लक्ष्य पूरा करते हैं, तो एक इनाम सेट करें, "शुक्रवार रात मेरे साथियों के साथ एक पिंट पकड़ो"। यह इसे थोड़ा अधिक पुरस्कृत करने में मदद करेगा।

इसके अलावा, कभी-कभी काम सिर्फ इतना है कि ... काम।


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

आपको उन लोगों को पकड़ने में मदद करने के लिए एक "अप्रत्याशित त्रुटि हैंडलर" दिनचर्या लिखने की आवश्यकता है
;;

2

इस प्रकार की स्थिति में आपको किसी प्रकार की रचनात्मक चुनौती की आवश्यकता होती है। आम तौर पर, यह कोड लिख रहा है, लेकिन यहाँ यह नहीं है।

पर अभी भी सब कुछ खत्म नहीं हुआ। अपनी मेटा-समस्याओं को हल करने पर काम करें और उसमें अपनी ऊर्जा डालें। प्रतिक्रिया प्राप्त करने में 30 सेकंड से 3 मिनट क्यों लगते हैं? आप उस समय को कैसे छोटा कर सकते हैं? (हो सकता है कि आप किसी तरह की स्क्रिप्ट या यूटिलिटी ऐप लिख सकते हैं, जिसे आप चेक नहीं करते हैं जो आपको ऐसा करने में मदद करता है)। यह आपकी नई समस्या डोमेन है - आपकी नई रचनात्मक चुनौती।

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

तो, संक्षेप में, मैं कहूंगा कि "हमेशा विकासशील रहें।" :)


मैं तुम्हें सुनता हूं। काश मैं चीजों को स्वचालित करने के लिए कुछ कर पाता। मुझे एक सर्वर और एक क्लाइंट मिला है, और मैं ग्राहक को आसानी से स्वचालित नहीं कर सकता। इस चीज़ के वर्कफ़्लो में कई चरण होते हैं और चरणों के बीच कई बग उत्पन्न होते हैं, इसलिए मुझे 30 सेकंड का चरण करना होगा, फिर 3 मिनट का चरण, या उल्टा करना होगा। निचला रेखा, यह बहुत बुरा सपना है :) :)
Naftuli Kay

2

क्या आपकी समस्या डीबगिंग या बग फिक्सिंग की है? यदि आप समस्या को उत्पन्न करने वाले घटक को अलग करने के लिए पर्याप्त डिबग कर सकते हैं, तो इसे एक नए विकास कार्य के रूप में देखें।

  1. कोड के सिर्फ टुकड़े के लिए कुछ इकाई परीक्षण लिखें जो टूट रहा है। सुनिश्चित करें कि आपके पास सभी वांछित कार्यक्षमता को मान्य करने वाले परीक्षण हैं, साथ ही कुछ जो विशेष रूप से छोटी गाड़ी के व्यवहार को अलग करते हैं।
  2. नया कोड लिखें जो आपके द्वारा लिखे गए सभी परीक्षणों को पास करता है।
  3. पुराने कोड को नए के साथ बदलें।
  4. कुछ एकीकरण परीक्षण चलाएं। यह वह जगह है जहाँ आप अपने तीन मिनट के सर्वर रिबूट में भाग लेंगे, लेकिन अगर आपने 1-3 अच्छी तरह से कदम उठाए तो इसे कम से कम किया जाना चाहिए।
  5. देखा!

2

शायद तुम ब्रायन हेस 'पर गौर करना चाहिए खुद डिबगिंग , एक लेख है कि 1995 में अमेरिकी वैज्ञानिक में छपी आप कदम उठाने (के अभ्यस्त उपयोग की तरह हो सकता है योदा स्थितियां कम या कीड़े की सबसे ज्यादा नफरत प्रकार आप का उत्पादन खत्म करने के लिए)।

मेरा विचार है कि डिबगिंग प्रोग्रामिंग से अलग कौशल है, हालांकि संबंधित है। विशेष रूप से, बहु-थ्रेडेड प्रोग्राम डीबग करना उन्हें लिखने से लगभग पूरी तरह से अलग है।


1

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


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

1
@ टीके: मेरी पिछली कंपनी में हमें पूर्ववर्ती मैनुअल प्रक्रियाओं को स्वचालित करने के लिए ग्रूवी को हमारे जावा विकास प्रक्रिया में एकीकृत करने में बड़ी सफलता मिली थी। यह जावा नहीं है, लेकिन यह काफी करीब था, और इतना प्रभावी था कि हमारे पास बहुत कम पुश-बैक था।
केविन क्लाइन

1

यह दुर्भाग्य से नौकरी का हिस्सा है। आपके पास भद्दे प्रोजेक्ट्स और भद्दे नियोक्ता होंगे (मैं यह नहीं कह रहा हूं या तो यहां मामला है, बस सामान्यीकरण)।

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

सुस्ती को ठीक करने के लिए डिबगिंग टूल का उपयोग करें, नए कोड का परीक्षण करने के लिए यूनिट परीक्षणों का उपयोग करें और मौजूदा कोड के मुद्दों को ठीक करने के साथ-साथ मौजूदा कोड को छोटे टुकड़ों में तोड़ने के लिए उपयोग करें।

आप इसे एक चुनौती बना सकते हैं और एक प्रक्रिया सुधार नायक बन सकते हैं। और, अगर यह काम नहीं करता है, तो आपके पास अगले नियोक्ता को लेने के लिए अच्छा अनुभव होगा।


1

अधिकांश प्रोग्रामर को अपने करियर में किसी समय बग फिक्सिंग व्यक्तिगत मुद्दों से निपटना पड़ता है।

आपकी प्रेरणा के लिए व्यक्ति-से-काम की दूरी का सही अर्थ आवश्यक है। अपने काम के साथ अधिक या कम न करें। यदि आप अपने काम के साथ खुद की पहचान कर रहे हैं, तो आपके द्वारा बताई गई समस्याएँ सतह पर आ सकती हैं: आप बग को ठीक करने के लिए बहुत अनिच्छुक हो सकते हैं क्योंकि आप खुद को दोष देने वाले समय के आधे हैं। कुछ आंतरिक दूरी प्राप्त करें और पता लगाएं कि आप तर्कसंगत रूप से अपनी समस्या पर कैसे काम कर सकते हैं।

आपके प्लेटफ़ॉर्म पर विशेष मुद्दों के बारे में, लंबे समय से तैनात और परीक्षण समय को कम करने के कुछ तरीके हैं (और, आपकी तरफ, विशेष रूप से लंबे समय तक नहीं हैं)।

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

दूसरे, पूर्वाग्रह इकाई परीक्षणों की ओर अधिक और एकीकरण परीक्षणों की ओर कम। हार्ड-टू-डीबग प्लेटफ़ॉर्म से हर बिंदु-विफलता को हटा दें।


1

बग फिक्सिंग "भयानक" या "थकाऊ" हो सकता है। मेरे पास कुछ गेम क्रेडिट हैं जो पूरी तरह से एक बग को ठीक करने के कारण हैं - क्रैश बग जिसे कोई और नहीं ठीक कर सकता है। लेकिन दिन-ब-दिन बुग्जिला का संवारना मन-सुन्न है। मामूली कीड़े थकाऊ होते हैं। प्रमुख कीड़े योग्य हैं।

यहाँ एहसास है: तथ्य यह है कि आप मामूली कीड़े की एक विशाल सूची है ही एक प्रमुख बग है। यह सिर्फ एक कोड बग नहीं है। इसकी एक प्रक्रिया या प्रबंधन बग।

उस बग को ढूंढें, और उसे ठीक करें।


1

एक बात मुझे सहकर्मियों और परिचितों के बीच मिली है जो अच्छे "डिबगर्स / बग फिक्सर्स / प्रॉब्लम सॉल्वर्स" हैं, वे आम तौर पर पहेलियों को हल करना पसंद करते हैं। इसका मतलब हो सकता है कि क्रॉसवर्ड पज़ल्स, नंबर गेम (जैसे सुडोकू) और लॉजिक पज़ल्स आदि ...

तो एक तरह से आप एक बेहतर बग फिक्सर बन सकते हैं जो आपकी समस्या को सुलझाने या पहेली सुलझाने के कौशल पर काम करने में कुछ समय बिताना होगा।

यहां एक विकिपीडिया लिंक दिया गया है जो चीजों के लिए एक अच्छा शुरुआती बिंदु हो सकता है जिससे आपको एक बेहतर समस्या हल करने में मदद मिल सके।

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


0

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

तो आप इसे कैसे मज़ेदार बनाते हैं? खैर, मैं वास्तव में इसका जवाब नहीं दे सकता क्योंकि मैं वास्तव में यह कल्पना नहीं कर सकता कि यह क्या है जो आपकी व्यक्तिगत नाव को तैरता है। मेरे लिए, मैं थोड़ा टूल जंकी हूं, इसलिए इसका उत्तर बहुत विश्वसनीय टूल चेन, और एक लचीली विकास प्रक्रिया में रहा है, जो बग को कम करने के लिए बग को ठीक करने में योगदान देती है, और अधिक बस एक समस्या को हल करने के लिए। सर्र से। मैं वर्तमान में ज्यादातर C # में विकसित कर रहा हूं, और मैं हमेशा ऐसे टूल्स की तलाश में रहता हूं, जो लेखन सॉफ्टवेयर के थकाऊ समय को नष्ट कर देगा। मैं StoryQ नामक एक बहुत ही अच्छे BDD API के साथ समर्थित पहले परीक्षण दृष्टिकोण का उपयोग करता हूं । मैं अपने रीफ्रैक्टरिंग और स्टाइलकॉप का ज्यादा इस्तेमाल करने के लिए रीशेयर का इस्तेमाल कोडिंग स्टाइल जैसी चीजों पर ढक्कन रखने के लिए करता हूं। उपकरण श्रृंखला में मेरा नवीनतम जोड़ शामिल करने के लिए किया गया हैNCrunch जो मेरे कोड को लगातार और समवर्ती रूप से पृष्ठभूमि में चलाता है, और यह वास्तव में NCrunch है जो गेम चेंजर साबित हुआ है।

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

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