पुनर्लेखन (प्रोग्रामिंग): Difference between revisions
From Vigyanwiki
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
{{About-distinguish| | {{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 | 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> विडंबना यह है कि नेविगेटर स्वयं उस प्रोग्राम के डेवलपर्स की देखरेख में [[एनसीएसए मोज़ेक]] का एक सफल क्लीनरूम पुनर्लेखन था। [[ब्राउज़र युद्ध|ब्राउज़र वॉर]] देखें। | |||
कुछ | कुछ परियोजनाएँ अपने इतिहास में प्रमुख पुनर्लेखन का उल्लेख करती हैं: | ||
{{colbegin}} | {{colbegin}} | ||
* [[ अपाचे | * [[ अपाचे एचटीटीपी सर्वर ]] (1) | ||
* [[एओएल इंस्टेंट मैसेंजर]] (1) | * [[एओएल इंस्टेंट मैसेंजर]] (1) | ||
* बाइंड (1) | * बाइंड (1) | ||
| Line 32: | Line 31: | ||
* [[माजर्डोमो (सॉफ्टवेयर)]] (1) | * [[माजर्डोमो (सॉफ्टवेयर)]] (1) | ||
* विकिपीडिया का इतिहास#हार्डवेयर और सॉफ्टवेयर (1) | * विकिपीडिया का इतिहास#हार्डवेयर और सॉफ्टवेयर (1) | ||
* | * मोज़िला/नेटस्केप (1) | ||
* [[आइसकास्ट]] (0-1) | * [[आइसकास्ट]] (0-1) | ||
* [[ | * [[ नेटकैट ]] (1) | ||
* [[ओपनआरपीजी]] (1) | * [[ओपनआरपीजी]] (1) | ||
* [[पीएचपी]] (1-2) | * [[पीएचपी]] (1-2) | ||
Revision as of 22:33, 27 June 2023
कंप्यूटर प्रोग्रामिंग में रीराइट उसके स्रोत कोड के पुन: उपयोग के बिना उपस्थित कार्यक्षमता के एक बड़े भाग को फिर से लागू करने का कार्य या परिणाम है। जब रीराइट उपस्थित कोड का बिल्कुल भी उपयोग नहीं कर रहा है, तो स्क्रैच से रीराइट की बात करना सामान्य बात है।
प्रेरणा
सॉफ़्टवेयर का एक टुकड़ा सामान्यतः फिर से लिखा जाता है जब निम्न में से एक या अधिक लागू होते हैं:
- इसका स्रोत कोड उपलब्ध नहीं है या केवल असंगत लाइसेंस के तहत उपलब्ध है।
- इसके कोड को किसी नए लक्ष्य प्लेटफ़ॉर्म पर अनुकूलित नहीं किया जा सकता है।
- इसके मौजूदा कोड को संभालना और विस्तारित करना बहुत कठिन हो गया है।
- इसे डिबगिंग करने का कार्य बहुत जटिल लगता है।
- प्रोग्रामर को इसके स्रोत कोड को समझने में कठिनाई होती है।
- डेवलपर्स नई तकनीकें सीखते हैं या बड़े फीचर ओवरहॉल करना चाहते हैं जिसके लिए बहुत अधिक बदलाव की आवश्यकता होती है।
- डेवलपर्स सीखते हैं कि लिखे गए नए कोड सामग्री विकल्पों का विस्तार कर सकते हैं जो पिछली समस्याओं को ठीक कर सकते हैं या ओवरराइट कर सकते है।
- सोर्स कोड की प्रोग्रामिंग भाषा को बदलना होता है।
जोखिम
कई सॉफ्टवेयर इंजीनियरों, जैसे कि जोएल स्पोल्स्की[1] ने पूर्ण पुनर्लेखन के प्रति चेतावनी दी है, विशेष रूप से शेड्यूल बाधाओं या प्रतिस्पर्धी दबावों के तहत, हालाँकि डेवलपर्स शुरू में ऐतिहासिक डिज़ाइन की गलतियों को सुधारने के अवसर का स्वागत कर सकते हैं, लेकिन पुनर्लेखन डिज़ाइन के उन हिस्सों को भी हटा देता है जो आवश्यकतानुसार काम करते हैं। एक पुनर्लेखन विकास टीम को न केवल नई सुविधाएँ प्रदान करने के लिए प्रतिबद्ध करता है, बल्कि वे सभी सुविधाएँ जो पिछले कोड में मौजूद हैं, जबकि संभावित रूप से नए बग या पहले से तय किए गए बग के प्रतिगमन को पेश करता है।[2][3] पुनर्लेखन पुराने संस्करण में ठीक न किए गए बगों की ट्रैकिंग में भी हस्तक्षेप करता है।[4]
वृद्धिशील पुनर्लेखन एक वैकल्पिक दृष्टिकोण है, जिसमें डेवलपर्स धीरे-धीरे मौजूदा कोड को कॉल के साथ एक नए कार्यान्वयन में बदल देते हैं, उस कार्यान्वयन का विस्तार करते हैं जब तक कि यह पुराने को पूरी तरह से बदल नहीं देता हैं। यह दृष्टिकोण पुनर्लेखन के दौरान कार्यक्षमता के व्यापक नुकसान से बचाता है। क्लीनरूम सॉफ्टवेयर इंजीनियरिंग एक और दृष्टिकोण है, जिसके लिए टीम को सॉफ्टवेयर की कार्यक्षमता के विस्तृत लिखित विनिर्देश से काम करने की आवश्यकता होती है।[5]
उदाहरण
नेविगेटर 4 में एचटीएमएल लेआउट को बेहतर बनाने के लिए नेटस्केप की परियोजना को एक असफल पुनर्लेखन के उदाहरण के रूप में उद्धृत किया गया है। नया लेआउट इंजन (गेको) नेविगेटर से स्वतंत्र रूप से विकसित हुआ था और नेविगेटर के कोड के साथ आसानी से एकीकृत नहीं हुआ था; इसलिए नेविगेटर को ही नए इंजन के इर्द-गिर्द फिर से लिखा गया, जिससे कई मौजूदा सुविधाएँ टूट गईं और रिलीज़ में कई महीनों की देरी भी हुई है। इस बीच, माइक्रोसॉफ्ट ने इंटरनेट एक्सप्लोरर में क्रमिक सुधारों पर ध्यान केंद्रित किया और उसे समान बाधाओं का सामना नहीं करना पड़ा था।[3][6] विडंबना यह है कि नेविगेटर स्वयं उस प्रोग्राम के डेवलपर्स की देखरेख में एनसीएसए मोज़ेक का एक सफल क्लीनरूम पुनर्लेखन था। ब्राउज़र वॉर देखें।
कुछ परियोजनाएँ अपने इतिहास में प्रमुख पुनर्लेखन का उल्लेख करती हैं:
- अपाचे एचटीटीपी सर्वर (1)
- एओएल इंस्टेंट मैसेंजर (1)
- बाइंड (1)
- फ्रीनेट (1)
- फ़्यूज़बॉक्स (प्रोग्रामिंग) (2)
- जीएनयू ग्रब (1)
- माजर्डोमो (सॉफ्टवेयर) (1)
- विकिपीडिया का इतिहास#हार्डवेयर और सॉफ्टवेयर (1)
- मोज़िला/नेटस्केप (1)
- आइसकास्ट (0-1)
- नेटकैट (1)
- ओपनआरपीजी (1)
- पीएचपी (1-2)
- प्रोजेक्ट ज़ानाडू (0-1)
- सन सिक्योर ग्लोबल डेस्कटॉप (1)
- वी चोटी (2)
- वेबऑब्जेक्ट्स (1)
- ज़ोप (1)
यह भी देखें
- कोड रीफैक्टरिंग
- ओपन सोर्स सॉफ्टवेयर डेवलपमेंट
- तकनीकी ऋण
- विकास नरक
- में porting
- खेल इंजन मनोरंजन
- रिवर्स इंजीनियरिंग
संदर्भ
- ↑ Spolsky, Joel. "चीजें जो आपको कभी नहीं करनी चाहिए, भाग I". Joel on Software. Retrieved 2015-01-23.
- ↑ Ronkes Agerbeek, Joost (April 15, 2005). "स्क्रैच से कोड को कभी भी दोबारा न लिखें". Archived from the original on October 10, 2008. Retrieved 2008-09-11.
- ↑ 3.0 3.1 Spolsky, Joel (April 6, 2000). "चीजें जो आपको कभी नहीं करनी चाहिए". Retrieved 2008-09-11.
- ↑ Zawinski, Jamie. "कैस्केड ऑफ अटेंशन-डेफिसिट टीनएजर्स". Retrieved 2008-09-11.
- ↑ Tilly, Ben (September 29, 2001). "पुनर्लेखन, खरोंच से, एक विशाल कोड आधार". Retrieved 2008-09-11.
- ↑ Zawinski, Jamie (March 31, 1999). "इस्तीफा और पोस्टमॉर्टम". Retrieved 2008-09-11.
