मैंने एक विधि हस्ताक्षर को बदल दिया है और अब 25,000 से अधिक त्रुटियां हैं। अब क्या?


166

मैंने हाल ही में एक नया काम शुरू किया है जहाँ मैं एक बहुत बड़े एप्लिकेशन (15M लोकेशन) पर काम कर रहा हूँ। मेरी पिछली नौकरी में हमारे पास एक समान रूप से बड़ा आवेदन था लेकिन (बेहतर या बदतर के लिए) हमने OSGi का उपयोग किया, जिसका अर्थ था कि एप्लिकेशन को बहुत सारे माइक्रोसॉर्क्स में तोड़ दिया गया था जिसे स्वतंत्र रूप से बदला जा सकता है, संकलित किया जा सकता है और तैनात किया जा सकता है। नया आवेदन सिर्फ एक बड़ा कोड बेस है, जिसमें शायद .dll का एक जोड़ा है।

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

मैंने अपनी पिछली नौकरी में कभी इस तरह की समस्या का सामना नहीं किया। मैं क्या करूं?


7
आपको हमें त्रुटियों के प्रकारों के बारे में अधिक जानकारी देने की आवश्यकता है और "यह वर्ग" क्या है, हम पाठकों को बुरा नहीं मानते।
whatsisname

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

13
मैं आपके द्वारा बदले गए तरीके पर हस्ताक्षर करने से पहले और बाद में देखना चाहूंगा। BTW - 25k त्रुटियों से निपटने के लिए बहुत अधिक की तरह वास्तव में ध्वनि नहीं करता है। थकाऊ हाँ, चुनौतीपूर्ण, हाँ, असहनीय, नहीं।
जोमेनो

46
एक सार्वजनिक इंटरफ़ेस एक अनुबंध है। ऐसे अनुबंध न तोड़ें - नए बनाएँ।
मैथ्यू पढ़ें

6
25000 त्रुटियां !? ह्यूस्टन, हमें एक समस्या मिली। निश्चित रूप से परिवर्तन को वापस करें और अपने प्रबंधक से बात करें, उसे समझाएं कि आपको एक नया इंटरफ़ेस बनाना होगा।
कोड व्हिस्परर 18

जवाबों:


349

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

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


79
जरूरी नहीं कि वह नया वर्ग हो । भाषा और परिस्थितियों के आधार पर यह एक फ़ंक्शन, इंटरफ़ेस, विशेषता, आदि हो सकता है
Jan Hudec

33
यह भी मदद करता है कि पुराने इंटरफ़ेस को नए के आसपास अनुकूलता आवरण द्वारा प्रतिस्थापित किया जा सकता है।
जान हुडेक

79
कभी-कभी, 25000 त्रुटियां वास्तव में इसका मतलब है कि हमने कभी भी इसे छूने की हिम्मत नहीं की, लेकिन अब जब एक नवागंतुक आया है, तो आइए हम उसे सफाई-आउट-ऑगियन-अस्तबल कार्य दें।
मौविसील

13
@ अन्य: मैं मानता हूं, 1 परिवर्तन और 25k त्रुटियों का सबसे अधिक संभावना है कि 2.5k परिवर्तन का सबसे अधिक मतलब है, और मुझे यह देखकर आश्चर्य नहीं होगा कि यह लगभग 250 था। बहुत सारे काम दोनों तरह से, लेकिन उल्लेखनीय।
11

33
उन 25000 त्रुटियों को सभी एक परिवर्तन से ठीक कर सकते हैं। यदि मैं एक बड़ी उत्तराधिकारिणी के आधार वर्ग को तोड़ता हूं, तो व्युत्पन्न वर्गों में से हर एक अमान्य आधार के बारे में त्रुटियां पैदा करेगा, उन वर्गों का प्रत्येक उपयोग वर्ग के बारे में त्रुटियां पैदा करेगा, जो मौजूदा नहीं हैं, आदि की कल्पना करें कि यह "getName" था, और मैंने कहा। एक विवाद। "हसनमे" कार्यान्वयन वर्ग में ओवरराइड अब काम नहीं करता है (त्रुटि), और इससे प्राप्त होने वाली सब कुछ अब त्रुटियां (सभी 1000 कक्षाएं) उत्पन्न करता है, साथ ही हर बार मैं उनमें से किसी का भी एक उदाहरण बनाता हूं (प्रति वर्ग 24x) औसत)। फिक्स है ... एक लाइन।
Yakk

80

विभाजित और refactorings के साथ जीत

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

फूट डालो

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

जीतना

आपके जैसे जटिल मामलों के लिए, यह एक समय में एक छोटे से रीफैक्टरिंग करने के लिए समझ में आता है और फिर समस्या को आराम करने दे सकता है, ताकि सभी निरंतर एकीकरण सिस्टम परिवर्तन को सत्यापित कर सकें, और शायद परीक्षण टीम को भी एक नजर थी। यह आपके द्वारा किए गए चरणों को मान्य करता है।

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

उदाहरण

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

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

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

कभी-कभी वह काम नहीं करता है

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

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


12
इस। रिफैक्टर यदि आप (सुरक्षित रूप से) कर सकते हैं, अन्यथा आपको एक उचित प्रवासन की आवश्यकता है।
सिल्के

3
और जो कुछ भी हो, उसके प्यार के लिए, कृपया अपने IDE के बिल्ट-इन रिफैक्टिंग टूल का उपयोग करें, बजाय इसके (जैसे) विधि हस्ताक्षर को स्थानीय रूप से बदलने और फिर परिणामी त्रुटियों को ठीक करने के लिए।
KlaymenDK

36

एक पेशेवर सॉफ्टवेयर डेवलपर के रूप में समस्या और आपकी जरूरतों को समझने में उसकी मदद करने के लिए अपने बॉस के साथ अपने कार्य को स्पष्ट करें।

यदि आप किसी टीम का हिस्सा हैं, तो लीड डेवलपर की तलाश करें और उससे सलाह लें।

सौभाग्य।


15
यह मेरा पहला कदम है - "मैं एक जूनियर हूं और मेरे बॉस ने मुझे एक काम करने के लिए कहा और अब मुझे वास्तव में बड़ी त्रुटि संदेश मिल रहा है, लेकिन मेरे बॉस ने मुझे इस बारे में नहीं बताया।" चरण 1: "हे मालिक, मैंने बात की थी, लेकिन मुझे अब 25k त्रुटियाँ मिलती हैं। क्या ऐसा होने वाला है, या ..."
Pimgd

28

इसे मत छुओ। कुछ भी मत करो।

इसके बजाय, अपनी कुर्सी पर बैठ जाओ और चिल्लाओ "Heeeeelp !!!!!" तुम्हारे द्वारा जितने भी जोर से किया जा सकता हो।

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

और हो सकता है कि बॉस ने अपने वरिष्ठ सहयोगियों को भी यही बदलाव करने के लिए कहा हो, और उन्होंने कहा कि "नहीं"। क्योंकि वे जानते थे कि क्या होगा। इसलिए आपको काम दिया गया था।


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

@ TheGreatDuck: मुझे बताएं कि आपने कभी भी एक इंटरफ़ेस का उपयोग हर जगह और हर जगह गलत नहीं देखा है। मुझे यकीन है।
जोशुआ

@ जोशुआ वह भी प्रासंगिक नहीं है जो मैंने अभी कहा था। वहाँ कई बार एक छोटी सी बग फिक्सिंग कर रहे थे हमेशा सबसे अच्छा विचार नहीं है इसका मतलब है कि कोड की 10,000+ लाइनों को फिर से लिखना। दुर्भाग्य से, एक नया कर्मचारी काम के पुनर्लेखन के बाहर 10 ऑल-नाइटर्स को खींचने के लिए पर्याप्त रूप से भोला हो सकता है जो अपने बॉस को प्रभावित करने और उसे प्राप्त करने के लिए कोड बनाते हैं। ज़रूर, यह बहुत अच्छी बात है, लेकिन कभी-कभी पर्याप्त है। आपको बस बग के अस्तित्व को स्वीकार करना होगा।
द ग्रेट डक

1
@ जोशुआ btw, मैं केवल इस समुदाय में शामिल हुआ क्योंकि यह प्रश्न मेरे लोकप्रिय प्रश्न फ़ीड पर आया था। मुझे इस तरह के बड़े पैमाने के डिजाइन के साथ कोई अनुभव नहीं है। मैं सिर्फ इस व्यक्ति के दृष्टिकोण से सहमत हूं।
द ग्रेट डक

22

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


10

मूल्यांकन करना

मूल्यांकन करें कि क्या यह परिवर्तन आवश्यक है, या क्या आप एक नई विधि जोड़ सकते हैं और दूसरे को अपदस्थ कर सकते हैं

आगे

यदि बदलना आवश्यक है; तब एक प्रवास योजना आवश्यक है।

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

यह एक प्रतिबद्ध बिंदु है: जांचें कि सभी परीक्षण पास, कमिट, पुश करते हैं।

माइग्रेट

व्यस्त कार्य पुराने तरीके के सभी कॉलगर्ल को नए में स्थानांतरित कर रहा है। शुक्र है कि यह धीरे-धीरे किया जा सकता है फॉरवर्डर के लिए धन्यवाद।

तो आगे बढ़ो; सहायता करने के लिए उपकरणों का उपयोग करने में संकोच न करें ( sedसबसे बुनियादी होने के नाते, अन्य हैं)।

पदावनत के रूप में पुरानी विधि को चिह्नित करें (नई पद्धति पर स्विच करने के संकेत के साथ); यह आपको यह बताने में मदद करेगा कि क्या आप कुछ भी भूल गए हैं और इससे मदद मिलेगी कि क्या कोई सहकर्मी पुरानी पद्धति पर कॉल करता है जबकि आप इस पर काम कर रहे हैं।

यह एक प्रतिबद्ध बिंदु है (या शायद कई प्रतिबद्ध बिंदु): जांचें कि सभी परीक्षण पास, कमिट, पुश।

हटाना

कुछ समय बीत जाने के बाद (शायद दिन जितना कम हो), बस पुरानी पद्धति को हटा दें।


4
sedशायद एक बुरा विचार है ... कुछ ऐसा जो वास्तव में भाषा को "समझता है" और अनजाने में किए गए कठोर बदलावों को बेहतर नहीं करेगा।
20 अक्टूबर को wizzwizz4

1
@ wizzwizz4: दुर्भाग्य से, मुझे बहुत कम उपकरण मिले हैं जो वास्तव में C ++ के लिए भाषा को अच्छी तरह से समझते हैं; ज्यादातर उपकरण नाम बदलने के लिए पूरा करने लगते हैं और यह बात है। दी गई, केवल सटीक विधि कॉल का नामकरण (और कोई अधिभार या असंबंधित लेकिन इसी तरह नामित विधि कॉल) पहले से ही प्रभावशाली नहीं है, लेकिन यह अधिक जटिल कुछ भी के लिए अपर्याप्त है। बहुत कम से कम, आपको (1) फेरबदल तर्क की क्षमता की आवश्यकता होगी, (2) किसी दिए गए तर्क में परिवर्तन लागू करें ( .c_str()उदाहरण के लिए कॉल करें ) और नए तर्क पेश करें। sedथोड़े काम करता है, संकलक इसके मुद्दों को बाद में पकड़ता है।
मैथ्यू एम।

1
sed(या ed) इस तरह की चीज़ के लिए पर्याप्त हो सकता है - जब तक आप ठीक से समीक्षा करते हैं इससे पहले कि आप प्रतिबद्ध हों।
टॉबी स्पाइट नाइट

यह html का TCRR है, हाँ? :)
डैनियल स्प्रिंगर

8

यदि विधि हस्ताक्षर में आपका परिवर्तन केवल एक नाम परिवर्तन है, तो 25,000 वर्गों में परिवर्तन को स्वचालित करने के लिए उपकरण का उपयोग करना सरल उपाय है जो प्रश्न में विधि का संदर्भ देता है।

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

यदि आप केवल नाम बदलने (मापदंडों की संख्या या प्रकारों को बदलने) की तुलना में विधि हस्ताक्षर में अन्य परिवर्तन कर रहे हैं, तो आप "Refactoring -> विधि परिवर्तन हस्ताक्षर" का उपयोग कर सकते हैं। हालाँकि, संभावना है कि आपको अधिक सावधान रहना होगा क्योंकि अन्य उत्तर सुझाते हैं। इसके अलावा, परिवर्तन के प्रकार की परवाह किए बिना यह अभी भी काफी काम हो सकता है जो व्यस्त कोड आधार में उन सभी परिवर्तनों को पूरा कर रहा है।


2
ओपी ने विशेष रूप से कहा कि OSGi उनकी पिछली नौकरी पर था, इसलिए यह वास्तव में यहां प्रासंगिक नहीं है।
एक सीवीएन

3
@ माइकलकॉर्जलिंग अगर ओपी अपनी पिछली नौकरी में जावा प्रोग्रामर था, तो इस बात से बेहतर है कि वे इस नौकरी में भी जावा प्रोग्रामर हैं।
रिच

@ माइकलकॉर्जलिंग मैं एक ठोस सिफारिश देना चाहता था, जिसमें ग्रहण के लिए ग्रहण का उपयोग किया गया था क्योंकि ओपी जावा से परिचित है। क्या ओपी वास्तव में वर्तमान परियोजना के लिए जावा का उपयोग कर रहा है, मुझे लगता है कि यह कम महत्वपूर्ण है, लेकिन मुझे अपना उत्तर स्पष्ट करना चाहिए। धन्यवाद।
मिककेलराज

6

यहाँ मेरा योगदान है।

मैंने हाल ही में एक नया काम शुरू किया है, जहाँ मैं एक बहुत बड़े एप्लिकेशन (कोड की 15M लाइन्स) पर काम कर रहा हूँ।

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

मौजूदा समाधान को समझने से आपको बेहतर परिप्रेक्ष्य मिलता है कि आप कहां जा रहे हैं। समाधान और इसके महत्व का संदर्भ।

जैसा कि @Greg ने बताया, आपको मौजूदा कोड का परीक्षण करने में सक्षम होना चाहिए (प्रतिगमन परीक्षणों) के साथ तुलना करने के लिए एक वैध संदर्भ। आपका समाधान मौजूदा के मुकाबले बहुत ही परिणाम उत्पन्न करने में सक्षम होना चाहिए । इस स्तर पर, आपको इस बात की परवाह नहीं है कि परिणाम सही हैं या नहीं । पहला लक्ष्य रिफ्लेक्टर है, बग को ठीक करने के लिए नहीं। यदि मौजूदा समाधान "2 + 2 = 42" कहता है, तो आपका समाधान भी होना चाहिए। यदि यह अपवाद नहीं फेंकता है, तो आपका भी नहीं होना चाहिए। यदि यह नल को लौटाता है, तो आपको नल भी लौटाना चाहिए। और इसी तरह। अन्यथा, आप कोड की 25k लाइनों से समझौता करेंगे।

यह रेट्रो-संगतता के लिए है।

क्यों? क्योंकि अभी, यह एक सफल रिफ्लेक्टर की आपकी अनूठी गारंटी है।

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

रेट्रो-संगतता की गारंटी देने का एक तरीका आपके लिए तत्काल आवश्यक है इसलिए यहां आपकी पहली चुनौती है। इकाई परीक्षण के लिए घटक को अलग करें।

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

एक बार जब आप नए "अनुबंध" को डिज़ाइन और कार्यान्वित कर लेते हैं, तो पुराने को बदल दें। इसे अपदस्थ करें या इसे बाहर निकालें।

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

कोड की 25k लाइनें मुझे केवल एक कार्य पर ध्यान केंद्रित करने के लिए पर्याप्त मुद्दे लगती हैं।

एक बार आपका पहला काम हो गया। अपने बॉस को उन बग / सुविधाओं को उजागर करें।

अंत में, जैसा @Stephen ने बताया है:

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


5

झसे आज़माओ।

हर कोई सिफारिश कर रहा है कि कैसे रिफ्लेक्टर किया जाए ताकि बहुत कम प्रभाव पड़े। लेकिन उस कई त्रुटियों के साथ, भले ही आप कोड की 10 पंक्तियों (आप शायद कर सकते हैं) के साथ कम करने में सफल होते हैं, तो आपने 25,000 कोड प्रवाह को प्रभावित किया है , भले ही आपको उन्हें फिर से लिखने की आवश्यकता न हो।

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

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