पुनर्लेखन (प्रोग्रामिंग): 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|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 में एचटीएमएल लेआउट को | नेविगेटर 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) | ||
| Line 45: | Line 45: | ||
== यह भी देखें == | == यह भी देखें == | ||
* [[कोड रीफैक्टरिंग]] | * [[कोड रीफैक्टरिंग]] | ||
* [[ओपन सोर्स सॉफ्टवेयर डेवलपमेंट]] | * [[ओपन सोर्स सॉफ्टवेयर डेवलपमेंट|ओपन स्रोत सॉफ्टवेयर डेवलपमेंट]] | ||
* [[तकनीकी ऋण]] | * [[तकनीकी ऋण]] | ||
* [[विकास नरक]] | * [[विकास नरक]] | ||
Revision as of 22:57, 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.
