डेवलपमेंट में जंक — यह क्या है, जंक कोड हानिकारक क्यों है और इसे कैसे हटाएँ

जंक कोड क्या है?

जंक (junk code) कोड, कॉन्फ़िगरेशन और डिपेंडेंसी के लिए एक सामूहिक शब्द है जो प्रोजेक्ट में मौजूद हैं लेकिन कोई कार्यात्मक मूल्य प्रदान नहीं करते। जंक ज़रूरी नहीं कि टूटा हुआ या अप्रयुक्त हो — समस्या यह है कि इसकी उपस्थिति पर्याप्त औचित्य के बिना प्रोजेक्ट मीट्रिक्स को खराब करती है।

जंक चार श्रेणियों में बाँटा गया है। पहली — अतिरिक्त डिपेंडेंसी: एक ही फीचर के लिए जोड़ी गई लाइब्रेरी जिसे मानक टूल से लागू किया जा सकता था। दूसरी — मृत बोझ: टिप्पणी किए गए ब्लॉक, बिना टिकट के TODO, खाली विधियाँ और स्टब क्लास। तीसरी — डुप्लिकेट समाधान: दो लाइब्रेरी एक ही काम करती हैं (जैसे एक प्रोजेक्ट में Gson और Kotlin Serialization)। चौथी — ओवर-इंजीनियरिंग: आर्किटेक्चरल लेयर जो उपयोग नहीं होतीं लेकिन “जस्ट इन केस” बनाए रखी जाती हैं।

Stripe Engineering Productivity (2025) शोध के अनुसार, एक सामान्य प्रोजेक्ट से 10 प्रतिशत जंक हटाने से पूर्ण बिल्ड समय में औसतन 22 प्रतिशत की कमी आती है। कारण: हर अतिरिक्त डिपेंडेंसी बिल्ड ग्राफ़ बढ़ाती है, हर खाली अब्स्ट्रैक्शन समझने में समय लेता है, हर टिप्पणी किया गया ब्लॉक ध्यान भटकाता है।

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

जंक डिपेंडेंसी और उन्हें कैसे पहचानें

जंक डिपेंडेंसी वे लाइब्रेरी और पैकेज हैं जो प्रोजेक्ट में जोड़े गए हैं लेकिन कोड में सीधे उपयोग नहीं होते, या केवल एक ही फीचर के लिए उपयोग होते हैं जिसे मानक APIs से लागू करना आसान होगा।

सामान्य उदाहरण: JSON प्रोसेसिंग के लिए लाइब्रेरी जब प्रोजेक्ट पहले से Kotlin Serialization का उपयोग करता है (दो पार्सर जंक है); एक StringUtils.isEmpty कॉल के लिए Apache Commons Lang लाइब्रेरी जिसे Kotlin extension isNullOrBlank से बदला जा सकता है; दस में से एक मॉड्यूल में उपयोग की जाने वाली DI लाइब्रेरी जबकि अन्य मैन्युअल रूप से कंस्ट्रक्टर के माध्यम से डिपेंडेंसी प्राप्त करते हैं।

हर अतिरिक्त डिपेंडेंसी बाइनरी में सिर्फ अतिरिक्त कोड नहीं है। यह कमज़ोरियों के लिए हमले की सतह बढ़ाती है: GitHub Advisory Database (2025) के अनुसार, मोबाइल प्रोजेक्ट्स में 40 प्रतिशत गंभीर CVE ट्रांज़िटिव डिपेंडेंसी से आते हैं जिन्हें डेवलपर नियंत्रित नहीं करते। जितनी कम डिपेंडेंसी, उतनी छोटी हमले की सतह।

Android प्रोजेक्ट डिपेंडेंसी विश्लेषण

// View Gradle dependency tree
./gradlew app:dependencies --configuration releaseRuntimeClasspath

// Find unused dependencies (Gradle plugin)
plugins {
    id "com.autonomousapps.dependency-analysis" version "2.0.0"
}

// Generate unused library report
./gradlew buildHealth

iOS के लिए, swift package show-dependencies कमांड का उपयोग करें जो पूरा डिपेंडेंसी ट्री दिखाता है। Xcode Build Timeline टूल दिखाता है कि प्रत्येक लाइब्रेरी बिल्ड में कितना समय जोड़ती है। यदि कोई लाइब्रेरी 30 प्रतिशत कंपाइलेशन समय लेती है लेकिन एक स्क्रीन पर उपयोग होती है, तो वह हटाने या बदलने के लिए उम्मीदवार है।

Node.js (React Native) के लिए, depcheck का उपयोग करें — एक उपयोगिता जो package.json में अप्रयुक्त डिपेंडेंसी ढूँढती है, और npm-check जो अतिरिक्त रूप से पुराने संस्करण दिखाती है। एक नियम लागू करें: प्रत्येक नई डिपेंडेंसी को “मानक टूल का उपयोग क्यों नहीं किया जा सकता” के औचित्य के साथ कोड समीक्षा से गुज़रना होगा।

मृत इम्पोर्ट और टिप्पणी किया गया कोड

मृत इम्पोर्ट सबसे सामान्य प्रकार का जंक है। वे रनटाइम को प्रभावित नहीं करते लेकिन कंपाइलेशन समय बढ़ाते हैं: कंपाइलर हर इम्पोर्ट को प्रोसेस करता है, भले ही वह अप्रयुक्त हो। बड़े प्रोजेक्ट्स में, अप्रयुक्त इम्पोर्ट हटाने से बिल्ड समय 5–10 प्रतिशत कम होता है।

आधुनिक IDE स्वचालित रूप से अप्रयुक्त इम्पोर्ट को ग्रे रंग में हाइलाइट करते हैं। फ़ाइल सेव करने पर ऑटो-क्लीनअप सेट करें: IntelliJ IDEA में — Optimize Imports on the fly, Xcode में — Editor > Remove Unused Imports। CI में एक जाँच जोड़ें: लिंटर को अप्रयुक्त इम्पोर्ट वाले कमिट को ब्लॉक करना चाहिए।

टिप्पणी किया गया कोड एक और प्रकार का जंक है। डेवलपर रीफ़ैक्टरिंग के दौरान कार्यक्षमता को “खोने से बचाने” के लिए ब्लॉक कमेंट करते हैं। हालाँकि, git परिवर्तनों का पूरा इतिहास संग्रहीत करता है: किसी भी हटाए गए कोड को एक git revert या git log -S कमांड से पुनर्स्थापित किया जा सकता है। master में टिप्पणी किया गया कोड टीम के प्रति अनादर है: प्रत्येक डेवलपर मानसिक ऊर्जा इस प्रश्न पर खर्च करता है “यह क्यों कमेंट किया गया है और कब अनकमेंट किया जाना चाहिए?”

नियम: रिपॉजिटरी में कोई टिप्पणी किया गया कोड नहीं है। यदि कोड की आवश्यकता नहीं है, तो इसे स्थायी रूप से हटा दें। यदि कोड आवश्यक है लेकिन अस्थायी रूप से अक्षम है, तो टिकट और समाप्ति तिथि के साथ फीचर टॉगल का उपयोग करें। // TODO: remove after migration जैसी टिप्पणियाँ — बिना समय सीमा के न छोड़ें। एक तिथि निर्धारित करें और कैलेंडर से स्वयं को याद दिलाएँ।

अतिरिक्त अब्स्ट्रैक्शन और ओवर-इंजीनियरिंग

ओवर-इंजीनियरिंग आर्किटेक्चरल लेयर बनाना है जो वर्तमान समस्याओं का समाधान नहीं करतीं लेकिन रखरखाव की माँग करती हैं। यह जंक के सबसे कठिन प्रकारों में से एक है क्योंकि औपचारिक रूप से कोड “सही” है: यह SOLID का पालन करता है, परीक्षणों से कवर है और आर्किटेक्चर के अनुरूप है। समस्या यह है कि यह आवश्यक नहीं है।

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

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

कट-ऑफ मानदंड: यदि कोई अब्स्ट्रैक्शन तीन अलग-अलग संदर्भों में पुन: उपयोग नहीं किया जाता, तो उसे हटा दें। अब्स्ट्रैक्शन तब उचित है जब वह वास्तव में दोहराव की समस्या का समाधान करता है, काल्पनिक भविष्य परिदृश्यों की भविष्यवाणी नहीं करता। YAGNI (You Ain’t Gonna Need It) ओवर-इंजीनियरिंग को रोकने का सबसे अच्छा सिद्धांत है।

जंक ऑडिट टूल

जंक ऑडिट के लिए स्थैतिक विश्लेषण, डिपेंडेंसी विश्लेषण और मैन्युअल समीक्षा के संयोजन की आवश्यकता होती है। अतिरिक्त अब्स्ट्रैक्शन की खोज को पूरी तरह से स्वचालित करना असंभव है, लेकिन तकनीकी जंक (मृत इम्पोर्ट, अप्रयुक्त लाइब्रेरी, टिप्पणी किया गया कोड) टूल से पाया जा सकता है।

पूर्ण ऑडिट के लिए, प्रति स्प्रिंट buildHealth (Android) या depcheck (Node.js) चलाएँ। CI में एक डैशबोर्ड बनाएँ जो स्प्रिंट दर स्प्रिंट डिपेंडेंसी संख्या की प्रवृत्ति दिखाता है। यदि संख्या बढ़ती है लेकिन कार्यक्षमता आनुपातिक रूप से नहीं बढ़ती, तो टीम जंक जमा कर रही है।

डुप्लिकेट क्लास पर ध्यान दें — एक त्रुटि जब दो लाइब्रेरी में एक ही क्लास हो। यह न केवल जंक है बल्कि बिल्ड संघर्षों का सीधा स्रोत भी है। Gradle में, ऐसे संघर्ष force या exclude के माध्यम से हल किए जाते हैं, लेकिन प्रत्येक ऐसा समाधान संकेत है कि एक लाइब्रेरी अतिरिक्त है।

नियमित प्रोजेक्ट सफाई प्रक्रिया

जंक सफाई एक बार की कार्रवाई नहीं बल्कि एक नियमित प्रक्रिया है। प्रक्रिया के बिना, जंक दो-तीन स्प्रिंट के भीतर वापस आ जाता है। सबसे अच्छा अभ्यास प्रत्येक स्प्रिंट की 10–15 प्रतिशत क्षमता तकनीकी सफाई के लिए आवंटित करना है, जिसमें जंक ऑडिट शामिल है।

प्रक्रिया में चार चरण हैं। पहला — निदान: टूल चलाएँ, रिपोर्ट प्राप्त करें, प्राथमिकता निर्धारित करें। उच्च प्राथमिकता: ज्ञात CVE वाली डिपेंडेंसी और डुप्लिकेट लाइब्रेरी। मध्यम प्राथमिकता: मृत इम्पोर्ट और टिप्पणी किया गया कोड। निम्न प्राथमिकता: अतिरिक्त अब्स्ट्रैक्शन (मैन्युअल विश्लेषण आवश्यक)।

दूसरा — सफाई: मृत डिपेंडेंसी हटाएँ, डुप्लिकेट लाइब्रेरी को एक से बदलें, टिप्पणी किया गया कोड हटाएँ। प्रत्येक परिवर्तन स्पष्ट संदेश के साथ अलग कमिट होना चाहिए: “remove unused dependency: gson (replaced by kotlinx.serialization)”, “delete commented code in LoginViewModel.”

तीसरा — सत्यापन: प्रोजेक्ट बनाएँ, परीक्षण चलाएँ, UI जाँचें। यदि डिपेंडेंसी हटाने के बाद परीक्षण पास होते हैं, तो डिपेंडेंसी वास्तव में अनावश्यक थी। यदि परीक्षण विफल होते हैं, तो कहीं छिपा हुआ संदर्भ है जिसे स्थैतिक विश्लेषक ने नहीं पाया।

चौथा — रोकथाम: कोड समीक्षा चेकलिस्ट अपडेट करें, Definition of Done में “बिना औचित्य के कोई नई डिपेंडेंसी नहीं” नियम जोड़ें, CI में स्वचालित जाँच सेट करें। रोकथाम ही जंक को फिर से जमा होने से रोकने का एकमात्र तरीका है।