2010-05-14 14 views
8

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

कारणों मैं कोड के बारे में चिंतित महसूस कर रहे हैं:

  1. वर्ग पदानुक्रम जटिल और स्पष्ट नहीं
  2. कुछ कक्षाएं एक अच्छी तरह से परिभाषित उद्देश्य (वे असंबंधित चीजों के एक नंबर है) नहीं है
  3. कुछ वर्गों दूसरों internals का उपयोग करें (वे दोस्त वर्गों के रूप में घोषित कर रहे हैं) प्रदर्शन के लिए अमूर्त की परतों को बायपास करने के लिए, लेकिन मुझे लगता है कि वे इस
  4. कुछ वर्गों करके कैप्सूलीकरण तोड़ रिसाव कार्यान्वयन विवरण (जैसे, मैं एक नक्शा बदल पहले एक हैश मानचित्र के लिए और अपने आप को बदलने के लिए काम करने के लिए)
  5. मेरे स्मृति प्रबंधन/पूलिंग प्रणाली थोड़े भद्दा और कम-से पारदर्शी

वे उत्कृष्ट कारणों refactor करने के लिए और साफ कोड की तरह लग रही है अन्य स्रोत फ़ाइलों में कोड को संशोधित करने के लिए मिला, भावी रखरखाव और विस्तार की सहायता करना, लेकिन काफी समय ले सकता है। साथ ही, मैं किसी भी कोड के साथ कभी भी पूरी तरह से खुश नहीं रहूंगा ...

तो, स्टैक ओवरफ्लो क्या सोचता है? स्वच्छ कोड या सुविधाओं पर काम?

+0

सलाह के लिए सभी को धन्यवाद। इसकी वास्तव में सराहना की। मुझे लगता है कि मैं अपने दिमाग में ताजा होने पर प्रतिक्रिया करता हूं और जब मैं इसे कुछ समय समर्पित कर सकता हूं। मुझे बाद में ऐसा करने का मौका नहीं मिल सकता है और यह कोड बढ़ने के साथ कोड को बढ़ाना मुश्किल है, जो निश्चित रूप से अच्छा नहीं है। एक बार फिर धन्यवाद! – Dan

+0

एक संभावित प्रासंगिक लेख: http://www.joelonsoftware.com/articles/fog0000000069.html –

+0

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

उत्तर

6

मैं तर्क दूंगा कि यदि आपको इस कोड को दोबारा करने की आवश्यकता महसूस होती है, तो आपने अभी तक इसे "पूरा नहीं किया" है।

मुझे लगता है कि जब आप जाते हैं (यह मानते हैं कि आपके पास परीक्षण हैं और टीडीडी की लाल, हरे, रिफैक्टर विधि का पालन कर रहे हैं), लेकिन जहां आप हैं, वहां आपको यह बताने में बहुत कुछ नहीं है कि आपको क्या करना चाहिए " कर लिया।

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

+0

कुल मिलाकर महान सलाह, लेकिन मेरे अंक 2, 3 और 4 की वजह से, अभी थोड़ा सा रिफैक्टरिंग और थोड़ी देर बाद .. dificult - लेकिन मुझे लगता है कि यह मेरा जवाब है: मुझे यह सुनिश्चित करने की ज़रूरत है कि मैं कोड में वृद्धि में सुधार कर सकता हूं । अभी मैं नहीं कर सकता। – Dan

+0

@ डैन: "जब आप कोड करते हैं, जब मुझे लगता है कि मैं बाद में रिफैक्टर करूँगा, तो आप एक ऋण के मालिक होंगे। और आप एक से एक का भुगतान करेंगे" ग्रेट सलाह। – nXqd

1

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

आईएमएचओ, ज़ाहिर है।

+0

मैं लोगों की राय मांग रहा हूं, इसलिए धन्यवाद!:-) इसकी संभावना नहीं है कि किसी भी भी अगले कुछ महीनों के लिए कोड देखेंगे, लेकिन इसके ऊपर बहुत सारे कोड बनाए जाएंगे, इसलिए इसे बाद में ठीक करने के लिए यह बहुत अधिक भिन्न होगा। साथ ही, यह अच्छी तरह से काम करता है और पर्याप्त तेज़ है और इसे साफ करने में समय लग सकता है जो कहीं और बेहतर खर्च किया जा सकता है, खासकर अगर मैं कमियों को ठीक करने के लिए फिर से डिजाइन करता हूं (स्मृति प्रबंधन कोड की तरह) और इसके बाद भी, इसकी संभावना नहीं है इसके साथ कभी भी 100% खुश रहेंगे। Thats क्यों मैं देख रहा हूँ कि अन्य लोग क्या सोचते हैं। मुझे एक तरफ या दूसरे को प्रेरित करें। – Dan

+0

ठीक है, "इसके ऊपर बहुत सारे कोड बनाए जाएंगे" पहले अनजान जानकारी है जो पूरी तरह से समीकरण को बदलती है। निश्चित रूप से इंटरफ़ेस का पुन: उपयोग करना जो क्लाइंट कोड का उपयोग करेगा, ताकि इंटरफ़ेस को "अच्छा कार्यान्वयन" का समर्थन करने के लिए उच्च प्राथमिकता हो। –

+0

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

1

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

यह एक कारण के लिए पर्याप्त है प्रयास इमो के लायक बनाने के लिए। परिभाषा के अनुसार यह कुछ ऐसा है जो उपयोगकर्ता वास्तव में नोटिस करेंगे।

कुछ अन्य महत्वपूर्ण बातों पर विचार करना:

  • अनुरक्षणीयता - कैसे आसान यह किसी भी अपरिहार्य कीड़े कि फसल ऊपर ठीक करने के लिए किया जाएगा?
  • टेस्टेबिलिटी - एक और टेस्टेबल फॉर्म में अपना कोड काम करना इसे पुन: सक्रिय करने का एक शानदार तरीका है। इकाई परीक्षण जोड़ना मतलब है कि आप इसे बदल सकते हैं और वास्तव में क्या ब्रेक जान सकते हैं।
  • विस्तारशीलता - क्या आपको लगता है कि आपको कभी भी नई सुविधाएं जोड़ने की आवश्यकता होगी?

वास्तव में केवल एक बार जब आप अपना कोड बेहतर बनाने पर विचार नहीं करना चाहते हैं तो यह है कि यदि आप निश्चित रूप से जानते हैं तो आपको इसे फिर से स्पर्श करने की आवश्यकता नहीं होगी (यानी कभी भी नहीं)।

+0

इसके लिए धन्यवाद। महान अंक विस्तारशीलता शामिल है, इसलिए एक गैर मुद्दा है, लेकिन रखरखाव और टेस्टेबिलिटी पर विचार करने लायक है। मुझे अभी एहसास हुआ कि यह मेरे तीसरे बिंदु के कारण उन लोगों से निपटने के लिए एक दुःस्वप्न हो सकता है। मुझे लगता है कि मैंने जो कहा वह महसूस किया, लेकिन उस घबराहट को "उस चीज़ पर काम करें जो आपको लाभ देता है", जो मुझे लगता है कि शायद गलत काम है। सलाह के लिए धन्यवाद! – Dan

0

मैं हमेशा रेफैक्टर कहूंगा। कोड की हर अतिरिक्त रेखा और उन सभी घबराहट वाले छोटे गठिया वापस आ जाएंगे और आपको गधे में काट लेंगे।

भविष्य में आप यहां तक ​​कि रिएक्टर भी हो सकते हैं - समय कभी कम नहीं होता है - भले ही आप इसे फेंक दें, फिर भी आपने कुछ बेहतर तरीके से सीखना सीखा है।

2

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

1

"मैं अभी पूरा ..."

ऐसा लगता है कि आप सक्रिय रूप से विरासत कोड है, जो एक अच्छी बात नहीं है लिख रहे हैं। आपने कई कारणों को हाइलाइट किया है कि आप अपने कोड को दोबारा क्यों बदलना चाहते हैं, लेकिन जैसा कि आप कहते हैं कि यह spec के लिए काम करता है, इसलिए इसे रखने के लिए कोई मौजूदा लागत नहीं है।

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

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

देखें। यदि आपको लगता है कि एक वर्ग कई जिम्मेदारियों को प्राप्त कर रहा है, तो रोकें और सोचें कि क्या आपको जिम्मेदारियों को अलग-अलग वर्गों में अलग करने की आवश्यकता है।

यदि आप देखते हैं कि आप कक्षा के आंतरिक भाग में प्रवेश करना चाहते हैं, तो कक्षाओं के बीच इंटरफ़ेस को रोकना और काम करना चाहिए ताकि आपको ठोस वर्ग 'आंतरिकों को जानने और उपयोग करने की आवश्यकता न हो।

+0

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

+0

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

2

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

अपने बारे में जानना अच्छा है कि आप कभी भी कोड के साथ सामग्री महसूस नहीं करेंगे। याद रखें कि आप अपने पूर्णतावाद को नियमित रिलीज के रास्ते में नहीं जाने देते हैं।

3

इसे अभी रिफैक्टर करें।

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

+0

अच्छा बिंदु, धन्यवाद – Dan

0

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

1

उन पहलुओं पर काम करें जो बाद में बग का कारण बनेंगे। सोनाप्लेट मत करो।

2

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

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

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

यदि आपके पास अब खराब, खराब डिजाइन कोड है, तो यह बाद में बट में आपको काट देगा। विशेष रूप से यदि इसके ऊपर बहुत सारे कोड लिखे जाएंगे।

0

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

TDD चक्र RED-GREEN-REFACTOR है, और यह कहते हैं कि आप नहीं "पूरा" कर रहे हैं जब तक डिजाइन अच्छा है - कि कहने के लिए जब तक यह किसी भी अधिक पुनर्रचना की जरूरत नहीं है है।

1

यह वास्तव में जटिल नहीं है। बस इस नियम का पालन करें:

अक्सर रिएक्टर कोड। हर बार जब यह संभव हो रिफैक्टर।

इसलिए, अगर आपको लगता है कि आप अपने कोड को दोबारा कर सकते हैं, तो आपको इसे बहुत जटिल होने से पहले इसे अभी करना चाहिए जब सभी कोड एक साथ कड़े हो जाते हैं।

1

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

शायद उपभोक्ता कोड के आधार पर एपीआई/इंटरफ़ेस को फिर से करें और रीफैक्टरिंग टॉप डाउन ड्राइव करें।

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

+0

सार्वजनिक डेटा के संबंध में, चिंता न करें, मैं एक्सेसर्स का प्रशंसक नहीं हूं और मानता हूं कि वस्तुओं को अपने डेटा पर संचालित होना चाहिए और जहां कहीं भी संभव हो अन्य ऑब्जेक्ट डेटा में पोक करना चाहिए। – Dan

1

तो, स्टैक ओवरफ्लो क्या सोचता है? सुविधाओं पर साफ कोड या काम?

प्रश्न मैं यहां देखता हूं कि अगर आप रिफैक्टर बनाम भुगतान करते हैं तो आपको कितना मूल्य देना होगा यदि आप नहीं करते हैं तो आप किस कीमत का भुगतान करते हैं।

यदि आप इसे छोड़ देते हैं, तो यह आपको किसी भी रखरखाव (अतिरिक्त समय, प्रत्येक परिवर्तन के साथ नए दोष जोड़ने की संभावना में वृद्धि) और डेवलपर के रूप में प्रतिष्ठा के लिए खर्च करेगा (इसमें देखे गए किसी भी अन्य कोडर शायद आपको शाप दे सकता है:))।

यदि आप गारंटी दे सकते हैं कि कोई भी उस कोड को फिर से स्पर्श नहीं करेगा (क्योंकि यह बहुत भयानक नहीं है;)) आप सुरक्षित रूप से इसे छोड़ सकते हैं। (एक डेवलपर के रूप में 10+ वर्षों में मुझे कभी ऐसी स्थिति नहीं मिली है जहां मैं इसकी गारंटी दे सकता हूं)।

अन्य सभी मामलों में, आप रिफैक्टरिंग से बेहतर हैं।

वे refactor और स्वच्छ कोड के लिए उत्कृष्ट कारणों से, भविष्य रखरखाव और विस्तार सहायता की तरह लग रही है, लेकिन काफी समय लगता है हो सकता है।

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

इसका मतलब है कि आप अपने उपलब्ध समय के आधार पर रिफैक्टर करने में सक्षम होना चाहिए, न कि दूसरी तरफ।

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

यदि आपके पास अधिक समय है, तो आप अगला रिफैक्टरिंग और दोहराना कर सकते हैं।

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

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