Refactoring: क्या यह आपके कोड को साफ करने के लिए सिर्फ एक फैंसी शब्द नहीं है? [बन्द है]

Question

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

क्या आपको लगता है कि रिफ्लेक्टिंग कभी भी कुछ नया था? शायद कोड सफाई के लिए समय आवंटित करने में प्रबंधन को चकमा देने का एक तरीका है?

Comments

जब आप कहते हैं कि "पुस्तक के बाहर आने से पहले", मुझे लगता है कि आप मार्टिन फोल्वर की पुस्तक का उल्लेख कर रहे हैं क्या यह सही है?

— एलेक्सा

-1: इस प्रश्न की उपयोगिता क्या है?

— जिम जी।

हाँ फाउलर की किताब।

— चक स्टेफंस्की

Answer 1

पहाड़ियों की तुलना में पुराने को रिफलेक्ट करना, तो नहीं, यह कोई नई बात नहीं है।

और सफाई की सफाई नहीं है। खैर, यह हो सकता है, लेकिन यह सफाई तक सीमित नहीं है।

यह आपके एप्लिकेशन की वास्तुकला को समायोजित कर रहा है (चाहे बड़े या छोटे पैमाने पर) व्यवहार को संरक्षित करते हुए।

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

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

इसने कहा कि कोई फर्क नहीं पड़ता कि कोड में क्या बदलाव किए जाते हैं, हमेशा अपने परीक्षण चलाने चाहिए ... बस मामले में।

Comments

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

— फ्रैंक शीयर

Answer 2

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

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

वहाँ कोई जादू refactoring करने के लिए है; यह एक पुरानी प्रथा का वर्णन करने के लिए शब्दजाल का एक नया सेट है।

Comments

विलियम ओपीडके, 1992: रिफैक्टिंग ऑब्जेक्ट-ओरिएंटेड फ्रेमवर्क । फाउलर एंड बेक एंड दोस्तों ने रिफैक्टिंग को लोकप्रिय बनाया । जॉन ब्रैंट और डॉन रॉबर्ट्स ने 1999 से कुछ समय पहले पहला स्वचालित उपकरण लागू किया था। इसलिए "शब्दजाल का नया सेट" बहुत सटीक नहीं है।

— फ्रैंक शायर

यदि आप स्वीकार करते हैं कि 1800 के मध्य में Ada Lovelace से कंप्यूटर प्रोग्रामिंग चल रही है, तो हाँ - यह शब्दजाल का अपेक्षाकृत नया सेट है।

— एंट

मुझे लगता है कि अंतर डिज़ाइन पैटर्न के साथ है लगभग हर डेवलपर ने कुछ नए पैटर्न सीखे और इसलिए पुस्तक से व्यापार के कुछ नए उपकरण। Refactoring के साथ मुझे ऐसा नहीं लगता कि किसी ने वास्तव में कुछ भी सीखा है। किसी चीज़ में नाम डालने में माध्यमिक मूल्य होता है (और डिज़ाइन पैटर्न की तुलना वहाँ होती है), लेकिन वह उस ब्लॉग पोस्ट को w / कर सकता था।

— चक Stephanski

वास्तव में, मैंने उल्लेख किया है कि यह नया शब्दजाल था ... मेमने की गणना के सापेक्ष।

— फ्रैंक शीयर

@ चक, क्या आपने पुस्तक को पढ़ा है, Refactoring? यदि हां, तो मुझे बहुत आश्चर्य होगा यदि आपने इससे कुछ नया नहीं सीखा ।

— मार्सी

Answer 3

हम अपनी कंपनी में तीन अलग-अलग काम करते हैं, तीनों के लिए आवंटित समय:

• Refactoring: कोड संरचना को बदलने में होते हैं, इस प्रकार व्यवहार को बनाए रखते हैं।

उदाहरण: एक बदसूरत और अपठनीय 100 लाइनों की विधि को विभाजित करना जो चार चीजों को चार पुन: प्रयोज्य तरीकों में करता है, प्रत्येक 25 लाइनें।

• सफाई: कोड को और अधिक पठनीय बनाने के लिए मामूली बदलाव करने में शामिल हैं, न तो इसके व्यवहार को संशोधित किए बिना, न ही इसकी संरचना।

उदाहरण: यह सुनिश्चित करने के बाद कि इस कोड की अब और आवश्यकता नहीं है, टिप्पणी कोड को हटाना।

• StyleCop / FxCop नियमों को लागू करना: जाँच में शामिल है कि क्या कोड StyleCop या FxCop नियमों के डिफ़ॉल्ट सेट से मेल खाता है, और यदि नहीं, तो उन नियमों से मेल खाने के लिए इसे संशोधित करें।

उदाहरण: (या अन्य संस्कृति जो अधिक उपयुक्त है) Culture.Invariantमें जोड़ना string.Format।

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

Comments

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

— न्यूटॉपियन

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

— कोजिरो

किसी भी सफाई को करने के बाद आपको हमेशा एक पूर्ण निर्माण करना चाहिए - भले ही यह केवल सफेद-स्थान हो और टिप्पणियां बदलती हैं। उस बारे में किसी भी पायथन या मेकफाइल लेखकों से पूछें।

— JBRWilkinson

Answer 4

Refactoring आपके कोड में ज्ञान जोड़ता है। यदि आप जानते हैं कि कुछ गलत नाम है, तो आप इसे बेहतर नाम देते हैं। यदि आप जानते हैं कि कुछ बेहतर किया जा सकता है, तो आप इसे कुछ बेहतर में बदल सकते हैं।

यह बहुत सारे चरण हैं - छोटे और बड़े - उम्मीद है कि बेहतर कार्यक्रम का परिणाम होगा।

Answer 5

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

"क्लीन अप" का मतलब कुछ भी हो सकता है "रिफॉर्मेटिंग थोडा" से "बड़े चिट्ठों को फिर से लिखना"।

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

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

Answer 6

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

Comments

यह देखने का एक दिलचस्प तरीका है। हो सकता है कि यह मेरे डेटाबेस बैकग्राउंड से आता है, लेकिन कुछ ऐसा है जो मुझे रीफैक्टरिंग पर तनाव के बारे में बताता है, और आपने मुझे अपनी उंगली डालने में मदद की है। यह एक डेटाबेस में है कि आप डिजाइन में क्या तय नहीं करते हैं, परीक्षण में ठीक करने के लिए 10x लंबा समय लगता है और संभवतः उत्पादन में 1000 गुना लंबा है। तो एक अच्छा DBA चीजों को जल्द से जल्द एक चरण में प्राप्त करने के बारे में गुदा है। मेरी आंत की भावना यह है कि बाद के चरणों में बहुत अधिक समय का रिफैक्टरिंग बहुत कम समय के डिजाइनिंग का संकेत है।

— user21007

@ user21007: कोड एक डेटाबेस स्कीमा की तुलना में बहुत अधिक जटिल है, लेकिन इसे बदलने और तैनात करने में बहुत आसान है।

— केविन क्लाइन

Answer 7

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

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

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

Answer 8

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

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

Comments

नाम बदलना एक मानक रीफैक्टरिंग तकनीक है!

— चक स्टेफ़्स्की

Answer 9

मैं कहता हूँ नहीं।

रिफैक्टिंग प्रक्रिया में सफाई हो सकती है लेकिन यह सार नहीं है।

क्लीनअप इस धारणा के साथ आता है कि पिछला कोड साफ नहीं है। वास्तव में, डेवलपर्स ने अपने कोड को रिफलेक्टर किया यहां तक ​​कि मूल कोड पहले से ही साफ है।

DRY रिफैक्टिंग के पीछे एक महत्वपूर्ण ड्राइव है।

मौजूदा कोड बेस में नए कोड जोड़ने पर, DRY सिद्धांत के कारण प्राकृतिक रूप से रिफैक्टिंग की जाती है।

बस मेरी 0.02

Answer 10

अपने कोड को साफ करना आपके घर को ख़राब करने जैसा है, फिर से भरना एक दीवार को फाड़ने और संभवतः इसे कहीं और लगाने जैसा है

Answer 11

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

Comments

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

— जेफओ

Answer 12

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

Answer 13

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

Comments

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

— न्यूटोपियन

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

— विली व्हीलर

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

— न्यूटोपियन

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

— विली व्हीलर

Answer 14

दोनों किनारों पर थोड़ा ओवरलैप करते हैं, लेकिन मेरे लिए यह घर की सफाई और घर को फिर से तैयार करने के बीच का अंतर है। मेरे लिए सफाई, संरचनात्मक परिवर्तन का मतलब नहीं है, जबकि refactoring करता है।

Answer 15

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