refactoring - आप खुद को काम करने वाले-भयानक कोड को पुनः सक्रिय करने से कैसे रोकते हैं?




code-smell (20)

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

यदि आप इस "दुःख" से पीड़ित हैं, तो आप खुद को कैसे रोकते हैं? या कम से कम लंबे समय तक इसे बनाए रखने के लिए मौजूदा कोड के बड़े हिस्से को बदलने से बचने के लिए कम से कम रिफैक्टरिंग का प्रबंधन करें।


"मौजूदा कोड को रिफैक्टर करना जो काम करता है" - यह स्पष्ट रूप से अल्पसंख्यक राय है, लेकिन यह समय की पूरी बर्बादी है। यह अच्छा है कि आप खुद को रोकने का प्रयास कर रहे हैं।

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

यह रवैया कि कामकाजी कोड को दोबारा करने के बाद "मैंने कोड को बेहतर छोड़ दिया है" अक्सर प्रोग्रामर हब्रिस होता है । कई मामलों में आप वास्तव में नहीं जानते कि आपने कोड को बेहतर छोड़ दिया है, आप बस मानते हैं कि आपने किया था। यदि आपने कोई बग ठीक नहीं किया है या कार्यक्षमता जोड़ें तो गलत होने का जोखिम क्यों लें?


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

हालांकि, संक्षिप्त जवाब यह है कि आप उस कोड को दोबारा नहीं मानते हैं जो तब तक काम करता है जब तक कोई दबदबा की आवश्यकता न हो। एक अच्छी चेकलिस्ट है:

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

यदि आप उनमें से किसी एक को हाँ का उत्तर देते हैं तो यह रिफैक्टर करने का समय हो सकता है।


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


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

मैं Doxygen का एक बड़ा प्रशंसक हूं, जो मुझे एक साधारण छड़ी करने की अनुमति देता है:

/**
 * Function to rule the world
 * @todo make this actually work
 */

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

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

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

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

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


जवाब आप नहीं करते हैं। सिर्फ इसलिए कि कोड काम का मतलब यह नहीं है कि यह हमेशा काम करेगा। खराब कोड खराब कोड है।

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

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

मैं हमेशा इसे छोड़ने से बेहतर कोड छोड़ने की कोशिश करता हूं।


देखभाल करना बंद करो।

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

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


निम्नलिखित बॉय स्काउट नियम (खराब) कोड और डिज़ाइन के लिए बहुत अच्छा लागू होता है:
कैंपग्राउंड क्लीनर को छोड़कर आप इसे छोड़ दें!


पूरी तरह से वैध सवाल।

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

यह मुझे लगातार खुद से पूछने के खरगोश में मिला: क्या मैं जिस कोड को लिख रहा हूं वह अब मुझे इस कार्य को उचित समय में पूरा करने में मदद करने जा रहा है? क्या मैं इस रिफैक्टरिंग करके कंपनी के समय को बर्बाद कर रहा हूं, जबकि प्राथमिक वस्तुओं पर बकाया सामान हैं जो बहुत अधिक हैं?

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

मैं जो करता हूं वह सिर्फ टिप्पणी करता है कि मैं बाद में क्या करना चाहता हूं, और बस मौजूदा सिस्टम के साथ काम करता हूं, इससे कोई फर्क नहीं पड़ता कि यह कितना बदसूरत है! इससे मुझे कम चीजें तोड़ने और वास्तव में चीजों की सूची में तेजी लाने के लिए अनुमति मिलती है। (हम टीडीडी नहीं करते ... अभी तक)

एक बार आपको समय मिल जाए, वापस आएं और रिफैक्टर।


मेरे लिए क्या काम किया गया था इसके लिए नौकरी से निकाल दिया गया था। : \

उस ने कहा, मेरी मूल समस्या दो गुना थी:

  1. मैं कोड को दोबारा कर रहा था कि किसी ने मुझे काम करने के लिए कहा नहीं था।

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

मैंने जो सीखा वह था:

  1. उस कोड पर काम न करें जिस पर आपको काम करने की आवश्यकता नहीं है, और कोई भी आपको काम करने के लिए नहीं कहता है। अतीत में परिणामों को देखते हुए, अब इसे याद रखना आसान है।

  2. जब आपको कोड को दोबारा करने की आवश्यकता होती है तो आपको काम करना चाहिए, परीक्षण में जगहें हैं, लेकिन उन्हें स्वचालित होने की आवश्यकता नहीं है।

बहुत अधिक टीडीडी सामान पढ़ने के बाद, मैंने स्वचालित परीक्षणों के बारे में सोचने का प्रयास किया क्योंकि एकमात्र प्रकार का परीक्षण है। हकीकत में, Debug.Print स्टेटमेंट का भी एक गुच्छा यह पता लगाने के लिए एक सभ्य परीक्षण हो सकता है कि कार्यक्षमता लगातार रह रही है या नहीं।

अगर आपको रिफैक्टर करना है, और आप स्वचालित परीक्षण नहीं कर सकते हैं, तो आपको किसी प्रकार का परीक्षण करना होगा, चाहे वह प्रिंटिंग टेक्स्ट हो या यूआई स्क्रिप्ट, या जो भी हो। किसी भी परीक्षण से कोई भी प्रभावी परीक्षण बेहतर नहीं है।


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

इसके अलावा, एक बहुत ही वास्तविक जोखिम है, आप विरासत गड़बड़ी में तय की गई बग पेश करेंगे। इससे आपको गैर-व्यावसायिक दिखाई देगा।

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

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

आम तौर पर आपके पास दो मुद्दे होंगे: समय की पूरी कमी, और रिफैक्टर को आवंटित करने के खिलाफ प्रबंधन को धक्का देना। यदि उनमें से कोई भी मुद्दा नहीं है, तो अपने आप को बहुत भाग्यशाली मानें।

संपादित करें: जोएल स्पॉस्की का सबसे अच्छा जवाब है , मुझे विश्वास है।


मैं उस कोड को ठीक करने के बारे में हमारे मुद्दे ट्रैकर (या आप इसे पोस्ट-नोट नोट का उपयोग कर सकते हैं) में कोई समस्या बनाते हैं, और फिर समस्या के बारे में भूल जाते हैं।

यह सभी को यह जानने की अनुमति देता है कि कोड खराब है जो कुछ समस्याएं पैदा कर सकता है, लेकिन मुझे बिना किसी विकृति के अपने वर्तमान कार्य पर काम करने की अनुमति देता है।


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


मैं मानता हूं, यह मोहक है लेकिन यदि आप इस पर ध्यान केंद्रित करते हैं तो आपको अपना कोई वास्तविक काम नहीं मिल सकता है!

दो सुझाव:

  1. कोड को चिह्नित करें ताकि आप इसे बाद में साफ कर सकें (TODO टिप्पणी या कुछ इसी तरह का उपयोग करें)
  2. सुगंधित कोड को इंगित करने वाले आपके बग ट्रैकिंग सिस्टम में एक बग जोड़ें। शायद आप उनके समूह को ठीक करने के लिए समय निर्धारित कर सकते हैं।

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



मैंने अतीत में इसका सामना किया है, और मैं अपनी 'बुरी' अच्छी आदत को कम करता हूं।

असल में, मैं निम्नलिखित करता हूं:

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

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

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

वैसे भी। आप की देखभाल करने से अधिक मस्तिष्क डंप हो सकता है, लेकिन उम्मीद है कि यह मदद करता है।


रिफैक्टरिंग शुरू करने से पहले आपको इसके लिए व्यापक यूनिट परीक्षण करने की आवश्यकता है, और कोई भी इकाई परीक्षण लिखना पसंद नहीं करता :)


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


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

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

तो, आमतौर पर आपको कहीं रेखा खींचनी होती है; रिफैक्टर केवल कोड जो सीधे काम पर चिंतित है, और केवल तभी जब यह एक समान समय नहीं लेगा

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

यदि आप वाणिज्यिक सॉफ्टवेयर विकास की किसी भी बाधा से मुक्त हैं, तो आपका लाभ भिन्न हो सकता है। ;)

वैसे, अच्छा सवाल - मैं भी खुद को लाइन को आकर्षित करने के बारे में सोच रहा हूं।


मार्टिन फाउलर इस मुद्दे पर लेते हैं:

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

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

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