पुनर्लेखन (प्रोग्रामिंग)
कंप्यूटर प्रोग्रामिंग में एक पुनर्लेख इसके स्रोत कोड के पुन: उपयोग के बिना मौजूदा कार्यक्षमता के एक बड़े हिस्से को फिर से लागू करने का कार्य या परिणाम है। जब पुनर्लेखन मौजूदा कोड का उपयोग बिल्कुल नहीं कर रहा है, तो खरोंच से पुनर्लेखन की बात करना आम बात है।
प्रेरणा
सॉफ़्टवेयर का एक टुकड़ा आम तौर पर फिर से लिखा जाता है जब निम्न में से एक या अधिक लागू होते हैं:
- इसका अनाथ कार्य या केवल लाइसेंस संगतता लाइसेंस के तहत उपलब्ध है
- इसका कोड किसी नए लक्ष्य प्लेटफॉर्म के लिए अनुकूलित नहीं किया जा सकता है
- इसका मौजूदा कोड संभालना और विस्तार करना बहुत कठिन हो गया है
- डिबगिंग का कार्य बहुत जटिल लगता है
- प्रोग्रामर को इसके सोर्स कोड को समझने में कठिनाई होती है
- डेवलपर्स नई तकनीक सीखते हैं या एक बड़ा फीचर ओवरहाल करना चाहते हैं जिसके लिए बहुत बदलाव की आवश्यकता होती है
- डेवलपर्स सीखते हैं कि लिखे गए नए कोड सामग्री विकल्पों को बढ़ा सकते हैं जो पिछली समस्याओं को ठीक कर सकते हैं या ओवरराइट कर सकते हैं
- स्रोत कोड की प्रोग्रामिंग भाषा को बदलना होगा
जोखिम
कई सॉफ्टवेयर इंजीनियर, जैसे जोएल स्पोल्स्की[1] विशेष रूप से शेड्यूल बाधाओं या प्रतिस्पर्धी दबावों के तहत कुल पुनर्लेखन के खिलाफ चेतावनी दी है। जबकि डेवलपर्स शुरू में ऐतिहासिक डिजाइन की गलतियों को ठीक करने के मौके का स्वागत कर सकते हैं, एक पुनर्लेख भी डिजाइन के उन हिस्सों को छोड़ देता है जो आवश्यकतानुसार काम करते हैं। एक पुनर्लेख विकास टीम को न केवल नई सुविधाएँ प्रदान करने के लिए प्रतिबद्ध करता है, बल्कि वे सभी जो पिछले कोड में मौजूद हैं, जबकि संभावित रूप से नए बग या पहले से तय बग के सॉफ़्टवेयर प्रतिगमन को पेश करते हैं।[2][3] एक पुनर्लेख पुराने संस्करण में अनफिक्स बग्स की ट्रैकिंग के साथ भी हस्तक्षेप करता है।[4] वृद्धिशील पुनर्लेख एक वैकल्पिक दृष्टिकोण है, जिसमें डेवलपर्स धीरे-धीरे मौजूदा कोड को एक नए कार्यान्वयन में कॉल के साथ बदल देते हैं, उस कार्यान्वयन को तब तक विस्तारित करते हैं जब तक कि यह पुराने को पूरी तरह से बदल नहीं देता। यह दृष्टिकोण पुनर्लेखन के दौरान कार्यक्षमता के व्यापक नुकसान से बचा जाता है। क्लीनरूम सॉफ्टवेयर इंजीनियरिंग एक अन्य दृष्टिकोण है, जिसके लिए टीम को इसके कोड तक पहुंच के बिना, सॉफ्टवेयर की कार्यक्षमता के विस्तृत लिखित विनिर्देश से काम करने की आवश्यकता होती है।[5]
उदाहरण
[[नेटस्केप नेविगेटर]] 4 में एचटीएमएल लेआउट में सुधार करने के लिए नेटस्केप की परियोजना को विफल पुनर्लेखन के उदाहरण के रूप में उद्धृत किया गया है। नया लेआउट इंजन (गेको (लेआउट इंजन)) नेविगेटर से स्वतंत्र रूप से विकसित हुआ था और नेविगेटर के कोड के साथ आसानी से एकीकृत नहीं हुआ था; इसलिए नेविगेटर को नए इंजन के आसपास फिर से लिखा गया, कई मौजूदा सुविधाओं को तोड़ दिया और कई महीनों तक रिलीज में देरी की। इस बीच, माइक्रोसॉफ्ट ने इंटरनेट एक्सप्लोरर में वृद्धिशील सुधारों पर ध्यान केंद्रित किया और समान बाधाओं का सामना नहीं किया।[3][6] विडंबना यह है कि नेविगेटर स्वयं उस कार्यक्रम के डेवलपर्स द्वारा देखे गए एनसीएसए मोज़ेक की एक सफल क्लीनरूम पुनर्लेखन था। ब्राउज़र युद्ध देखें।
कुछ परियोजनाएं अपने इतिहास में प्रमुख पुनर्लेखन का उल्लेख करती हैं:
- अपाचे HTTP सर्वर (1)
- एओएल इंस्टेंट मैसेंजर (1)
- बाइंड (1)
- फ्रीनेट (1)
- फ़्यूज़बॉक्स (प्रोग्रामिंग) (2)
- जीएनयू ग्रब (1)
- माजर्डोमो (सॉफ्टवेयर) (1)
- विकिपीडिया का इतिहास#हार्डवेयर और सॉफ्टवेयर (1)
- Mozilla Application Suite का इतिहास | Mozilla/Netscape (1)
- आइसकास्ट (0-1)
- netcat (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.
