डिबगिंग कोड के तरीके (दुःस्वप्न की स्थिति)


16

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

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

  2. हमारे ऐप्स में वस्तुतः कोई लॉगिंग नहीं है। कोई यूनिट परीक्षण नहीं हैं।

  3. संस्करण नियंत्रण में केवल पूर्ण समाधान का 1 संस्करण है (स्रोत सुरक्षित 2005 का उपयोग करके)। इसलिए संपूर्ण समाधान के पिछले संस्करण को प्राप्त करना संभव नहीं है, केवल व्यक्तिगत फाइलें। (जब तक किसी को इसके आस-पास के तरीके न पता हों)।

  4. स्थानीय रूप से पुन: पेश नहीं किया जा सकता है, अक्सर बार परीक्षण वातावरण पर पुनरावृत्ति नहीं कर सकता है (उच्च मौका है कि परीक्षण और उत्पादन समान संस्करण नहीं हैं)।

  5. एक उच्च संभावना है कि क्लाइंट जिस संस्करण का उपयोग कर रहा है वह स्रोत सुरक्षित से अलग है। ऐसा इसलिए है क्योंकि व्यक्तिगत फ़ाइलें अपडेट की जाती हैं, जिसमें उस विशिष्ट क्लाइंट के लिए कस्टम तर्क एम्बेडेड होता है। अक्सर ऐसा होता है कि एक अपडेट एक बाइनरी के लिए किया जाता है, जिसमें कई अन्य बायनेरिज़ में बदलाव की आवश्यकता होती है, लेकिन जब एक प्रतिबद्ध किया जाता है, तो किसी के पास इसका कोई रिकॉर्ड या ज्ञान नहीं होता है। एक सामान्य त्रुटि जो मुझे दिखाई देती है वह है 'फंक्शन / मेथड नॉट फाउंड' या 'मेथड कॉल में क्लाइंट वातावरण पर बहुत अधिक / बहुत कम पैरामीटर निर्दिष्ट हैं'।

  6. यह एक .net VB समाधान है

  7. क्लाइंट साइटों पर कोई सॉफ़्टवेयर स्थापित नहीं कर सकता, लेकिन स्थानीय स्तर पर

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

  9. कोड में वस्तुतः कोई टिप्पणी नहीं है। वास्तुकला के बारे में कोई दस्तावेज नहीं है। एपी के बारे में कोई दस्तावेज नहीं। केवल एक चीज हमारे पास सैकड़ों ईमेल श्रृंखलाओं पर है जो कुछ हद तक समझाती है कि क्या चल रहा है। कोड को जानने वाले केवल वही लोग हैं जिन्होंने मूल रूप से इसे लिखा था, लेकिन वे अब प्रति डेवलपर्स नहीं कहते हैं, इसलिए वे इसमें शामिल नहीं होते हैं।

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

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

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


43
क्या आपके पास एक संक्षिप्त विवरण है?
रॉबर्ट हार्वे

5
+1 के लिए "मैं खुद को भी शूट करना चाहता हूं"। स्रोत सुरक्षित 2005, ouch। ठीक है, कम से कम आपको अद्भुत इतिहास पाठ पर 'ध्यान केंद्रित' करना चाहिए - आप मूल रूप से एक समय-यात्री हैं! आप ध्यान से विकसित ज्ञान के एक दशक के सबक सीखेंगे "तो यही कारण है कि हम अब ऐसा नहीं करते हैं"। गॉडस्पीड, टिड्डा।
BrianH

7
आवश्यकता को देखते हुए # 1 इस गंदगी को खत्म करने के लिए प्रभावी होने का एकमात्र तरीका क्लैरवॉयंट होना है। गंभीरता से, कोई जादू की गोली नहीं है जो इसे एक क्रेप्सूट के अलावा कुछ भी बनाने जा रही है। कुछ मायनों में यह आप से कुछ दबाव लेना चाहिए, क्योंकि डिबगिंग जरूरी भाग्य का विषय है। या आपका प्रबंधन आपको भाग्यशाली होने का आदेश देने वाला है? स्पष्ट रूप से यह स्थायी नहीं है, इसलिए आपको अन्य अवसरों की तलाश में रहना चाहिए।
चार्ल्स ई। ग्रांट

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

2
मैं इन स्थितियों का प्रबंधन कैसे करता हूं: अगर मुझे बाजार से ऊपर का भुगतान नहीं किया जा रहा है, तो मुझे कुछ और करना होगा।
केविन क्लाइन

जवाबों:


22

रॉबर्ट हार्वे की सलाह सर्वश्रेष्ठ होने की संभावना है, लेकिन चूँकि करियर की सलाह विषय से हटकर है, इसलिए मैं देता हूँ कि क्या जवाब दिया जा सकता है:

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

ऐसा लगता है कि आप वास्तव में जानते हैं कि चीजों को कैसे काम करना चाहिए । यदि कोई और आपकी मदद नहीं करेगा तो (फिर, कैरियर सलाह को अनदेखा करते हुए) आपकी एकमात्र पसंद खुद इन चीजों को ठीक करना शुरू करना है।

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

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

और परीक्षण लिखना शुरू करें, कम से कम आपके द्वारा किए गए नए परिवर्तनों के लिए।

इसमें कोई चीनी का लेप नहीं है: यहाँ कोई जवाब नहीं है जिसमें बहुत सारे काम शामिल नहीं हैं, या इसे कैरियर का प्रश्न माना जाता है।


मेरा विश्वास करो, मैं asserts, guards, और लॉगिंग को जोड़ने के अलावा और कुछ नहीं चाहूंगा, शायद डेटा परत को भी फिर से लिखो (मैं विशिष्ट कॉन्फ़िगरेशन मुद्दों का निदान करने के लिए कॉन्फ़िगरेशन सत्यापनकर्ता लिख ​​रहा हूं)। दुर्भाग्य से यह मेरे ऊपर नहीं है। मैं स्रोत को सुरक्षित रखने के लिए कुछ करने का अनुरोध कर सकता हूं, लेकिन विशिष्ट प्रतिक्रिया है 'आपके इरादे अच्छे हैं, लेकिन यह ऐसी चीज नहीं है जिस पर हमें ध्यान केंद्रित करना चाहिए।' काश, मैं 1/2 साल के अनुभव के साथ एक जूनियर हूं। मैं थोड़ी देर के लिए इस पहाड़ पर चढ़ूंगा।
Igneous01

9
@ Igneous01 ईमानदारी से, चढ़ाई करने के लिए एक अलग पहाड़ खोजने की कोशिश करें। अन्य स्थानों पर काम की स्थितियाँ एकदम सही नहीं हो सकती हैं, लेकिन मुझे लगता है कि आप जो अनुभव कर रहे हैं, उससे कम से कम बहुत बेहतर हैं। यदि आपके द्वारपाल आपके सुधारों को अस्वीकार कर देते हैं, तो "यह कोई ऐसी चीज नहीं है जिस पर हमें ध्यान केंद्रित करना चाहिए", यह उनके निर्णय लेने का निर्णय है, और वे उस असफल नीति के परिणामों को फिर से प्राप्त करेंगे (वे पहले से ही खोए हुए विकास के समय में टन पैसा खो रहे हैं) । सवाल यह है कि क्या आप उनके साथ तब तक रहना चाहते हैं जब तक वे ऐसा नहीं करते?
cmaster - मोनिका

6
और ध्यान रखें कि जब खराब नीतियां विफल होती हैं, तो इसमें शामिल सभी लोग बुरे लगते हैं, यहां तक ​​कि जो असहमत थे।
रोबोट

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

4
@ Igneous01: भागो, मत चलो। यह जगह बीमार है और आपको बीमार कर देगी।
मोनिका - एम। श्रोडर

8

1) ग्राहक साइट पर डीबगर का उपयोग नहीं किया जा सकता ...

यह पूरी तरह से सामान्य है।

... या स्थानीय स्तर पर

अब यह एक समस्या है।

2) हमारे ऐप्स में वास्तव में कोई लॉगिंग नहीं है।

लॉगिंग है उत्पादन डिबगिंग।

कोई यूनिट परीक्षण नहीं हैं।

बाप रे। सभी आम है, यद्यपि।

3) संस्करण नियंत्रण में पूर्ण समाधान का केवल 1 संस्करण है

तब आप संस्करण नियंत्रण का उपयोग नहीं कर रहे हैं।

4) स्थानीय रूप से पुन: पेश नहीं कर सकता है, अक्सर बार परीक्षण पर्यावरण पर पुनरावृत्ति नहीं कर सकता है (उच्च मौका है कि परीक्षण और उत्पादन समान संस्करण नहीं हैं)।

तो केवल तैनात, क्लाइंट वातावरण त्रुटियों को दिखाता है।

उस मामले में, आपको एप्लिकेशन कोड में एम्बेडेड अव्यवस्थित लॉगिंग की आवश्यकता होती है जो (ए) जाल और [पूरी तरह से] रिकॉर्ड [घातक] त्रुटियां और (बी) अतिरिक्त, निरंतर, निदान का उत्पादन करने की मांग पर "डायल किया जा सकता है" जो उपयोगी है । समस्या पर नज़र रखना।

5) एक उच्च संभावना है कि क्लाइंट जिस संस्करण का उपयोग कर रहा है, वह स्रोत सुरक्षित से अलग है।

फिर, आप केवल अपने लाभ के लिए संस्करण नियंत्रण का उपयोग नहीं कर रहे हैं।

8) हमारे आवेदन अत्यंत अनुकूलन है

यह काफी विशिष्ट है।

साइट-विशिष्ट अंतर को संस्करण नियंत्रण "शाखा" के माध्यम से प्रबंधित किया जाना चाहिए।

9) कोड में लगभग कोई टिप्पणी नहीं है।

फिर, यह सब बहुत सामान्य है, क्योंकि डेवलपर्स "स्व-दस्तावेजीकरण" कोड लिखते हैं, क्या वे नहीं?
या, कम से कम, कोड जो वे उस दिन समझते हैं कि वे इसे लिखते हैं।

वास्तुकला के बारे में कोई दस्तावेज नहीं है।

बाप रे।

एपी के बारे में कोई दस्तावेज नहीं।

हे प्रिय, हे प्रिय!

और इससे पहले कि आप इसे कहें ... हाँ मुझे पता है; मैं खुद को भी शूट करना चाहता हूं।

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

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

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

फंक्शन सिग्नेचर मिसमैच एक टूटे हुए निर्माण का कारण बनना चाहिए ; उन लोगों को "टूटे हुए निर्माण" का कारण बनना चाहिए और इसे कभी भी दरवाजे से बाहर नहीं करना चाहिए!


2
"हमेशा ऐसा कोड करें जैसे कि आपके कोड को बनाए रखने वाला व्यक्ति एक हिंसक मनोरोगी है, जो जानता है कि आप कहाँ रहते हैं"
पेरीसी

रक्षात्मक प्रोग्रामिंग की कमी से समझ की कमी के कारण रनटाइम त्रुटियां अधिक होती हैं। रक्षात्मक प्रोग्रामिंग इस तथ्य को छिपाने का एक तरीका है कि कोड काम नहीं करता है।
user253751

1
"आर्किटेक्चर के बारे में कोई दस्तावेज नहीं" का अर्थ आमतौर पर "नो आर्किटेक्चर" होता है ...
gnasher729

The site-specific differences should be managed through Version Control "Branching".- मुझे नहीं लगता कि यह आगे बढ़ने का सबसे अच्छा तरीका है। कॉन्फ़िगरेशन फ़ाइलों और फ़ीचर टॉगल का उपयोग करना अधिक सामान्य और आसान लगता है।
साठफुटेर्सडूड

5

लॉगिंग से शुरू करें। इसका सबसे ज्यादा असर पड़ेगा। कोड आधार में एक लॉगिंग फ्रेमवर्क को लागू करें, जैसे लॉग 4नेट या इसी तरह। कोड क्या करता है लॉगिंग शुरू करें।

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

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

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

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

आवश्यकतानुसार किसी भी आदिवासी ज्ञान का दस्तावेज। कोड स्व दस्तावेज होना चाहिए ताकि टिप्पणियां विरल हों, लेकिन कई प्रणालियों में चीजों को करने के "असामान्य" तरीके हैं, जो कोडिंग WIKI या अन्य प्रकार के अनौपचारिक भंडार में इंगित करते हैं। इसके अलावा, कोडिंग मानकों और प्रथाओं के साथ आने पर विचार करें। Resharper जैसे टूलसेट के माध्यम से उन मानकों को लागू करें। चूंकि अधिकांश कोड शायद किसी भी मानक और दिशानिर्देशों का पालन नहीं कर रहे हैं, इसलिए नए कोड पर लिखे गए मानकों को लागू करें।

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


4

सबसे पहले, उपरोक्त सभी ... डिट्टो।

कुछ अनुमान:

  • अपने विकास के कंप्यूटर पर स्रोत नियंत्रण का उपयोग करें। यह सबसे अच्छी बात है जो मैंने किया है। यह परियोजना के संस्करण नियंत्रण का विकल्प नहीं है, जो हमारे पास है। यह एक ऐसा उपकरण है जो निडरता से प्रयोग करने, हैक करने, काम की समस्याओं को एक साथ स्वतंत्र रूप से करने की अद्भुत स्वतंत्रता देता है, आदि मैं संस्करण नियंत्रण का उपयोग करने में बेहतर हूं क्योंकि मुझे बोल्ड होने, स्क्रू अप करने और सीखने की स्वतंत्रता है।
  • आप टिप्पणियों को जोड़ने के लिए, अंतरंगता का लाभ लेने के लिए सार्वजनिक इंटरफ़ेस तत्वों को प्राथमिकता देते हैं। अपने डिबग एडवेंचर्स के दौरान आप जैसा करते हैं, वैसा ही करें।
  • मामूली रिफ्लेक्टरिंग के साथ लगातार बने रहें। जल्दी या बाद में, कोड के दिए गए हंक के लिए, आप एक महत्वपूर्ण द्रव्यमान प्राप्त करेंगे जो कक्षाओं में निरर्थक कोड को DRYing जैसे बड़े रिफैक्टोरिंग को सक्षम बनाता है।
  • एक ही संस्करण नियंत्रण के कमिट में कोड सुधार और वास्तविक परिवर्तनों को न मिलाएं।
  • ठोस सिद्धांत
    • एकल जिम्मेदारी को कभी भी नजरअंदाज न करें। ठीक है, यह वस्तु उन्मुख के वादे का मार्ग है; IMHO।
    • हमेशा खुले / बंद को अनदेखा करें।
    • हम यहां नया कोड नहीं बोल रहे हैं।
    • उद्देश्यपूर्ण डिजाइन के बिना इंटरफेस बनाना रखरखाव में बाधा डालता है।
  • पुनर्रचना
  • डिबगिंग का प्रयास करने से पहले कुछ कोड फ़ाइलों को पूर्ण पुन: स्वरूपण, परिवर्तनशील नामकरण आदि की आवश्यकता होती है। इकाई परीक्षणों के बिना दृश्य स्टूडियो के रिफलेक्टर मेनू का उपयोग करने में शर्म न करें।
  • केवल प्रलेखन जो गलत नहीं किया जा सकता है वह कोड फाइलों में है।
  • जब आप संस्करण नियंत्रण प्राप्त करते हैं तो वीसी की योजना को पूर्व-निर्धारित कर देते हैं। और यह दस्तावेज! और शाखाओं के लिए एक नामकरण सम्मेलन के साथ आते हैं, टैग जो प्रमुख सॉफ़्टवेयर संस्करणों और मील के पत्थर को उजागर करेंगे।
  • अच्छे उपकरणों का उपयोग करें
  • रबर डकी डिबगिंग का अभ्यास करें
  • कभी-कभी सबसे बुरी बात यह हो सकती है कि वे आपको आग नहीं देते।

संपादित करें

.NET में ब्राउनफील्ड अनुप्रयोग विकास

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

इसे चिपका कर

रहो, कहो, 1.5 साल अगर आप कर सकते हैं; यह जानने के लिए पर्याप्त है कि क्या आप अनुभवात्मक प्रगति कर रहे हैं। आपको पता चल जाएगा कि आपको 4 साल का 2 साल का अनुभव या 6 महीने का अनुभव मिल रहा है।

"1/2 वर्ष के अनुभव के साथ जूनियर" होने के नाते मुझे चिंता है कि एक संभावित नियोक्ता इसे जल्दी से बाहर निकलते हुए देखेगा क्योंकि आप इसे हैक नहीं कर सकते। यह कहना एक बात है कि आपने z, y, x सीखे, कुछ नाम लिए और कुछ गधे को लात मारी - लेकिन आपकी क्षमताओं में योगदान करने की अनुमति नहीं थी; और एक और बस स्पष्टीकरण के माध्यम से नौकरी, कोड, प्रबंधन, आदि को खारिज कर दिया।

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

अंत संपादित करें


+1 फॉर कोड मिक्स रिफॉर्मेटिंग और वास्तविक बदलावों को एक ही वर्जन कंट्रोल में नहीं मिलाते हैं।
किवीरॉन

0

मैं कहूंगा (5) वह है जिसे आपको पहले ठीक करने की आवश्यकता है। यदि आपको पता नहीं है कि उत्पादन में कौन सा कोड चल रहा है, तो आपके पास समस्याओं को दोहराने और ठीक करने का कोई सुरक्षित तरीका नहीं है। यह आपके द्वारा खतरनाक पेश किए जाने वाले किसी भी अन्य परिवर्तन को बनाता है, क्योंकि यह उन समस्याओं का कारण हो सकता है जिन्हें आप दूर नहीं कर सकते हैं और पुन: पेश नहीं कर सकते हैं।

आपको कुछ जासूसी कार्य करने की आवश्यकता हो सकती है और कोड के कौन से संस्करण (ओं) और कौन से पुस्तकालयों को तैनात किया गया है, यह पता लगाने के लिए शायद रिवर्स इंजीनियरिंग करना होगा। (और आगे बढ़ने वाले स्रोत नियंत्रण के अनुरूप सभी तैनात कोड को लाने के लिए आपके पास एक सुसंगत निर्माण और तैनाती प्रणाली की आवश्यकता है।)

विभिन्न तैनाती को दोहराने के लिए आपको कई परीक्षण वातावरण बनाने पड़ सकते हैं। (निश्चित रूप से सबसे सरल फिक्स एक नया स्वच्छ निर्माण करना और इसे हर जगह लगातार तैनात करना है, लेकिन ऐसा लगता है कि यह संभव नहीं है?)

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

आपकी अगली प्राथमिकता एकल कोड आधार को समेकित करना होनी चाहिए जिसे हर जगह तैनात किया जा सकता है। ऐसा लगता है कि आपके पास अनुकूलन के कारण कोड के विभिन्न संस्करण हैं? आपको एकल संस्करण को समेकित करना चाहिए और फिर कस्टम तर्क के लिए कॉन्फ़िगरेशन स्विच का उपयोग करना चाहिए।

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

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


0

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


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

खैर, जैसा कि यह .NET है, बायनेरिज़ मशीन कोड नहीं हैं, वे CIL ( en.wikipedia.org/wiki/Common_Intermediate_Language ) में हैं। यह काफी आसानी से और सटीक रूप से वापस c # या VB कोड में परिवर्तित किया जा सकता है, खासकर अगर यह बाधित नहीं था। आप इसे उदाहरण के लिए ILSpy के साथ आज़मा सकते हैं ( ilspy.net ) लेकिन संभवत: ऐसे अन्य उपकरण हैं जिनका आप उपयोग कर सकते हैं।
सी
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.