पुनर्लेखन (प्रोग्रामिंग): Difference between revisions

From Vigyanwiki
No edit summary
No edit summary
 
(6 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{About-distinguish|code rewrites, where it is expected that the behavior will change|Code refactoring}}
{{About-distinguish|कोड फिर से लिखता है, जहां यह उम्मीद की जाती है कि व्यवहार बदल जाएगा|कोड रीफैक्टरिंग}}


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


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


== जोखिम ==
== जोखिम ==
कई सॉफ्टवेयर इंजीनियर, जैसे [[जोएल स्पोल्स्की]]<ref>{{cite web|last1=Spolsky|first1=Joel|title=चीजें जो आपको कभी नहीं करनी चाहिए, भाग I|url=http://www.joelonsoftware.com/articles/fog0000000069.html|website=Joel on Software|accessdate=2015-01-23}}</ref> विशेष रूप से शेड्यूल बाधाओं या प्रतिस्पर्धी दबावों के तहत कुल पुनर्लेखन के खिलाफ चेतावनी दी है। जबकि डेवलपर्स शुरू में ऐतिहासिक डिजाइन की गलतियों को ठीक करने के मौके का स्वागत कर सकते हैं, एक पुनर्लेख भी डिजाइन के उन हिस्सों को छोड़ देता है जो आवश्यकतानुसार काम करते हैं। एक पुनर्लेख विकास टीम को न केवल नई सुविधाएँ प्रदान करने के लिए प्रतिबद्ध करता है, बल्कि वे सभी जो पिछले कोड में मौजूद हैं, जबकि संभावित रूप से नए बग या पहले से तय बग के सॉफ़्टवेयर प्रतिगमन को पेश करते हैं।<ref>{{cite web | url=http://www.ronkes.nl/blog/?2005-04-15-neverrewritecode | title=स्क्रैच से कोड को कभी भी दोबारा न लिखें| first=Joost | last=Ronkes Agerbeek | date=April 15, 2005 | accessdate=2008-09-11 | url-status=dead | archiveurl=https://web.archive.org/web/20081010211819/http://www.ronkes.nl/blog/?2005-04-15-neverrewritecode | archivedate=October 10, 2008 }}</ref><ref name="spolsky">{{cite web | url=http://www.joelonsoftware.com/articles/fog0000000069.html | title=चीजें जो आपको कभी नहीं करनी चाहिए| first=Joel | last=Spolsky | authorlink=Joel Spolsky | date=April 6, 2000 | accessdate=2008-09-11}}</ref> एक पुनर्लेख पुराने संस्करण में अनफिक्स बग्स की ट्रैकिंग के साथ भी हस्तक्षेप करता है।<ref>{{cite web | url=http://www.jwz.org/doc/cadt.html | title=कैस्केड ऑफ अटेंशन-डेफिसिट टीनएजर्स| first=Jamie | last=Zawinski | authorlink=Jamie Zawinski | accessdate=2008-09-11}}</ref>
कई सॉफ्टवेयर इंजीनियरों, जैसे कि [[जोएल स्पोल्स्की]]<ref>{{cite web|last1=Spolsky|first1=Joel|title=चीजें जो आपको कभी नहीं करनी चाहिए, भाग I|url=http://www.joelonsoftware.com/articles/fog0000000069.html|website=Joel on Software|accessdate=2015-01-23}}</ref> ने विशेष रूप से शेड्यूल बाधाओं या प्रतिस्पर्धी दबावों के अनुसार पूर्ण रीराइट के प्रति चेतावनी दी है, चूंकि डेवलपर्स प्रारंभ में ऐतिहासिक डिज़ाइन की गलतियों को सुधारने के अवसर का स्वागत कर सकते हैं, लेकिन रीराइट डिज़ाइन के उन भागों को भी हटा देता है जो आवश्यकतानुसार कार्य करते हैं। एक रीराइट विकास टीम को न केवल नई सुविधाएँ प्रदान करने के लिए प्रतिबद्ध करता है, अपितु वे सभी सुविधाएँ जो पिछले कोड में उपस्तिथ हैं, जबकि संभावित रूप से नवीनतम बग या पहले से तय किए गए बग के प्रतिगमन को पेश करता है।<ref>{{cite web | url=http://www.ronkes.nl/blog/?2005-04-15-neverrewritecode | title=स्क्रैच से कोड को कभी भी दोबारा न लिखें| first=Joost | last=Ronkes Agerbeek | date=April 15, 2005 | accessdate=2008-09-11 | url-status=dead | archiveurl=https://web.archive.org/web/20081010211819/http://www.ronkes.nl/blog/?2005-04-15-neverrewritecode | archivedate=October 10, 2008 }}</ref><ref name="spolsky">{{cite web | url=http://www.joelonsoftware.com/articles/fog0000000069.html | title=चीजें जो आपको कभी नहीं करनी चाहिए| first=Joel | last=Spolsky | authorlink=Joel Spolsky | date=April 6, 2000 | accessdate=2008-09-11}}</ref> रीराइट प्राचीन संस्करण में ठीक न किए गए बगों की ट्रैकिंग में भी हस्तक्षेप करता है।<ref>{{cite web | url=http://www.jwz.org/doc/cadt.html | title=कैस्केड ऑफ अटेंशन-डेफिसिट टीनएजर्स| first=Jamie | last=Zawinski | authorlink=Jamie Zawinski | accessdate=2008-09-11}}</ref>
वृद्धिशील पुनर्लेख एक वैकल्पिक दृष्टिकोण है, जिसमें डेवलपर्स धीरे-धीरे मौजूदा कोड को एक नए कार्यान्वयन में कॉल के साथ बदल देते हैं, उस कार्यान्वयन को तब तक विस्तारित करते हैं जब तक कि यह पुराने को पूरी तरह से बदल नहीं देता। यह दृष्टिकोण पुनर्लेखन के दौरान कार्यक्षमता के व्यापक नुकसान से बचा जाता है। [[क्लीनरूम सॉफ्टवेयर इंजीनियरिंग]] एक अन्य दृष्टिकोण है, जिसके लिए टीम को इसके कोड तक पहुंच के बिना, सॉफ्टवेयर की कार्यक्षमता के विस्तृत लिखित विनिर्देश से काम करने की आवश्यकता होती है।<ref>{{cite web | url=http://www.perlmonks.org/?node_id=115511 | title=पुनर्लेखन, खरोंच से, एक विशाल कोड आधार| first=Ben | last=Tilly | date=September 29, 2001 | accessdate=2008-09-11}}</ref>
 


वृद्धिशील रीराइट एक वैकल्पिक दृष्टिकोण है, जिसमें डेवलपर्स धीरे-धीरे उपस्थित कोड को कॉल के साथ एक नवीनतम कार्यान्वयन में परिवर्तित कर देते है, फिर उस कार्यान्वयन का विस्तार करते हैं जब तक कि यह पिछले को पूरे प्रकार से परिवर्तित नहीं कर देता हैं। यह दृष्टिकोण रीराइट के समय कार्यक्षमता की व्यापक हानि से बचाता है। [[क्लीनरूम सॉफ्टवेयर इंजीनियरिंग]] एक दृष्टिकोण है, जिसके लिए टीम को सॉफ्टवेयर की कार्यक्षमता के विस्तृत लिखित विनिर्देश से कार्य करने की आवश्यकता होती है।<ref>{{cite web | url=http://www.perlmonks.org/?node_id=115511 | title=पुनर्लेखन, खरोंच से, एक विशाल कोड आधार| first=Ben | last=Tilly | date=September 29, 2001 | accessdate=2008-09-11}}</ref>
== उदाहरण ==
== उदाहरण ==
[[नेटस्केप]] नेविगेटर 4 में एचटीएमएल लेआउट में सुधार करने के लिए नेटस्केप की परियोजना को विफल पुनर्लेखन के उदाहरण के रूप में उद्धृत किया गया है। नया लेआउट इंजन (गेको (लेआउट इंजन)) नेविगेटर से स्वतंत्र रूप से विकसित हुआ था और नेविगेटर के कोड के साथ आसानी से एकीकृत नहीं हुआ था; इसलिए नेविगेटर को नए इंजन के आसपास फिर से लिखा गया, कई मौजूदा सुविधाओं को तोड़ दिया और कई महीनों तक रिलीज में देरी की। इस बीच, [[माइक्रोसॉफ्ट]] ने [[इंटरनेट एक्सप्लोरर]] में वृद्धिशील सुधारों पर ध्यान केंद्रित किया और समान बाधाओं का सामना नहीं किया।<ref name="spolsky"/><ref>{{cite web | url=http://www.jwz.org/gruntle/nomo.html | title=इस्तीफा और पोस्टमॉर्टम| first=Jamie | last=Zawinski | authorlink=Jamie Zawinski | date=March 31, 1999 | accessdate=2008-09-11}}</ref> विडंबना यह है कि नेविगेटर स्वयं उस कार्यक्रम के डेवलपर्स द्वारा देखे गए [[एनसीएसए मोज़ेक]] की एक सफल क्लीनरूम पुनर्लेखन था। [[ब्राउज़र युद्ध]] देखें।
नेविगेटर 4 में एचटीएमएल लेआउट को अच्छा बनाने के लिए [[नेटस्केप]] की परियोजना को एक असफल रीराइट के उदाहरण के रूप में उद्धृत किया गया है। नवीनतम लेआउट इंजन (गेको) नेविगेटर से स्वतंत्र रूप से विकसित हुआ था और नेविगेटर के कोड के साथ सरलता से एकीकृत नहीं हुआ था; इसलिए नेविगेटर को ही नवीनतम इंजन के आस-पास फिर से लिखा गया, जिससे कई उपस्थित सुविधाएँ टूट गईं और रिलीज़ में कई महीनों की देरी भी हुई थी। इस बीच, [[माइक्रोसॉफ्ट]] ने [[इंटरनेट एक्सप्लोरर|इंटरनेट]] [[इंटरनेट एक्सप्लोरर|एक्सप्लोरर]] में क्रमिक सुधारों पर ध्यान केंद्रित किया और उसे समान बाधाओं का सामना नहीं करना पड़ा था।<ref name="spolsky"/><ref>{{cite web | url=http://www.jwz.org/gruntle/nomo.html | title=इस्तीफा और पोस्टमॉर्टम| first=Jamie | last=Zawinski | authorlink=Jamie Zawinski | date=March 31, 1999 | accessdate=2008-09-11}}</ref> विडंबना यह है कि नेविगेटर स्वयं उस प्रोग्राम के डेवलपर्स की देखरेख में [[एनसीएसए मोज़ेक]] का एक सफल क्लीनरूम रीराइट था। [[ब्राउज़र युद्ध|ब्राउज़र वॉर]] देखें।


कुछ परियोजनाएं अपने इतिहास में प्रमुख पुनर्लेखन का उल्लेख करती हैं:
कुछ परियोजनाएँ अपने इतिहास में प्रमुख रीराइट का उल्लेख करती हैं:
{{colbegin}}
{{colbegin}}
* [[ अपाचे HTTP सर्वर ]] (1)
* [[ अपाचे एचटीटीपी सर्वर ]] (1)
* [[एओएल इंस्टेंट मैसेंजर]] (1)
* [[एओएल इंस्टेंट मैसेंजर]] (1)
* बाइंड (1)
* बाइंड (1)
* [[फ्रीनेट]] (1)
* [[फ्रीनेट]] (1)
* [[फ़्यूज़बॉक्स (प्रोग्रामिंग)]] (2)
* [[फ़्यूज़बॉक्स (प्रोग्रामिंग)]] (2)
* [[जीएनयू ग्रब]] (1)
* [[जीआरयूबी]] (1)
* [[माजर्डोमो (सॉफ्टवेयर)]] (1)
* [[माजर्डोमो (सॉफ्टवेयर)]] (1)
* विकिपीडिया का इतिहास#हार्डवेयर और सॉफ्टवेयर (1)
* [[मीडियाविकि]] (1)
* Mozilla Application Suite का इतिहास | Mozilla/Netscape (1)
* [[मोज़िला/नेटस्केप]] (1)
* [[आइसकास्ट]] (0-1)
* [[आइसकास्ट]] (0-1)
* [[ netcat ]] (1)
* [[ नेटकैट ]] (1)
* [[ओपनआरपीजी]] (1)
* [[ओपनआरपीजी]] (1)
* [[पीएचपी]] (1-2)
* [[पीएचपी]] (1-2)
* [[प्रोजेक्ट ज़ानाडू]] (0-1)
* [[प्रोजेक्ट ज़ानाडू]] (0-1)
* [[सन सिक्योर ग्लोबल डेस्कटॉप]] (1)
* [[सन सिक्योर ग्लोबल डेस्कटॉप]] (1)
* वी [[चोटी]] (2)
* [[वीबुलेटिन]] (2)
* [[वेबऑब्जेक्ट्स]] (1)
* [[वेबऑब्जेक्ट्स]] (1)
* [[ज़ोप]] (1)
* [[ज़ोप]] (1)
Line 46: Line 45:
== यह भी देखें ==
== यह भी देखें ==
* [[कोड रीफैक्टरिंग]]
* [[कोड रीफैक्टरिंग]]
* [[ओपन सोर्स सॉफ्टवेयर डेवलपमेंट]]
* [[ओपन सोर्स सॉफ्टवेयर डेवलपमेंट|ओपन स्रोत सॉफ्टवेयर डेवलपमेंट]]
* [[तकनीकी ऋण]]
* [[तकनीकी ऋण]]
* [[विकास नरक]]
* [[विकास नरक]]
Line 60: Line 59:
*[http://www.c2.com/cgi/wiki?RewriteCodeFromScratch RewriteCodeFromScratch at C2 Wiki]
*[http://www.c2.com/cgi/wiki?RewriteCodeFromScratch RewriteCodeFromScratch at C2 Wiki]
*[http://www.joelonsoftware.com/articles/fog0000000069.html Things You Should Never Do, Part I] by [[Joel Spolsky]]
*[http://www.joelonsoftware.com/articles/fog0000000069.html Things You Should Never Do, Part I] by [[Joel Spolsky]]
[[Category: कंप्यूटर प्रोग्रामिंग]]


[[Category: Machine Translated Page]]
[[Category:Created On 14/06/2023]]
[[Category:Created On 14/06/2023]]
[[Category:Lua-based templates]]
[[Category:Machine Translated Page]]
[[Category:Multi-column templates]]
[[Category:Pages using div col with small parameter]]
[[Category:Pages with script errors]]
[[Category:Templates Vigyan Ready]]
[[Category:Templates that add a tracking category]]
[[Category:Templates using TemplateData]]
[[Category:Templates using under-protected Lua modules]]
[[Category:Wikipedia fully protected templates|Div col]]
[[Category:कंप्यूटर प्रोग्रामिंग]]

Latest revision as of 09:04, 16 July 2023

This article is about कोड फिर से लिखता है, जहां यह उम्मीद की जाती है कि व्यवहार बदल जाएगा. It is not to be confused with कोड रीफैक्टरिंग.

कंप्यूटर प्रोग्रामिंग में रीराइट उसके स्रोत कोड के पुन: उपयोग के बिना उपस्थित कार्यक्षमता के एक बड़े भाग को फिर से लागू करने का कार्य या परिणाम है। जब रीराइट उपस्थित कोड को पूरे प्रकार से भी उपयोग नहीं कर रहा है, तो स्क्रैच से रीराइट की बात करना सामान्य बात है।

प्रेरणा

सॉफ़्टवेयर का एक टुकड़ा सामान्यतः फिर से लिखा जाता है जब निम्न में से एक या अधिक लागू होते हैं:

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

जोखिम

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

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

उदाहरण

नेविगेटर 4 में एचटीएमएल लेआउट को अच्छा बनाने के लिए नेटस्केप की परियोजना को एक असफल रीराइट के उदाहरण के रूप में उद्धृत किया गया है। नवीनतम लेआउट इंजन (गेको) नेविगेटर से स्वतंत्र रूप से विकसित हुआ था और नेविगेटर के कोड के साथ सरलता से एकीकृत नहीं हुआ था; इसलिए नेविगेटर को ही नवीनतम इंजन के आस-पास फिर से लिखा गया, जिससे कई उपस्थित सुविधाएँ टूट गईं और रिलीज़ में कई महीनों की देरी भी हुई थी। इस बीच, माइक्रोसॉफ्ट ने इंटरनेट एक्सप्लोरर में क्रमिक सुधारों पर ध्यान केंद्रित किया और उसे समान बाधाओं का सामना नहीं करना पड़ा था।[3][6] विडंबना यह है कि नेविगेटर स्वयं उस प्रोग्राम के डेवलपर्स की देखरेख में एनसीएसए मोज़ेक का एक सफल क्लीनरूम रीराइट था। ब्राउज़र वॉर देखें।

कुछ परियोजनाएँ अपने इतिहास में प्रमुख रीराइट का उल्लेख करती हैं:

यह भी देखें

संदर्भ

  1. ↑ Spolsky, Joel. "चीजें जो आपको कभी नहीं करनी चाहिए, भाग I". Joel on Software. Retrieved 2015-01-23.
  2. ↑ Ronkes Agerbeek, Joost (April 15, 2005). "स्क्रैच से कोड को कभी भी दोबारा न लिखें". Archived from the original on October 10, 2008. Retrieved 2008-09-11.
  3. ↑ 3.0 3.1 Spolsky, Joel (April 6, 2000). "चीजें जो आपको कभी नहीं करनी चाहिए". Retrieved 2008-09-11.
  4. ↑ Zawinski, Jamie. "कैस्केड ऑफ अटेंशन-डेफिसिट टीनएजर्स". Retrieved 2008-09-11.
  5. ↑ Tilly, Ben (September 29, 2001). "पुनर्लेखन, खरोंच से, एक विशाल कोड आधार". Retrieved 2008-09-11.
  6. ↑ Zawinski, Jamie (March 31, 1999). "इस्तीफा और पोस्टमॉर्टम". Retrieved 2008-09-11.


बाहरी संबंध

Retrieved from ‘https://www.vigyanwiki.in/index.php?title=पुनर्लेखन_(प्रोग्रामिंग)&oldid=218811’