कोड पुन: उपयोग: Difference between revisions

[[सॉफ़्टवेयर]] विकास (और सामान्य रूप से [[कंप्यूटर प्रोग्रामिंग]]) में, कोड पुन: उपयोग, जिसे सॉफ़्टवेयर पुन: उपयोग भी कहा जाता है, नए सॉफ़्टवेयर के निर्माण के लिए मौजूदा सॉफ़्टवेयर या सॉफ़्टवेयर ज्ञान का उपयोग होता है,<ref>{{cite journal |last=Frakes |first=W.B. |author2=Kyo Kang |s2cid=14561810 |date=July 2005 |title=Software Reuse Research: Status and Future |journal=IEEE Transactions on Software Engineering |volume=31 |issue=7 |pages=529–536 |doi=10.1109/TSE.2005.85 |citeseerx=10.1.1.75.635 }}</ref><ref name="Reddy2011" >{{Cite book|last=Reddy|first=Martin|url=https://www.worldcat.org/oclc/704559821|title=API design for C++|date=2011|publisher=Morgan Kaufmann|isbn=978-0-12-385004-1|location=Boston|oclc=704559821}}</ref>{{Rp|page=7}} पुन: प्रयोज्यता का पालन करना।

चुने गए [[प्रोग्रामिंग भाषा]] की जटिलता के आधार पर कोड का पुन: उपयोग विभिन्न तरीकों से प्राप्त किया जा सकता है और निम्न स्तर के दृष्टिकोण जैसे कोड कट, कॉपी और पेस्ट | कॉपी-पेस्टिंग (उदाहरण के लिए [[स्निपेट (प्रोग्रामिंग)]] के माध्यम से),<ref>{{Cite journal|last1=Selaolo|first1=Karabo|last2=Hlomani|first2=Hlomani|date=2016|title=Towards An Algorithms Ontology Cluster: for Modular Code Reuse and Polyglot Programming|url=https://www.researchgate.net/publication/305144699|journal=Advances in Computer Science|volume=5|pages=63|via=Researchgate}}</ref> सरल कार्य ([[प्रक्रिया (कंप्यूटर विज्ञान)]] या [[सबरूटीन]]्स) या वस्तु का एक गुच्छा (कंप्यूटर विज्ञान) या सबरूटीन [[मॉड्यूलर प्रोग्रामिंग]] (जैसे [[पुस्तकालय (कम्प्यूटिंग)]]) में व्यवस्थित<ref>{{Cite web|title=4. Code Reuse: Functions and Modules - Head First Python, 2nd Edition [Book]|url=https://www.oreilly.com/library/view/head-first-python/9781491919521/ch04.html|access-date=2022-01-26|website=www.oreilly.com|language=en}}</ref>{{r|Reddy2011|page=7|}} या कस्टम [[नाम स्थान]], और [[पैकेज प्रबंधक]], फ्रेमवर्क (कंप्यूटर साइंस) या [[सॉफ्टवेयर सूट]] उच्च-स्तरों में।

कोड का पुन: उपयोग निर्भरता का अर्थ है जो सॉफ़्टवेयर रखरखाव को कठिन बना सकता है। कम से कम एक अध्ययन में पाया गया कि कोड का पुन: उपयोग [[तकनीकी ऋण]] को कम करता है।<ref>{{Cite journal|last1=Feitosa|first1=Daniel|last2=Ampatzoglou|first2=Apostolos|last3=Gkortzis|first3=Antonios|last4=Bibi|first4=Stamatia|last5=Chatzigeorgiou|first5=Alexander|date=September 2020|title=CODE reuse in practice: Benefiting or harming technical debt|url=https://linkinghub.elsevier.com/retrieve/pii/S0164121220300960|journal=Journal of Systems and Software|language=en|volume=167|pages=110618|doi=10.1016/j.jss.2020.110618|s2cid=219502749}}</ref>

कंप्यूटर प्रोग्रामिंग के शुरुआती दिनों से तदर्थ कोड पुन: उपयोग का अभ्यास किया गया है। प्रोग्रामर ने हमेशा कोड, टेम्प्लेट, फ़ंक्शंस और प्रक्रियाओं के अनुभागों का पुन: उपयोग किया है। सॉफ्टवेयर इंजीनियरिंग में अध्ययन के एक मान्यता प्राप्त क्षेत्र के रूप में सॉफ्टवेयर का पुन: उपयोग, हालांकि, केवल 1968 से शुरू होता है जब [[बेल लैब्स]] के [[डगलस मैक्लॉयय]] ने सॉफ्टवेयर उद्योग को पुन: प्रयोज्य घटकों पर आधारित करने का प्रस्ताव दिया था।

कोड पुन: उपयोग का उद्देश्य सॉफ्टवेयर उत्पाद विकास प्रक्रिया के भीतर पहले से ही किसी न किसी रूप में बनाई गई संपत्ति का लाभ उठाकर समय और संसाधनों को बचाना और [[अतिरेक (सूचना सिद्धांत)]] को कम करना है।<ref>{{cite web|author1=Lombard Hill Group|title=What Is Software Reuse?|url=http://lombardhill.com/what_reuse.htm|website=lombardhill.com|publisher=Lombard Hill Group|accessdate=22 October 2014|archive-date=23 January 2019|archive-url=https://web.archive.org/web/20190123223128/http://lombardhill.com/What_Reuse.htm|url-status=dead}}</ref> पुन: उपयोग में मुख्य विचार यह है कि एक समय में लिखे गए [[कंप्यूटर प्रोग्राम]] के कुछ हिस्सों को बाद में लिखे गए अन्य कार्यक्रमों के निर्माण में इस्तेमाल किया जा सकता है या इस्तेमाल किया जाना चाहिए।

कोड का पुन: उपयोग पुन: प्रयोज्य संपत्तियों के एक अलग से बनाए गए संस्करण के निर्माण का अर्थ हो सकता है। जबकि कोड पुन: उपयोग के लिए चुना गया सबसे आम संसाधन है, विकास चक्र के दौरान उत्पन्न अन्य संपत्तियाँ पुन: उपयोग के अवसर प्रदान कर सकती हैं: सॉफ़्टवेयर घटक, परीक्षण सूट, डिज़ाइन, दस्तावेज़ीकरण, और इसी तरह।<ref>{{cite web|author1=Lombard Hill Group|title=What Is Software Reuse?|url=http://lombardhill.com/what_reuse.htm|accessdate=22 October 2014|archive-date=23 January 2019|archive-url=https://web.archive.org/web/20190123223128/http://lombardhill.com/What_Reuse.htm|url-status=dead}}</ref>

लाइब्रेरी (कंप्यूटिंग) कोड पुन: उपयोग का एक अच्छा उदाहरण है। प्रोग्रामर आंतरिक सार बनाने का निर्णय ले सकते हैं ताकि उनके कार्यक्रम के कुछ हिस्सों का पुन: उपयोग किया जा सके, या अपने स्वयं के उपयोग के लिए कस्टम लाइब्रेरी बना सकें। कुछ विशेषताएँ जो सॉफ़्टवेयर को अधिक आसानी से पुन: प्रयोज्य बनाती हैं, वे हैं [[प्रतिरूपकता (प्रोग्रामिंग)]], ढीला युग्मन, उच्च [[सामंजस्य (कंप्यूटर विज्ञान)]], सूचना छिपाना और चिंताओं को अलग करना।

नए लिखित कोड के लिए मौजूदा कोड के एक टुकड़े का उपयोग करने के लिए, किसी प्रकार के [[इंटरफ़ेस (कंप्यूटिंग)]], या संचार के माध्यमों को परिभाषित किया जाना चाहिए। इनमें आमतौर पर एक सबरूटीन, ऑब्जेक्ट (कंप्यूटर साइंस), क्लास (कंप्यूटर साइंस), या [[प्रोटोटाइप-आधारित प्रोग्रामिंग]] का कॉल या उपयोग शामिल होता है। संगठनों में, ऐसी प्रथाओं को [[डोमेन इंजीनियरिंग]] द्वारा औपचारिक और मानकीकृत किया जाता है, जिसे [[उत्पाद परिवार इंजीनियरिंग]] इंजीनियरिंग के रूप में भी जाना जाता है।

अगले संस्करण के लिए एक प्रारंभिक बिंदु के रूप में एक मौजूदा कार्यक्रम के पूर्व संस्करण का उपयोग करने का सामान्य अभ्यास भी कोड पुन: उपयोग का एक रूप है।

कुछ तथाकथित कोड पुन: उपयोग में किसी मौजूदा प्रोग्राम से कुछ या सभी कोड को नए प्रोग्राम में कॉपी करना शामिल है। जबकि संगठन इस दृष्टिकोण के साथ एक नए उत्पाद के लिए बाजार लाभ के लिए समय का एहसास कर सकते हैं, वे बाद में [[कट और पेस्ट प्रोग्रामिंग]] के कारण समान [[कोड दोहराव]] की कई समस्याओं से परेशान हो सकते हैं।

 

एक अन्य, नया साधन सॉफ्टवेयर [[स्रोत कोड पीढ़ी]] का उपयोग करना है, ऐसे प्रोग्राम जो उपयोगकर्ताओं द्वारा चुने गए मापदंडों के एक सेट के आधार पर एक निश्चित प्रकार के नए प्रोग्राम बना सकते हैं। ऐसी प्रणालियों के बारे में अध्ययन के क्षेत्र [[जनरेटिव प्रोग्रामिंग]] और [[मेटाप्रोग्रामिंग]] हैं।

* अवसरवादी - एक परियोजना शुरू करने के लिए तैयार होने के दौरान, टीम को पता चलता है कि ऐसे मौजूदा घटक हैं जिनका वे पुन: उपयोग कर सकते हैं।

* नियोजित - एक टीम रणनीतिक रूप से घटकों को डिज़ाइन करती है ताकि वे भविष्य की परियोजनाओं में पुन: प्रयोज्य हों।

* आंतरिक पुन: उपयोग - एक टीम अपने स्वयं के घटकों का पुन: उपयोग करती है। यह एक व्यावसायिक निर्णय हो सकता है, क्योंकि टीम परियोजना के लिए महत्वपूर्ण घटक को नियंत्रित करना चाहती है।

* बाहरी पुन: उपयोग - एक टीम तीसरे पक्ष के घटक को लाइसेंस देना चुन सकती है। तीसरे पक्ष के घटक को लाइसेंस देने में आम तौर पर टीम को आंतरिक रूप से विकसित करने के लिए 1 से 20 प्रतिशत की लागत आती है।<ref>{{cite book |last=McConnell |first=Steve |title=Rapid Development: Taming Wild Software Schedules |year=1996 |isbn=978-1-55615-900-8 |url-access=registration |url=https://archive.org/details/rapiddevelopment00mcco }}</ref> टीम को घटक को खोजने, सीखने और एकीकृत करने में लगने वाले समय पर भी विचार करना चाहिए।

* संदर्भित - क्लाइंट कोड में पुन: उपयोग किए गए कोड का संदर्भ होता है, और इस प्रकार उनके अलग-अलग जीवन चक्र होते हैं और उनके अलग-अलग संस्करण हो सकते हैं।

* फोर्क्ड - क्लाइंट कोड में पुन: उपयोग किए गए कोड की एक स्थानीय या निजी प्रति होती है, और इस प्रकार वे एक जीवन चक्र और एक संस्करण साझा करते हैं।

फोर्क-पुन: उपयोग को अक्सर हतोत्साहित किया जाता है क्योंकि यह कोड दोहराव का एक रूप है, जिसके लिए आवश्यक है कि प्रत्येक प्रति में प्रत्येक बग को ठीक किया जाए, और पुन: उपयोग किए गए कोड में किए गए संवर्द्धन को प्रत्येक प्रति में मैन्युअल रूप से विलय करने की आवश्यकता होती है या वे पुराने हो जाते हैं। हालांकि, फोर्क-पुन: उपयोग में अलगाव, पुन: उपयोग किए गए कोड को बदलने के लिए लचीलापन, आसान पैकेजिंग, परिनियोजन और संस्करण प्रबंधन जैसे लाभ हो सकते हैं।<ref name="sharednow.blogspot.com"/>

 

व्यवस्थित सॉफ्टवेयर पुन: उपयोग उत्पादकता बढ़ाने और सॉफ्टवेयर उद्योग की गुणवत्ता में सुधार के लिए एक रणनीति है। हालांकि यह अवधारणा में सरल है, सफल सॉफ़्टवेयर पुन: उपयोग कार्यान्वयन व्यवहार में कठिन है। इसके लिए सामने रखा गया एक कारण सॉफ्टवेयर के पुन: उपयोग की उस संदर्भ पर निर्भरता है जिसमें इसे लागू किया गया है। व्यवस्थित सॉफ़्टवेयर पुन: उपयोग से संबंधित कुछ समस्यात्मक मुद्दे जिन्हें संबोधित करने की आवश्यकता है:<ref>{{cite conference |last1=Champman |first1=M. |last2=Van der Merwe |first2=Alta |year=2008 |url=http://portal.acm.org/citation.cfm?id=1456662 |title=Contemplating Systematic Software Reuse in a Small Project-centric Company |book-title=Proceeding SAICSIT '08 Proceedings of the 2008 annual research conference of the South African Institute of Computer Scientists and Information Technologists on IT research in developing countries: riding the wave of technology |doi=10.1145/1456659.1456662 |isbn=978-1-60558-286-3 }}</ref> *एक स्पष्ट और अच्छी तरह से परिभाषित उत्पाद दृष्टि एक [[सॉफ्टवेयर उत्पाद लाइन]] (एसपीएल) के लिए एक आवश्यक आधार है।

*एक विकासवादी कार्यान्वयन रणनीति कंपनी के लिए अधिक व्यावहारिक रणनीति होगी।

*SPL इंजीनियरिंग का समर्थन करने के लिए एक उपयुक्त संगठनात्मक संरचना की आवश्यकता है।

*परियोजना-केंद्रित कंपनी से उत्पाद-उन्मुख कंपनी में मानसिकता का परिवर्तन आवश्यक है।

=== सॉफ्टवेयर पुस्तकालय ===

 

कोड पुन: उपयोग का एक बहुत ही सामान्य उदाहरण लाइब्रेरी (कंप्यूटर विज्ञान) का उपयोग करने की तकनीक है। कई सामान्य संचालन, जैसे विभिन्न प्रसिद्ध स्वरूपों के बीच सूचना को परिवर्तित करना, बाहरी भंडारण तक पहुँचना, बाहरी कार्यक्रमों के साथ इंटरफेस करना, या जानकारी (संख्या, शब्द, नाम, स्थान, दिनांक, आदि) में हेरफेर करना, सामान्य तरीकों से कई अलग-अलग तरीकों से आवश्यक है। कार्यक्रम। नए कार्यक्रमों के लेखक इन कार्यों को करने के लिए एक सॉफ्टवेयर लाइब्रेरी में कोड का उपयोग कर सकते हैं, पहिया को फिर से आविष्कार करने के बजाय, एक ऑपरेशन करने के लिए प्रोग्राम में सीधे पूरी तरह से नया कोड लिखकर। पुस्तकालय के कार्यान्वयन में अक्सर अच्छी तरह से परीक्षण किए जाने और असामान्य या रहस्यमय मामलों को शामिल करने का लाभ होता है। नुकसान में विवरण को बदलने में असमर्थता शामिल है जो प्रदर्शन या वांछित आउटपुट को प्रभावित कर सकता है, और लाइब्रेरी प्राप्त करने, सीखने और कॉन्फ़िगर करने का समय और लागत शामिल है।<ref>{{Cite web|url=http://docforge.com/wiki/Code_reuse|title=Code reuse|access-date={{TODAY}}|work=DocForge|archive-url=https://web.archive.org/web/20110710143019/http://docforge.com/wiki/Code_reuse|url-status=dead|archive-date=2011-07-10}}</ref>

=== डिजाइन पैटर्न ===

डेवलपर्स आमतौर पर तीसरे पक्ष के अनुप्रयोगों और रूपरेखाओं के माध्यम से सॉफ्टवेयर के बड़े टुकड़ों का पुन: उपयोग करते हैं। हालांकि ढांचे आमतौर पर डोमेन-विशिष्ट होते हैं और केवल अनुप्रयोगों के परिवारों पर लागू होते हैं{{citation needed|date=April 2015}}.

=== उच्च-क्रम समारोह ===

{{main article|Higher-order function}}

[[कार्यात्मक प्रोग्रामिंग]] में उच्च-क्रम के कार्यों का उपयोग कई मामलों में किया जा सकता है जहां पहले डिजाइन पैटर्न या ढांचे का उपयोग किया जाता था।

रेट्रोकंप्यूटिंग में कोड का पुन: उपयोग शामिल है, केवल इसलिए कि पुराने कंप्यूटरों पर रेट्रो प्रोग्राम चलाए जा रहे हैं, या उनके लिए एमुलेटर।

कंप्यूटर सुरक्षा कोड-पुन: उपयोग में सॉफ़्टवेयर शोषण विधि के रूप में कार्यरत है।<ref name=Bletsch11>{{Cite book| publisher = North Carolina State University| last = Bletsch| first = Tyler | title = Code-reuse Attacks: New Frontiers and Defenses| date = 2011 |isbn=978-1-124-75297-6 |url=http://dl.acm.org/citation.cfm?id=2338075}}</ref>

जब एक हमलावर किसी प्रोग्राम के नियंत्रण प्रवाह को संशोधित करने के लिए सीधे कोड इनपुट करने में सक्षम नहीं होता है, उदाहरण के लिए W^X जैसे कोड इंजेक्शन सुरक्षा की उपस्थिति में, वह नियंत्रण प्रवाह को स्मृति में मौजूद कोड अनुक्रमों पर पुनर्निर्देशित कर सकता है।

 

 

{{main article|Software component}}

एक वस्तु-उन्मुख सीमा में एक घटक, सहयोगी वर्गों (या केवल एक वर्ग) और उसके इंटरफेस के एक सेट का प्रतिनिधित्व करता है। घटकों के प्रतिस्थापन को सक्षम करने के लिए इंटरफेस जिम्मेदार हैं। पुन: प्रयोज्य घटकों को घटक स्रोत कोड प्रबंधन तकनीकों ([https://github.com/teambit/bit CSCM]) का उपयोग करके SCM रिपॉजिटरी के बीच अलग और सिंक्रनाइज़ किया जा सकता है।{{citation needed|date=April 2015}}

 

कोड पुन: उपयोग की पूरी अवधारणा सॉफ्टवेयर के बाहर इंजीनियरिंग अनुप्रयोगों को भी शामिल कर सकती है। उदाहरण के लिए, [[कंप्यूटर एडेड डिजाइन]] में [[ठोस मॉडलिंग]] पुन: प्रयोज्य डिज़ाइन बनाने की अनुमति देता है। [[मानकीकरण]] के परिणामस्वरूप इंटरऑपरेबल भागों का निर्माण होता है जिसे कई संदर्भों में पुन: उपयोग किया जा सकता है।{{citation needed|date=April 2015}}

 

 

पुन: उपयोग किए जा रहे घटक पर [[युग्मन (कंप्यूटर प्रोग्रामिंग)]] में कोड का पुन: उपयोग होता है। [[रोब पाइक]] ने कहा कि थोड़ी सी नकल थोड़ी निर्भरता से बेहतर है। जब उन्होंने [[Google]] ज्वाइन किया, तब कंपनी कोड के पुन: उपयोग पर बहुत जोर दे रही थी। उनका मानना ​​है कि संकलन गति और रखरखाव के मामले में Google का [[codebase]] अभी भी उस पूर्व नीति के परिणामों से ग्रस्त है।<ref>{{Citation|last=The Go Programming Language|title=Go Proverbs – Rob Pike – Gopherfest – November 18, 2015|date=2015-12-01|url=https://www.youtube.com/watch?v=PAAkCSZUG1c |archive-url=https://ghostarchive.org/varchive/youtube/20211222/PAAkCSZUG1c |archive-date=2021-12-22 |url-status=live|accessdate=26 February 2016}}{{cbignore}}</ref>