क्या मुझे उस कोड को फिर से रिफ्लेक्टर करना चाहिए जिसे "परिवर्तन नहीं" कहा जाता है?


148

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

रीफैक्टरिंग के दौरान, समय-समय पर मैं क्लास, पद्धति या कोड की पंक्तियों का सामना करता हूं, जिसमें टिप्पणियां होती हैं

सामान करने के लिए मॉड्यूल ए को कुछ समय देने के लिए समय निर्धारित करें। अगर इसकी समयसीमा ऐसी नहीं रही तो यह टूट जाएगा।

या

इसे मत बदलो। मेरा विश्वास करो, तुम चीजों को तोड़ दोगे।

या

मुझे पता है कि सेटटाइमआउट का उपयोग करना एक अच्छा अभ्यास नहीं है, लेकिन इस मामले में मुझे इसका उपयोग करना था

मेरा सवाल यह है कि क्या मुझे लेखकों से इस तरह की चेतावनियों का सामना करने पर कोड को रिफलेक्टर करना चाहिए (नहीं, मैं लेखकों से संपर्क नहीं कर सकता)?


157
बधाई हो! अब आप कोड के लेखक हैं।

12
आप इसे तब तक ठीक नहीं कर सकते जब तक कि आप यह नहीं जानते कि यह दोनों क्या करना है और यह वास्तव में क्या करता है (आपको अपने परिवर्तनों के पूर्ण परिणामों को समझने के लिए उत्तरार्द्ध को जानना होगा।) समस्या समकालन में दिखाई देती है, और ऐसी समस्याओं को दूर करती है। नौकरी # 1 रिफैक्टिंग होनी चाहिए, वरना हर बदलाव के साथ चीजें और खराब होती जा रही हैं। आप जो सवाल पूछ रहे हैं, वह कैसे करना है। उस प्रश्न में उचित मात्रा में भाषा और मंच-निर्भरता है। उदाहरण: stackoverflow.com/questions/3099794/finding-threading-bugs
sdenham

14
@ Sdenham की टिप्पणी के बाद: यदि आपके पास पहले से स्वचालित इकाई परीक्षण नहीं हैं, जो आपके कोड आधार का उपयोग करते हैं, तो मेरा सुझाव है कि आप अपना समय ऐसे यूनिट परीक्षणों को बनाने में बिताएं, बजाय AFAICT के स्पष्ट लक्ष्यों के साथ "रिफैक्टिंग डायन हंट" पर समय बर्बाद करने के लिए। दिमाग में। एक बार जब आपके पास इकाई परीक्षणों का एक सूट होता है, जो आपके कोड आधार का पूरी तरह से उपयोग करता है, तो आपको यह जानने का एक उद्देश्य होगा कि क्या आपका कोड अभी भी काम करता है / यदि आपको इसके बिट्स को फिर से लिखना है। शुभकामनाएँ।
बॉब जार्विस

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

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

जवाबों:


225

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

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

यहां एक बेहतर रणनीति है: अपने समय का उपयोग करें

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

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

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

  • टीम के लिए पंख की पुस्तक "विरासत कोड के साथ प्रभावी ढंग से काम करना" की एक प्रति प्राप्त करें।

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

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


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

98
मैं तर्क था कि एक टिप्पणी के साथ चिह्नित किसी भी कोड "समय बाहर मॉड्यूल एक कुछ समय काम करना देने के लिए निर्धारित किया है। इसके इस तरह का समय समाप्त नहीं है, यह टूट जाएगा" पहले से ही एक बग है। यह सिर्फ उस ड्रा का सौभाग्य है जो बग हिट नहीं हो रहा है।
17 की 26

10
@ 17of26: जरूरी नहीं कि एक बग हो। कभी-कभी जब आप 3rd पार्टी लाइब्रेरी के साथ काम कर रहे होते हैं, तो आप इसे काम करने के लिए लक्ष्य में "लालित्य" रियायतें देने के लिए मजबूर हो जाते हैं।
whatsisname

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

17
@ ऐरन: मुझे समझ में नहीं आता है कि आपको क्यों लगता है कि परीक्षण जोड़ना या लड़के स्काउट सिद्धांत का पालन करना उत्पाद की गुणवत्ता को कम करेगा।
डॉक्टर ब्राउन

142

हां, आपको अन्य सुविधाओं को जोड़ने से पहले कोड को फिर से भरना चाहिए।

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

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

आपके मामले में, आप मूल परिस्थितियों को नहीं जानते हैं, और न ही आप मूल लेखकों से पूछ सकते हैं। (संभवतः आपके पास उचित प्रतिगमन / एकीकरण परीक्षण नहीं है, या आप बस आगे बढ़ सकते हैं और अपने परीक्षण आपको बता सकते हैं कि क्या आपको कुछ चाहिए।)

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


46
सबसे अच्छा जवाब यहीं; बहुत बुरा यह एक दलित व्यक्ति है। ऊपर दिया गया स्वीकृत उत्तर अच्छी सलाह नहीं है, विशेष रूप से "बर्बाद" पर जोर। मैंने पिछले साल सबसे बड़े (~ 10 ^ 6LOC ) पर काम करने के लिए अपने हिस्से का काम किया है), विरासत-स्था, विस्मयकारी कोड जो मैंने कभी देखा है, और मैं इसे ट्रेन की मलबे को ठीक करने की आदत बनाता हूं, जब मैं देखता हूं समय, भले ही यह उस घटक का हिस्सा न हो जो मैं काम कर रहा हूं। ऐसा करने से मुझे पता चला है कि बग्स को पता चल गया है कि देव टीम भी मौजूद नहीं थी (हालाँकि हमारे अंतिम उपयोगकर्ता शायद थे)। वास्तव में, मुझे निर्देश दिया गया है। परिणामस्वरूप उत्पाद में सुधार होता है।
हारून

10
मैं उस रीफैक्टरिंग को नहीं कहूंगा, लेकिन बग फिक्सिंग, हालांकि।
पाओलो एबरमन

7
एक कोडबेस के डिजाइन में सुधार करने से रिफैक्टरिंग होती है। यदि रिडिजाइन बग को ठीक करता है, तो यह बग फिक्सिंग है। मेरा कहना यह है कि पहला अक्सर दूसरे की ओर जाता है, और दूसरा अक्सर पहले के बिना बहुत कठिन होता है।
क्रामि

10
@Aaron आप भाग्यशाली हैं कि ऐसा करने में प्रबंधन / डेवलपर का समर्थन है। अधिकांश वातावरणों में खराब डिज़ाइन और कोड के कारण ज्ञात और अज्ञात कीड़े चीजों के प्राकृतिक क्रम के रूप में स्वीकार किए जाते हैं।
रुडोल्फ ओलाह

5
@nocomprende मेरा तर्क है कि यदि आप सिस्टम को इसके लिए कुछ परीक्षण लिखने के लिए पर्याप्त रूप से नहीं समझते हैं, तो आपके पास कोई भी व्यवसाय नहीं है जो यह काम करता है।
पैट्रिक एम

61

मेरा सवाल यह है कि क्या मुझे लेखकों से इस तरह की चेतावनियों का सामना करने पर कोड को रिफलेक्टर करना चाहिए

नहीं, या कम से कम अभी तक नहीं। आप मानते हैं कि स्वचालित परीक्षण का स्तर बहुत कम है। आत्मविश्वास के साथ प्रतिक्रिया करने से पहले आपको परीक्षणों की आवश्यकता होती है।

अभी के लिए हम किसी और चीज को तोड़े बिना किसी भी फीचर को जोड़ने में सक्षम नहीं हैं

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

ऐसा लगता है कि यह एक विरासत कोडबेस बन गया है, इसलिए आपको इसे थोड़ा अलग तरीके से व्यवहार करने की आवश्यकता है।

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

हर बार जब आप बग को ठीक करते हैं, तो एक परीक्षण केस जोड़ें जो साबित करता है कि बग ठीक हो गया है। यह प्रत्यक्ष प्रतिगमन को रोकता है।

जब आप एक नई सुविधा जोड़ते हैं, तो कम से कम कुछ बुनियादी परीक्षण जोड़ें जो नई सुविधा के अनुसार काम करता है।

शायद "विरासत कोड के साथ प्रभावी ढंग से काम करना" की एक प्रति प्राप्त करें?

मुझे मौजूदा कोड को रिफलेक्टर करने के लिए कुछ महीने दिए गए थे।

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

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


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

2
सही। या अगर कोई प्रयोग करने योग्य युक्ति की जाँच नहीं होती है यदि पिछला व्यवहार वास्तव में भुगतान करने वाले लोगों द्वारा वांछित है या सॉफ्टवेयर में रुचि रखता है।
बीडीएसएल

शायद "विरासत कोड के साथ प्रभावी ढंग से काम करना" की एक प्रति प्राप्त करें? उस पुस्तक को पढ़ने में उसे कितने सप्ताह लगेंगे? और कब: कार्यस्थल पर काम के घंटों के दौरान, रात में जब हर कोई सोता है?
बिलाल बेगेरदज

23

जीके चेस्टर्टन की बाड़ को याद रखें : जब तक आप यह नहीं समझते कि सड़क क्यों बनाई गई है, तब तक सड़क को बाधित करने वाले बाड़ को नीचे न लें।

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

आपका उद्देश्य एक समझ तक पहुंचना है कि कोड क्या करता है, और इसे तब चेतावनी के साथ क्यों चिह्नित किया गया था, और चेतावनी को अनदेखा करने पर क्या होगा।

इससे पहले, मैं उस कोड को नहीं छू पाऊंगा जिसे चिह्नित नहीं किया गया है "स्पर्श न करें"।


4
ओपी कहते हैं "नहीं, मैं लेखकों के संपर्क में नहीं आ सकता"।
FrustratedWithFormsDesigner

5
मैं लेखकों के संपर्क में नहीं आ सकता और न ही कोई दस्तावेज है।
kukis

21
@kukis: आप लेखकों, किसी भी डोमेन विशेषज्ञों से संपर्क नहीं कर सकते, और प्रश्न में कोड से संबंधित कोई भी ईमेल / विकी / डॉक्स / टेस्ट केस नहीं पा सकते हैं? ठीक है, तो यह सॉफ्टवेयर पुरातत्व में एक पूर्ण विकसित अनुसंधान परियोजना है, न कि एक सरल रीफैक्टरिंग कार्य।
9000

12
यह असामान्य नहीं है कि कोड पुराना है और लेखकों ने छोड़ दिया है। यदि वे एक प्रतियोगी के लिए काम करना समाप्त कर चुके हैं तो चर्चा करना किसी के एनडीए का उल्लंघन हो सकता है। कुछ मामलों में लेखक स्थायी रूप से अनुपलब्ध हैं: आप फिल काट्ज को पीकेजिप के बारे में नहीं पूछ सकते क्योंकि वह वर्षों पहले मर गया था।
pjc50

2
यदि आप "लेखक को खोजने" को "समझने के साथ प्रतिस्थापित करते हैं कि कोड क्या समस्या हल करता है" तो यह सबसे अच्छा जवाब है। कभी-कभी कोड के ये बिट्स बग का सबसे कम भयानक समाधान होते हैं जिन्हें खोजने और ट्रैक करने और निपटने के लिए हफ्तों या महीनों का समय लगता है, अक्सर ऐसे कीड़े होते हैं जो सामान्य प्रकार के यूनिट परीक्षण नहीं पाते हैं। (हालांकि कभी-कभी वे प्रोग्रामर का परिणाम होते हैं जो नहीं जानते थे कि वे क्या कर रहे हैं। आपका पहला काम यह समझना है कि यह कौन सा है)
grahamparks

6

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

यह भी ध्यान दें कि टिप्पणियाँ कम से कम में सहायक नहीं हैं: वे केवल चेतावनी देते हैं और कोई कारण नहीं। हां, वे शार्क के टैंक के आसपास चेतावनी संकेत हैं। लेकिन यदि आप आसपास के क्षेत्र में कुछ भी करना चाहते हैं, तो शार्क के साथ तैरने की कोशिश करने के लिए बहुत कम बिंदु हैं। Imho, आपको पहले उन शार्क से छुटकारा पाना चाहिए।

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

तो, समय समाप्त होने की स्थिति में: इसे तब तक छोड़ दें जब तक कि आप ठीक से समझ न जाएं कि कोड का क्या इंतजार है, और फिर इसे ठीक करने के लिए आगे बढ़ने से पहले कारण को ठीक करें।

इसके अलावा, सुनिश्चित करें कि आपका बॉस समझता है कि यह प्रयास क्या है कि आप इसे शुरू कर रहे हैं, और इसकी आवश्यकता क्यों है। और अगर वे कहते हैं कि नहीं, यह मत करो। इसमें आपको उनके समर्थन की पूरी जरूरत है।


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

@ सुपरप्रकट मेरा एक बिंदु यह था कि रिफैक्टरिंग को पूरी तरह से व्यवहार को संरक्षित करना चाहिए। यदि यह व्यवहार को संरक्षित नहीं करता है, तो यह मेरी पुस्तक में रिफैक्टिंग से अधिक है (और इस तरह के विरासत कोड से निपटने पर अत्यधिक खतरनाक है)।
सेमीस्टर

5

शायद इस तरह की चेतावनियों के साथ कोड को रिफलेक्टर करने के लिए एक अच्छा विचार नहीं है, अगर चीजें ठीक हैं जैसे वे हैं।

लेकिन अगर आपको रिफ्लैक्टर चाहिए ...

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


5

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


4

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

इस बिंदु पर, क्या रिफ्लेक्टर का प्रश्न समय से पहले है (भले ही इसका उत्तर 'हां' के विशिष्ट रूप से दिया जाएगा)।

यहाँ केंद्रीय मुद्दा यह है कि (जैसा कि कुछ उत्तरों में उल्लेख किया गया है) आप जो दृढ़ता से उद्धरण देते हैं, उससे संकेत मिलता है कि कोड में दौड़ की स्थिति या अन्य संगामिति / सिंक्रनाइज़ेशन समस्याएं हैं, जैसे कि यहां चर्चा की गई है । कई कारणों से ये विशेष रूप से कठिन समस्याएं हैं। सबसे पहले, जैसा कि आपने पाया है, प्रतीत होता है कि असंबंधित परिवर्तन समस्या को ट्रिगर कर सकते हैं (अन्य बग का भी यह प्रभाव हो सकता है, लेकिन संक्षिप्त रूप से त्रुटियां लगभग हमेशा होती हैं।) दूसरे, वे निदान करना बहुत कठिन हैं: बग अक्सर एक जगह पर ही प्रकट होता है। कारण से समय या कोड में दूर, और कुछ भी आप इसे निदान करने के लिए इसे दूर करने के लिए कारण हो सकता है ( Heisenbugs))। तीसरी बात, टेस्टिंग में खोजने के लिए कंसीलर बग बहुत कठिन हैं। आंशिक रूप से, जो कि दहनशील विस्फोट के कारण होता है: यह अनुक्रमिक कोड के लिए पर्याप्त खराब है, लेकिन समवर्ती निष्पादन के संभावित इंटरलेविंग्स को जोड़ने से यह उस बिंदु तक पहुंच जाता है जहां अनुक्रमिक समस्या तुलना में महत्वहीन हो जाती है। इसके अलावा, यहां तक ​​कि एक अच्छा परीक्षण मामला भी कभी-कभी समस्या को ट्रिगर कर सकता है - नैन्सी लेवसन ने गणना की कि थेरैक 25 में घातक कीड़े में से एकलगभग 350 रनों में से 1 में हुआ, लेकिन अगर आपको नहीं पता कि बग क्या है, या यहां तक ​​कि एक भी है, तो आप नहीं जानते कि कितने पुनरावृत्तियां एक प्रभावी परीक्षण बनाती हैं। इसके अलावा, इस पैमाने पर केवल स्वचालित परीक्षण संभव है, और यह संभव है कि परीक्षण चालक सूक्ष्म समय की कमी को लागू करता है जैसे कि यह वास्तव में बग को फिर से ट्रिगर नहीं करेगा (हाइजेनबग्स फिर से)।

कुछ वातावरणों में समवर्ती परीक्षण के लिए कुछ उपकरण हैं, जैसे कि POSIX pthreads का उपयोग करके कोड के लिए Helgrind , लेकिन हम यहां की बारीकियों को नहीं जानते हैं। परीक्षण को स्थैतिक विश्लेषण के साथ पूरक होना चाहिए (या क्या यह दूसरा तरीका है?), यदि आपके पर्यावरण के लिए उपयुक्त उपकरण हैं।

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

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


1
आप टिप्पणियों में "दौड़ की स्थिति" कहां देखते हैं? यह भी कहाँ निहित है? आप यहाँ कोड में देखने के लाभ के बिना भी बहुत सारी तकनीकी धारणाएँ बना रहे हैं।
रॉबर्ट हार्वे

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

3

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

रीफैक्टरिंग के दौरान, समय-समय पर मुझे कोड, विधि या कोड की पंक्तियों का सामना करना पड़ता है, जिसमें टिप्पणी होती है जैसे "" इसे स्पर्श न करें!]

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

पता करें कि वे ट्रिकी मॉड्यूल क्या कर रहे हैं और इसे छोटी समस्याओं (मूल लेखकों को क्या करना चाहिए) में तोड़ दें। एक गड़बड़ से बनाए रखने योग्य कोड प्राप्त करने के लिए, अच्छे हिस्सों को फिर से बनाने की जरूरत है और खराब हिस्सों को फिर से लिखना होगा


2

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

मुझे नहीं लगता कि ऐसे कई संगठन हैं जो एक व्यावसायिक प्रक्रिया को अपने पक्ष में करने के लिए कृपया ले सकते हैं क्योंकि सहायक अनुप्रयोग को कोड क्लीनअप या रीफैक्टरिंग की आवश्यकता होती है।

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

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

लेकिन फिर भी, आपके प्रबंधन को आप जो कर रहे हैं उसमें निहित जोखिम को समझने की आवश्यकता है और इस बात से सहमत हैं कि आप जो कर रहे हैं उसका एक व्यावसायिक मूल्य है जो जोखिम को दूर करता है और आपने जो किया है वह उस जोखिम को कम करने के लिए किया जा सकता है।

अब, हम सभी अपने-अपने TODO और उन चीजों को वापस प्राप्त करते हैं जिन्हें हम जानते हैं कि हमारी अपनी कोड क्रिएशंस में सुधार किया जा सकता है यदि केवल अधिक समय हो।


1

हाँ बिल्कुल। ये स्पष्ट संकेत हैं कि जिस व्यक्ति ने इस कोड को लिखा था, वह कोड से असंतुष्ट था और संभवत: इस पर तब तक नाराज रहा जब तक कि उन्हें यह काम करने के लिए नहीं मिला। यह संभव है कि वे समझ नहीं पाए कि असली मुद्दे क्या थे या बदतर थे, उन्हें समझ नहीं आया और उन्हें ठीक करने के लिए बहुत आलसी थे।

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

आदर्श रूप से, आप यह पता लगाने में सक्षम होंगे कि समस्या क्या थी और इसे ठीक से ठीक करें। उदाहरण के लिए:

सामान करने के लिए मॉड्यूल ए को कुछ समय देने के लिए समय निर्धारित करें। अगर इसकी समयसीमा ऐसी नहीं रही तो यह टूट जाएगा।

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

इसे मत बदलो। मेरा विश्वास करो, तुम चीजों को तोड़ दोगे।

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

मुझे पता है कि सेटटाइमआउट का उपयोग करना एक अच्छा अभ्यास नहीं है, लेकिन इस मामले में मुझे इसका उपयोग करना था।

यह एक आसान की तरह लग रहा है। आपको यह देखने में सक्षम होना चाहिए कि क्या setTimeoutकर रहा है और शायद इसे करने का एक बेहतर तरीका है।

उस ने कहा, यदि इस प्रकार के सुधार आपके रिफ्लेक्टर के दायरे से बाहर हैं, तो ये संकेत हैं कि इस कोड के अंदर रिफ्लेक्टर की कोशिश करने से आपके प्रयास का दायरा काफी बढ़ सकता है।

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


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

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

1
@ सुपरकैट शायद, शायद नहीं। हम यहाँ टिप्पणी से नहीं बता सकते। तो यह जांच के लायक है, अगर और कुछ नहीं, तो बारीकियों के साथ टिप्पणी में सुधार करें।
डेविड श्वार्ट्ज 19

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

1

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

कोड शायद अनुमान लगाने और परीक्षण-और-त्रुटि के माध्यम से विकसित किया गया है कि वास्तव में क्या होता है की पूरी समझ के बिना।

इसका मतलब है की:

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

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

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

इसका मतलब यह है कि यह कार्य नियमित रूप से नियमित करने की तुलना में बहुत अधिक है। आपको इसे वास्तविक विकास कार्य के रूप में शेड्यूल करना होगा।

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


-1

मैं जो सवाल पूछूंगा, वह यह है कि किसी ने क्यों लिखा, पहली जगह में नहीं पढ़ा।

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

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

दूसरे शब्दों में, मैं इसे फिर से ठीक नहीं करना चाहता क्योंकि मेरे पास अपने जीवन के साथ बेहतर चीजें हैं।

DO NOT EDIT कहकर, यह कहने का एक तरीका है कि हम सब कुछ जानते हैं, जिसे हम अभी जानने जा रहे हैं और इसलिए भविष्य में हम कभी भी कुछ नया नहीं सीखेंगे।

संपादन न करने के कारणों के बारे में कम से कम टिप्पणी होनी चाहिए। जैसे "Do Not Touch" या "Do Not Enter" कहना। बाड़ को क्यों नहीं छूते? दर्ज क्यों नहीं? यह कहना बेहतर नहीं होगा, "इलेक्ट्रिक फेंस, डोन्ट टच नहीं!" या "लैंड माइंस! दर्ज न करें!"। तब यह स्पष्ट है कि क्यों, और फिर भी आप अभी भी प्रवेश कर सकते हैं, लेकिन कम से कम परिणाम जानने से पहले आपको क्या करना चाहिए।

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

मुझे लगता है कि अंत में, रिफैक्टिंग और उत्पाद को प्राकृतिक और जैविक तरीके से विकसित करने पर प्रतिबंध लगाने के लिए इसे देखा जाता है।


2
ऐसा लगता है कि किए गए अंकों से अधिक कुछ भी उपलब्ध नहीं है और पहले के 9 जवाबों में समझाया गया है
gnat
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.