पुनर्लेखन (प्रोग्रामिंग)
कंप्यूटर प्रोग्रामिंग में रीराइट उसके स्रोत कोड के पुन: उपयोग के बिना उपस्थित कार्यक्षमता के एक बड़े भाग को फिर से लागू करने का कार्य या परिणाम है। जब रीराइट उपस्थित कोड को पूरे प्रकार से भी उपयोग नहीं कर रहा है, तो स्क्रैच से रीराइट की बात करना सामान्य बात है।
प्रेरणा
सॉफ़्टवेयर का एक टुकड़ा सामान्यतः फिर से लिखा जाता है जब निम्न में से एक या अधिक लागू होते हैं:
- इसका स्रोत कोड उपलब्ध नहीं है या फिर ये केवल असंगत लाइसेंस के अनुसार उपलब्ध है।
- इसके कोड को किसी नवीनतम लक्ष्य प्लेटफ़ॉर्म पर अनुकूलित नहीं किया जा सकता है।
- इसके उपस्थित कोड को संभालना और विस्तारित करना बहुत कठिन हो गया है।
- इसे डिबगिंग करने का कार्य बहुत जटिल लगता है।
- प्रोग्रामर को इसके स्रोत कोड को समझने में कठिनाई होती है।
- डेवलपर्स नवीनतम तकनीकें सीखते हैं या बड़े फीचर ओवरहॉल करना चाहते हैं जिसके लिए बहुत अधिक परिवर्तन की आवश्यकता होती है।
- डेवलपर्स सीखते हैं कि लिखे गए नवीनतम कोड सामग्री विकल्पों का विस्तार कर सकते हैं जो पिछली समस्याओं को ठीक कर सकते हैं या ओवरराइट कर सकते है।
- स्रोत कोड की प्रोग्रामिंग भाषा को परिवर्तित करना होता है।
जोखिम
कई सॉफ्टवेयर इंजीनियरों, जैसे कि जोएल स्पोल्स्की[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.
