ऐप डेवलपमेंट में कॉपीपेस्ट — यह क्या है, यह खतरनाक क्यों है और इससे कैसे बचें

कॉपीपेस्ट क्या है?

कॉपीपेस्ट (कॉपी-पेस्ट प्रोग्रामिंग) मौजूदा कोड को मामूली या बिना बदलाव के नए स्थान पर ले जाना है। इस शब्द का प्रयोग अपमानजनक अर्थ में किया जाता है: इसका तात्पर्य है कि डेवलपर कोई समाधान डिज़ाइन नहीं कर रहा है, बल्कि यांत्रिक रूप से एक तैयार ब्लॉक कॉपी कर रहा है, अक्सर यह पूरी तरह से समझे बिना कि यह कैसे काम करता है।

कॉपीपेस्ट दो प्रकार का होता है: जानबूझकर (intentional) और आकस्मिक (accidental)। जानबूझकर — जब डेवलपर बाद में रिफैक्टरिंग की योजना के साथ जानबूझकर कोड कॉपी करता है (लेकिन योजना अक्सर छोड़ दी जाती है)। आकस्मिक — जब डुप्लिकेशन बिना ध्यान दिए उत्पन्न होता है, उदाहरण के लिए, दो डेवलपर अलग-अलग स्क्रीन के लिए स्वतंत्र रूप से एक ही लॉजिक लिखते हैं।

SonarQube State of Clean Code (2025) रिपोर्ट के अनुसार, वाणिज्यिक प्रोजेक्ट्स में डुप्लिकेटेड कोड कुल कोड वॉल्यूम का औसतन 12–18 प्रतिशत होता है। वहीं, डुप्लिकेटेड कोड में बग ठीक करने की लागत एकल इम्प्लीमेंटेशन वाले कोड की तुलना में 2.5 गुना अधिक होती है, क्योंकि डेवलपर को सभी कॉपियाँ ढूँढ़नी और ठीक करनी होती हैं।

कॉपीपेस्ट के खिलाफ प्राथमिक उपकरण DRY (Don't Repeat Yourself) सिद्धांत है। हालांकि, DRY को निरपेक्ष बनाना भी खतरनाक है: कभी-कभी कॉपी करना उचित होता है जब दो कॉपियों को एक-दूसरे से स्वतंत्र रूप से विकसित होना चाहिए। “आकस्मिक डुप्लिकेशन” (जिसे समाप्त किया जाना चाहिए) और “आवश्यक डुप्लिकेशन” (जिसे दस्तावेज़ित किया जाना चाहिए) के बीच अंतर करना महत्वपूर्ण है।

कॉपीपेस्ट खतरनाक क्यों है

पहला और सबसे महत्वपूर्ण खतरा है बग का प्रसार। यदि मूल कोड में कोई दोष है, तो वह कोड के साथ सभी नए स्थानों पर कॉपी हो जाता है। जब दोष का पता चलता है और मूल मॉड्यूल में ठीक किया जाता है, तो कॉपियाँ अनफिक्स्ड रहती हैं। डेवलपर को पता भी नहीं चल सकता कि बग पाँच अलग-अलग फ़ाइलों में मौजूद है।

दूसरा खतरा है असमान विकास। एक ही एल्गोरिदम की दो कॉपियाँ समय के साथ अलग-अलग संशोधन जमा करती हैं। एक कॉपी में बाउंड्री वैल्यू वैलिडेशन जोड़ा जाता है, दूसरी में आउटपुट फ़ॉर्मेट बदला जाता है। कुछ महीनों के बाद, यह बताना असंभव हो जाता है कि कौन सा संस्करण “सही” है, और प्रोजेक्ट व्यवहारिक स्थिरता खो देता है।

तीसरा खतरा है बढ़ी हुई टेस्ट वॉल्यूम। प्रत्येक कॉपीपेस्ट इंस्टेंस को अपने स्वयं के टेस्ट की आवश्यकता होती है। यदि सामान्य लॉजिक को एक फंक्शन में निकाला जाए, तो इसे टेस्ट के एक सेट से कवर किया जा सकता है और पुनः उपयोग किया जा सकता है। डुप्लिकेशन के साथ, प्रत्येक कॉपी का अलग-अलग परीक्षण किया जाना चाहिए — यह CI रन टाइम और बनाए रखने वाले टेस्ट बेस के आकार को कई गुना बढ़ा देता है।

चौथा खतरा है उत्पादकता का भ्रम। कॉपीपेस्ट गति की झूठी भावना पैदा करता है: डेवलपर जल्दी से कोड पेस्ट करता है और देखता है कि स्क्रीन काम कर रही है। लेकिन यह “गति” तकनीकी ऋण में बदल जाती है जिसे ब्याज सहित चुकाना होगा जब डुप्लिकेटेड ब्लॉक में कोई बग मिलता है या बिज़नेस लॉजिक में बदलाव की आवश्यकता होती है।

डेवलपर कोड क्यों कॉपी करते हैं

कॉपीपेस्ट के कारणों को समझना उचित रोकथाम स्थापित करने में मदद करता है। अक्सर, डेवलपर आलस्य से नहीं, बल्कि समय सीमा के दबाव, ज्ञान की कमी या असुविधाजनक आर्किटेक्चर के कारण कोड कॉपी करते हैं।

पहला कारण है समय सीमा। जब दो दिनों में एक स्क्रीन बनानी होती है और एक समान स्क्रीन पहले से मौजूद है, तो डेवलपर इसे पूरी तरह कॉपी करता है और केवल वही बदलता है जो उपयोगकर्ता देखता है। साझा कंपोनेंट निकालने और रिफैक्टर करने का समय नहीं है — ग्राहक परिणाम चाहता है। परिणामस्वरूप, 80 प्रतिशत साझा कोड लेकिन संशोधनों के स्वतंत्र इतिहास के साथ दूसरी स्क्रीन दिखाई देती है।

दूसरा कारण है एकीकृत एब्स्ट्रैक्शन का अभाव। यदि प्रोजेक्ट में किसी विशिष्ट कार्य (जैसे, पुल-टू-रिफ्रेश वाली सूची स्क्रीन) के लिए कोई साझा कंपोनेंट नहीं है, तो प्रत्येक डेवलपर अपना स्वयं का इम्प्लीमेंटेशन लिखेगा या पड़ोसी की कॉपी करेगा। प्रोजेक्ट की शुरुआत में लिए गए आर्किटेक्चरल निर्णय सीधे भविष्य के कॉपीपेस्ट की मात्रा को प्रभावित करते हैं।

तीसरा कारण है काम कर रहे कोड को तोड़ने का डर। डेवलपर जानता है कि मौजूदा मॉड्यूल काम करता है। साझा कोड निकालने के लिए रिफैक्टरिंग मौजूदा कार्यक्षमता को प्रभावित कर सकती है। यदि टेस्ट कवरेज कम है, तो टूटने का जोखिम रिफैक्टरिंग के अनुमानित लाभ से अधिक होता है, और डेवलपर सुरक्षित रास्ता चुनता है — कॉपी करना।

लक्षणों के बजाय कारणों को संबोधित करें। यदि प्रोजेक्ट में ठोस आर्किटेक्चरल नींव नहीं है तो समय सीमा कम करना और कोड रिव्यू शुरू करना समस्या का समाधान नहीं करेगा। शुरुआती चरणों में पुन: प्रयोज्य कंपोनेंट बनाने में समय निवेश करें — भविष्य में कॉपीपेस्ट के प्रलोभन को कम करने का यही एकमात्र तरीका है।

डुप्लिकेट डिटेक्शन टूल

कॉपीपेस्ट डिटेक्शन स्वचालित विश्लेषकों द्वारा किया जाता है जो कोड टुकड़ों की तुलना करते हैं और एक निश्चित सीमा से ऊपर मिलान की पहचान करते हैं। सबसे अच्छे उपकरण AST (एब्स्ट्रैक्ट सिंटैक्स ट्री) स्तर पर काम करते हैं और फ़ॉर्मेटिंग, वेरिएबल नाम और टिप्पणियों को अनदेखा करते हैं।

PMD CPD (Copy-Paste Detector) Java, Kotlin, Swift, JavaScript, Python और C++ के लिए सबसे आम उपकरण है। CPD सोर्स कोड टोकन का विश्लेषण करता है और एक निर्दिष्ट न्यूनतम टोकन संख्या (डिफ़ॉल्ट 100) से अधिक लंबे डुप्लिकेट ढूँढता है। गुणवत्ता परिणामों के लिए सीमा को कॉन्फ़िगर करना महत्वपूर्ण है: बहुत कम सीमा कई झूठी सकारात्मकता देती है (सामान्य पैटर्न जैसे इम्पोर्ट), बहुत अधिक सीमा वास्तविक डुप्लिकेट को छोड़ देती है।

Gradle के माध्यम से PMD CPD चलाना

plugins {
    id 'pmd'
}

pmd {
    toolVersion = '7.0.0'
    ruleSetFiles = files("pmd-rules.xml")
}

tasks.register('cpd') {
    doLast {
        exec {
            workingDir = projectDir
            commandLine 'cpd',
                '--minimum-tokens', '75',
                '--language', 'kotlin',
                '--files', 'src/main/kotlin',
                '--format', 'xml',
                '--failOnViolation', 'true'
        }
    }
}

SonarQube डुप्लिकेट डिटेक्टर को सीधे Quality Gate में एम्बेड करता है। Duplicated Blocks (%) नियम डुप्लिकेटेड कोड का प्रतिशत दिखाता है। वाणिज्यिक प्रोजेक्ट्स के लिए 5 प्रतिशत की सीमा स्वस्थ मानी जाती है। इससे अधिक होने पर रिलीज़ ब्रांच में प्रमोशन ब्लॉक हो जाता है। SonarQube अतिरिक्त रूप से डुप्लिकेट को प्रकार के अनुसार समूहित करता है: सटीक मिलान और संरचनात्मक कॉपियाँ (पुनर्नामित पहचानकर्ताओं के साथ)।

JavaScript और TypeScript के लिए, डुप्लिकेट का पता ESLint में eslint-plugin-sonarjs प्लगइन (no-duplicate-string नियम) और jscpd उपयोगिता का उपयोग करके लगाया जाता है, जो 150+ भाषाओं का समर्थन करती है। jscpd विशेष रूप से मोनोरेपो के लिए सुविधाजनक है: यह सिर्फ एक मॉड्यूल के भीतर ही नहीं, बल्कि पैकेजों के बीच डुप्लिकेट ढूँढता है।

डुप्लिकेटेड कोड रिफैक्टरिंग की रणनीतियाँ

कॉपीपेस्ट रिफैक्टरिंग एक सिद्धांत पर आधारित है: सामान्य भाग निकालें और अंतरों को पैरामीटराइज़ करें। विशिष्ट तकनीक डुप्लिकेशन के दायरे और संदर्भ पर निर्भर करती है।

सबसे सरल मामला है एक ही क्लास के भीतर डुप्लिकेशन (उदाहरण के लिए, समान लॉजिक लेकिन अलग-अलग प्रकार वाली दो विधियाँ)। समाधान जेनेरिक के साथ सामान्यीकरण करना या टाइप पैरामीटर के साथ विधि का पुन: उपयोग करना है। यदि डुप्लिकेशन कई क्लासों में फैला है — सामान्य कोड को यूटिलिटी क्लास या एक्सटेंशन फंक्शन में निकालें।

अधिक जटिल मामला है स्क्रीन या मॉड्यूल स्तर पर डुप्लिकेशन। यहाँ, केवल एक फंक्शन निकालने से मदद नहीं मिलती, क्योंकि UI संरचना, लाइफसाइकिल लॉजिक और डेटा बाइंडिंग सभी डुप्लिकेट हैं। समाधान एक सामान्य बेस स्क्रीन क्लास या एक कम्पोज़िट व्यू कंपोनेंट बनाना है, और अंतरों को पैरामीटर या प्रोटोकॉल के माध्यम से पास करना है।

// before - two copies of the same UITableViewController
class UserListController: UITableViewController {
    private let viewModel = UserListViewModel()
    // 40 lines of code
}

class ProductListController: UITableViewController {
    private let viewModel = ProductListViewModel()
    // same 40 lines but with Product instead of User
}

// after - generic base class shared
class ListViewController<T: ListViewModel>: UITableViewController {
    let viewModel: T
    // 40 lines of code - once only

    init(viewModel: T) {
        self.viewModel = viewModel
        super.init(style: .plain)
    }
}

सबसे जटिल मामला है माइक्रोसर्विसेज या लाइब्रेरीज़ के बीच डुप्लिकेशन। साझा कोड निकालने से चक्रीय निर्भरता या अनुचित युग्मन हो सकता है। ऐसे मामलों में, कॉपीपेस्ट एक सचेत निर्णय हो सकता है: दो टीमें स्वतंत्र सेवाओं का रखरखाव करती हैं, और एक साझा लाइब्रेरी समस्याओं को हल करने से अधिक पैदा करती है। मुख्य बात इस तरह के निर्णय का दस्तावेज़ीकरण करना और नियमित रूप से जाँचना है कि क्या कॉपियाँ एकीकरण को उचित ठहराने के लिए पर्याप्त रूप से भिन्न हो गई हैं।

टीम स्तर पर कॉपीपेस्ट की रोकथाम

कॉपीपेस्ट को रोकना पहले से डुप्लिकेटेड कोड को रिफैक्टर करने से अधिक प्रभावी है। मुख्य निवारक उपाय प्रौद्योगिकी में नहीं, बल्कि विकास प्रक्रिया के आयोजन में निहित हैं।

पहला उपाय है डुप्लिकेशन पर ध्यान देने वाला कोड रिव्यू। रिव्यू चेकलिस्ट में यह आइटम शामिल होना चाहिए: “क्या इस PR में वह कोड है जो पहले से प्रोजेक्ट में मौजूद है?” यदि रिव्यूअर को कॉपीपेस्ट दिखता है — तो वह साझा कंपोनेंट निकाले जाने तक मर्ज को ब्लॉक कर देता है। यह आवश्यकता टीम की Definition of Done का हिस्सा होनी चाहिए।

दूसरा उपाय है साझा कंपोनेंट लाइब्रेरी। प्रत्येक UI पैटर्न जो दो या अधिक स्क्रीन पर दिखाई देता है, उसे एक सामान्य मॉड्यूल में निकाला जाना चाहिए। प्रोजेक्ट में एक शेयर्ड मॉड्यूल बनाएं और इसे सभी UI कंपोनेंट्स के लिए अनिवार्य एंट्री पॉइंट बनाएं। यदि कोई कंपोनेंट मौजूद नहीं है — इसे पहले बनाया जाता है, फिर स्क्रीन पर उपयोग किया जाता है।

तीसरा उपाय है CI/CD में ऑटोमेशन। पाइपलाइन में डुप्लिकेटेड कोड जाँच चरण जोड़ें (PMD CPD, jscpd, SonarQube)। सीमा से अधिक होने पर बिल्ड विफल होता है। डेवलपर एक PR मर्ज नहीं कर सकता जो कॉपीपेस्ट अनुपात को अनुमत स्तर से ऊपर बढ़ाता है। यह जिम्मेदारी कोड रिव्यू से ऑटोमेशन पर स्थानांतरित करता है और सुनिश्चित करता है कि कोई भी डुप्लिकेट अनदेखा न हो।

“एक इम्प्लीमेंटेशन — एक स्थान” की संस्कृति को बढ़ावा दें। यदि आपको पुन: उपयोग का अवसर दिखता है — तो रिफैक्टरिंग को बाद के लिए न टालें। प्रत्येक कॉपीपेस्ट जो “बाद के लिए” छोड़ा जाता है, कई गुना बढ़ जाता है और बेकाबू तकनीकी ऋण में बदल जाता है।