कोड रीफैक्टरिंग

From Vigyanwiki
Revision as of 16:14, 23 February 2023 by alpha>Kajal
"रिफ्लेक्टर" redirects here. For विकिपीडिया पर "रिफैक्टर" का उपयोग, see विकिपीडिया:रिफैक्टरिंग टॉक पेज.
This article is about एक व्यवहार-संरक्षण परिवर्तन. It is not to be confused with पुनर्लेखन (प्रोग्रामिंग).

कंप्यूटर प्रोग्रामिंग और सॉफ्टवेर डिज़ाइन में, कोड रीफैक्टरिंग मौजूदा कंप्यूटर कोड को उसके बाहरी व्यवहार को बदले बिना फैक्टरिंग (कंप्यूटर विज्ञान) को बदलने के पुनर्गठन की प्रक्रिया है। रिफैक्टरिंग का उद्देश्य इसकी कार्यक्षमता को संरक्षित करते हुए सॉफ़्टवेयर की डिज़ाइन, संरचना और/या कार्यान्वयन (इसकी गैर-कार्यात्मक विशेषताएँ) में सुधार करना है। रिफैक्टरिंग के संभावित लाभों में बेहतर कोड पठनीयता और कम चक्रीय जटिलता शामिल हो सकती है; ये स्रोत कोड की रखरखाव क्षमता में सुधार कर सकते हैं और 'विस्तारशीलता में सुधार के लिए एक सरल, स्वच्छ, या अधिक अभिव्यंजक आंतरिक सॉफ़्टवेयर वास्तुशिल्प या वस्तु मॉडल बना सकते हैं। रिफैक्टरिंग के लिए एक और संभावित लक्ष्य बेहतर प्रदर्शन है; सॉफ्टवेयर इंजीनियरों को ऐसे प्रोग्राम लिखने की निरंतर चुनौती का सामना करना पड़ता है जो तेजी से प्रदर्शन करते हैं या कम मेमोरी का उपयोग करते हैं।

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

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

— जोशुआ केरिवेस्की, रिफैक्टरिंग टू पैटर्न्स[1]


प्रेरणा

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

लंबे रूटीन के लिए, एक या अधिक छोटे सबरूटीन निकाले जा सकते हैं; या डुप्लिकेट रूटीन के लिए, डुप्लिकेशन को हटाया जा सकता है और साझा फ़ंक्शन के साथ प्रतिस्थापित किया जा सकता है। रिफैक्टरिंग करने में विफलता के परिणामस्वरूप तकनीकी ऋण जमा हो सकता है; दूसरी ओर, रिफैक्टरिंग तकनीकी ऋण चुकाने के प्राथमिक साधनों में से है।[3]


लाभ

रिफैक्टरिंग की गतिविधि के लाभों की दो सामान्य श्रेणियां हैं।

  1. रखरखाव। बग्स को ठीक करना आसान है क्योंकि सोर्स कोड को पढ़ना आसान है और इसके लेखक के इरादे को समझना आसान है।[4] यह व्यक्तिगत रूप से संक्षिप्त, अच्छी तरह से नामित, एकल-उद्देश्यीय तरीकों के सेट में बड़े मोनोलिथिक रूटीन को कम करके प्राप्त किया जा सकता है। यह विधि को अधिक उपयुक्त वर्ग में ले जाकर या भ्रामक टिप्पणियों को हटाकर प्राप्त किया जा सकता है।
  2. एक्स्टेंसिबिलिटी। यदि यह पहचानने योग्य डिज़ाइन पैटर्न (कंप्यूटर विज्ञान) का उपयोग करता है, तो एप्लिकेशन की क्षमताओं का विस्तार करना आसान है, और यह कुछ लचीलापन प्रदान करता है जहां पहले कोई अस्तित्व में नहीं हो सकता था।[1] प्रदर्शन इंजीनियरिंग कार्यक्रमों में अक्षमताओं को दूर कर सकती है, जिसे सॉफ़्टवेयर ब्लोट के रूप में जाना जाता है, जो पारंपरिक सॉफ़्टवेयर-विकास रणनीतियों से उत्पन्न होती है, जिसका उद्देश्य किसी एप्लिकेशन के विकास के समय को चलाने में लगने वाले समय को कम करना है। प्रदर्शन इंजीनियरिंग हार्डवेयर सुरक्षा मॉड्यूल के लिए सॉफ्टवेयर को भी तैयार कर सकती है, जिस पर वह चलता है, उदाहरण के लिए, समानांतर प्रोसेसर और वेक्टर इकाइयों का लाभ उठाने के लिए।[5]


चुनौतियां

रिफैक्टरिंग के लिए मौजूदा सॉफ्टवेयर सिस्टम का ज्ञान वापस पाने के लिए सॉफ्टवेयर सिस्टम संरचना, डेटा मॉडल और इंट्रा-एप्लिकेशन निर्भरता को निकालने की आवश्यकता होती है।[6]

टीमों के टर्नओवर का अर्थ है सिस्टम की वर्तमान स्थिति और दिवंगत डेवलपर्स द्वारा किए गए डिजाइन निर्णयों के बारे में लापता या गलत ज्ञान। आगे की कोड रीफैक्टरिंग गतिविधियों को इस ज्ञान को पुनः प्राप्त करने के लिए अतिरिक्त प्रयास की आवश्यकता हो सकती है।[7]

रिफैक्टरिंग गतिविधियाँ वास्तुशिल्प संशोधनों को उत्पन्न करती हैं जो सॉफ्टवेयर सिस्टम की संरचनात्मक वास्तुकला को बिगड़ती हैं। इस तरह की गिरावट वास्तुशिल्प गुणों जैसे रखरखाव और बोधगम्यता को प्रभावित करती है जिससे सॉफ्टवेयर सिस्टम का पूर्ण पुन: विकास हो सकता है।[8]

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


परीक्षण

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

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

तकनीक

यहाँ माइक्रो-रिफैक्टरिंग के कुछ उदाहरण दिए गए हैं; इनमें से कुछ केवल कुछ भाषाओं या भाषा प्रकारों पर ही लागू हो सकते हैं। एक लंबी सूची मार्टिन फाउलर (सॉफ्टवेयर इंजीनियर) और वेबसाइट में पाई जा सकती है।[2][page needed][13] कई विकास वातावरण इन माइक्रो-रिफैक्टरिंग के लिए स्वचालित समर्थन प्रदान करते हैं। उदाहरण के लिए, प्रोग्रामर चर के नाम पर क्लिक कर सकता है और फिर संदर्भ मेनू से एनकैप्सुलेट क्षेत्र रिफैक्टरिंग का चयन कर सकता है। आईडीई तब अतिरिक्त विवरण के लिए संकेत देगा, आमतौर पर समझदार चूक और कोड परिवर्तनों के पूर्वावलोकन के साथ। प्रोग्रामर द्वारा पुष्टि के बाद यह पूरे कोड में आवश्यक परिवर्तन करेगा।

  • तकनीकें जो अधिक एप्लिकेशन खोज और समझ की अनुमति देती हैं
    • कार्यक्रम निर्भरता ग्राफ - डेटा और नियंत्रण निर्भरताओं का स्पष्ट प्रतिनिधित्व [14]
    • सिस्टम डिपेंडेंस ग्राफ - पीडीजी के बीच प्रक्रिया कॉल का प्रतिनिधित्व [15]
    • सॉफ्टवेयर इंटेलिजेंस - मौजूदा इंट्रा-एप्लिकेशन निर्भरताओं को समझने के लिए प्रारंभिक स्थिति को रिवर्स इंजीनियर करता है
  • तकनीकें जो अधिक अमूर्तता (कंप्यूटर विज्ञान) की अनुमति देती हैं
  • कोड को अधिक तार्किक टुकड़ों में तोड़ने की तकनीकें
    • कंपोनेंटाइजेशन कोड को पुन: प्रयोज्य सिमेंटिक इकाइयों में तोड़ देता है जो स्पष्ट, अच्छी तरह से परिभाषित, उपयोग में आसान इंटरफेस पेश करता है।
    • वर्ग निकालें मौजूदा क्लास से कोड के हिस्से को नए क्लास में ले जाता है।
    • एक्सट्रैक्ट विधि, बड़ी विधि (कंप्यूटर साइंस) के हिस्से को नई विधि में बदलने के लिए। कोड को छोटे-छोटे टुकड़ों में तोड़कर इसे आसानी से समझा जा सकता है। यह समारोह (प्रोग्रामिंग) पर भी लागू होता है।
  • नाम और कोड के स्थान में सुधार के लिए तकनीकें
    • प्रेरित विधि या प्रेरित क्षेत्र - अधिक उपयुक्त क्लास (कंप्यूटर साइंस) या सोर्स फाइल पर जाएं
    • विधि का नाम बदलें या क्षेत्र का नाम बदलें - नाम को नए में बदलना जो इसके उद्देश्य को बेहतर ढंग से प्रकट करता है
    • पुल अप - ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग (ओओपी) में, सुपरक्लास (कंप्यूटर साइंस) में जाएं
    • नीचे पुश करें - ओओपी में, उपवर्ग (कंप्यूटर विज्ञान) में जाएँ[13]
    • स्वचालित क्लोन पहचान[18]


हार्डवेयर रीफैक्टरिंग

जबकि रिफैक्टरिंग शब्द मूल रूप से सॉफ्टवेयर कोड के रिफैक्टरिंग के लिए विशेष रूप से संदर्भित है, हाल के वर्षों में हार्डवेयर विवरण भाषाओं में लिखे गए कोड को भी रिफैक्टरिंग किया गया है। हार्डवेयर विवरण भाषाओं में कोड की रीफैक्टरिंग के लिए हार्डवेयर रीफैक्टरिंग शब्द का उपयोग शॉर्टहैंड शब्द के रूप में किया जाता है। चूंकि हार्डवेयर विवरण भाषाओं को अधिकांश हार्डवेयर इंजीनियरों द्वारा प्रोग्रामिंग भाषा नहीं माना जाता है,[19] हार्डवेयर रीफैक्टरिंग को पारंपरिक कोड रीफैक्टरिंग से अलग क्षेत्र माना जाना चाहिए।

ज़ेंग और हस द्वारा एनालॉग हार्डवेयर विवरण (VHDL-एम्स में) की स्वचालित रीफैक्टरिंग प्रस्तावित की गई है।[20] उनके दृष्टिकोण में, रीफैक्टरिंग हार्डवेयर डिज़ाइन के सिम्युलेटेड व्यवहार को संरक्षित करता है। गैर-कार्यात्मक माप जो सुधार करता है वह यह है कि रिफैक्टर कोड को मानक संश्लेषण उपकरण द्वारा संसाधित किया जा सकता है, जबकि मूल कोड नहीं हो सकता। सारांश के साथी माइक कीटिंग द्वारा डिजिटल हार्डवेयर विवरण भाषाओं की रीफैक्टरिंग, हालांकि मैन्युअल रीफैक्टरिंग की भी जांच की गई है।[21][22] उनका लक्ष्य जटिल प्रणालियों को समझना आसान बनाना है, जिससे डिजाइनरों की उत्पादकता बढ़ जाती है।

इतिहास

प्रकाशित साहित्य में रिफैक्टरिंग शब्द का पहला ज्ञात उपयोग सितंबर, 1990 में विलियम ओपडीके और राल्फ जॉनसन (कंप्यूटर वैज्ञानिक) के लेख में हुआ था।[23] ग्रिसवॉल्ड की पीएच.डी. थीसिस,[24] ओपडाइक की पीएच.डी. थीसिस,[25] 1992 में प्रकाशित, ने भी इस शब्द का इस्तेमाल किया था।[26] हालांकि दशकों से अनौपचारिक रूप से कोड को रिफैक्टरिंग किया जाता रहा है, बिल ग्रिसवॉल्ड की 1991 पीएच.डी. शोध प्रबंध[24] कार्यात्मक और प्रक्रियात्मक कार्यक्रमों के पुनर्संरचना पर पहले प्रमुख शैक्षणिक कार्यों में से एक है, इसके बाद विलियम ओपेडिक के 1 992 के शोध प्रबंध[25] वस्तु-उन्मुख कार्यक्रमों के पुनर्संरचना पर,[26] हालांकि सभी सिद्धांत और तंत्र कार्यक्रम परिवर्तन प्रणालियों के रूप में लंबे समय से उपलब्ध हैं। ये सभी संसाधन रिफैक्टरिंग के लिए सामान्य तरीकों की सूची प्रदान करते हैं; रीफैक्टरिंग विधि में वैज्ञानिक पद्धति को लागू करने के तरीके और संकेतकों के बारे में वर्णन है कि आपको विधि कब लागू करनी चाहिए (या नहीं करनी चाहिए)।

मार्टिन फाउलर (सॉफ्टवेयर इंजीनियर) की पुस्तक रिफैक्टरिंग: मौजूदा कोड के डिजाइन में सुधार करना विहित संदर्भ है।[according to whom?]

कम से कम 1980 के दशक की शुरुआत से ही फोर्थ (प्रोग्रामिंग भाषा) समुदाय में फैक्टरिंग और फैक्टरिंग आउट शब्द का इस तरह से उपयोग किया जाता रहा है। लियो ब्रॉडी (प्रोग्रामर) की किताब आगे सोच रहा है (1984) का अध्याय छह[27] विषय को समर्पित है।

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

सीवीएस या एसवीएन जैसे सॉफ़्टवेयर रिपॉजिटरी में रिकॉर्ड किए गए जटिल सॉफ़्टवेयर परिवर्तनों के संक्षिप्त विवरण का उत्पादन करने के लिए रिफैक्टरिंग पोस्टहॉक का पुनर्निर्माण भी किया जा सकता है।

स्वचालित कोड रीफैक्टरिंग

कई सॉफ्टवेयर पाठ संपादक और एकीकृत विकास पर्यावरण में ऑटोमेटेड रिफैक्टरिंग सपोर्ट है। यहाँ इनमें से कुछ संपादकों, या तथाकथित रिफैक्टरिंग ब्राउज़र की सूची दी गई है।


यह भी देखें

संदर्भ

  1. ↑ 1.0 1.1 Template:उद्धरण पुस्तक
  2. ↑ 2.0 2.1 Fowler, Martin (1999). Refactoring. Improving the Design of Existing Code. Addison-Wesley. pp. 63ff. ISBN 978-0-201-48567-7.
  3. ↑ Suryanarayana, Girish (November 2014). Refactoring for Software Design Smells. Morgan Kaufmann. p. 258. ISBN 978-0128013977.
  4. ↑ Martin, Robert (2009). Clean Code. Prentice Hall.
  5. ↑ Leiserson, Charles E.; Thompson, Neil C.; Emer, Joel S.; Kuszmaul, Bradley C.; Lampson, Butler W.; Sanchez, Daniel; Schardl, Tao B. (2020). "There's plenty of room at the Top: What will drive computer performance after Moore's law?". Science. 368 (6495): eaam9744. doi:10.1126/science.aam9744. PMID 32499413.
  6. ↑ Haendler, Thorsten; Neumann, Gustaf (2019). "A Framework for the Assessment and Training of Software Refactoring Competences". Proc. Of 11th International Conference on Knowledge Management and Information Systems (KMIS).: 307–316. doi:10.5220/0008350803070316. ISBN 978-989-758-382-7. S2CID 204754665.
  7. ↑ Nassif, Matthieu; Robillard, Martin P. (November 2017). "Revisiting turnover-induced knowledge loss in software projects". 2017 IEEE International Conference on Software Maintenance and Evolution (ICSME): 261–272. doi:10.1109/ICSME.2017.64. ISBN 978-1-5386-0992-7. S2CID 13147063.
  8. ↑ van Gurp, Jilles; Bosch, Jan (March 2002). "Design erosion: problems and causes". Journal of Systems and Software. 61 (2): 105–119. doi:10.1016/S0164-1212(01)00152-2.
  9. ↑ Hassan, Ahmed E.; Xie, Tao (November 2010). "Software intelligence: the future of mining software engineering data". In Proceedings of the FSE/SDP Workshop on Future of Software Engineering Research (FoSER '10): 161–166. doi:10.1145/1882362.1882397. S2CID 3485526.
  10. ↑ Novais, Renato; Santos, José Amancio; Mendonça, Manoel (2017). "Experimentally assessing the combination of multiple visualization strategies for software evolution analysis". Journal of Systems and Software. 128: 56–71. doi:10.1016/j.jss.2017.03.006.
  11. ↑ Fowler, Martin (1999). Refactoring : improving the design of existing code. Reading, MA: Addison-Wesley. ISBN 978-0201485677. OCLC 41017370.
  12. ↑ Smart, John Ferguson (2008). Java Power Tools (in English). "O'Reilly Media, Inc.". p. 301. ISBN 9781491954546. Retrieved 26 July 2018.
  13. ↑ 13.0 13.1 (these are only about OOP however).Refactoring techniques in Fowler's refactoring Website
  14. ↑ Ferrante, Jeanne; Ottenstein, Karl J.; Warren, Joe D. (July 1987). "The program dependence graph and its use in optimization". ACM Transactions on Programming Languages and Systems. ACM. 9 (3): 319–349. doi:10.1145/24039.24041. S2CID 505075.
  15. ↑ Donglin, Linag; Harrold, M. J. (November 2008). "Slicing objects using system dependence graphs". Proceedings. International Conference on Software Maintenance. IEEE: 319–349. doi:10.1109/ICSM.1998.738527. ISBN 978-0-8186-8779-2. S2CID 18160599.
  16. ↑ "Replace type-checking code with State/Strategy".
  17. ↑ "Replace conditional with polymorphism".
  18. ↑ Bruntink, Magiel, et al. "An evaluation of clone detection techniques for crosscutting concerns." Software Maintenance, 2004. Proceedings. 20th IEEE International Conference on. IEEE, 2004.
  19. ↑ Hardware description languages#HDL and programming languages
  20. ↑ Kaiping Zeng, Sorin A. Huss, "Architecture refinements by code refactoring of behavioral VHDL-AMS models". ISCAS 2006
  21. ↑ M. Keating :"Complexity, Abstraction, and the Challenges of Designing Complex Systems", in DAC'08 tutorial [1] Archived 2016-03-28 at the Wayback Machine"Bridging a Verification Gap: C++ to RTL for Practical Design"
  22. ↑ M. Keating, P. Bricaud: Reuse Methodology Manual for System-on-a-Chip Designs, Kluwer Academic Publishers, 1999.
  23. ↑ Opdyke, William F.; Johnson, Ralph E. (September 1990). "Refactoring: An Aid in Designing Application Frameworks and Evolving Object-Oriented Systems". Proceedings of the Symposium on Object Oriented Programming Emphasizing Practical Applications (SOOPPA). ACM.
  24. ↑ 24.0 24.1 Griswold, William G (July 1991). Program Restructuring as an Aid to Software Maintenance (PDF) (Ph.D. thesis). University of Washington. Retrieved 2011-12-24.
  25. ↑ 25.0 25.1 Opdyke, William F (June 1992). Refactoring Object-Oriented Frameworks (Ph.D. thesis). University of Illinois at Urbana-Champaign. Archived from the original (compressed Postscript) on 2019-12-16. Retrieved 2008-02-12.
  26. ↑ 26.0 26.1 "Martin Fowler, "MF Bliki: EtymologyOfRefactoring"".
  27. ↑ Brodie, Leo (2004). Thinking Forth. pp. 171–196. ISBN 0-9764587-0-5. Archived from the original on 16 December 2005. Retrieved 3 May 2020.
  28. ↑ "What's new in Xcode 9".
  29. ↑ "Refactoring in Qt Creator".


अग्रिम पठन


बाहरी संबंध

Retrieved from ‘https://www.vigyanwiki.in/index.php?title=कोड_रीफैक्टरिंग&oldid=257994’