प्रोग्रामिंग में बैसाखी — ये क्या हैं, कारण और कब उचित हैं

प्रोग्रामिंग में “बैसाखी” क्या है

बैसाखी (crutch) एक सॉफ्टवेयर समाधान है जो काम करता है लेकिन “जल्दबाजी में” बनाया गया है: यह एक विशिष्ट समस्या का समाधान करता है लेकिन इसके कारण को समाप्त नहीं करता, प्रोजेक्ट की आर्किटेक्चर का पालन नहीं करता, और वातावरण में मामूली बदलावों पर टूट सकता है। रूपक सटीक है — वास्तविक बैसाखी की तरह, ऐसा कोड “चलने” में मदद करता है लेकिन “पैर” को ठीक नहीं करता।

डेवलपर्स बग, वर्जन असंगतताएँ, प्लेटफ़ॉर्म विशेषताएँ और ग्राहक की तत्काल आवश्यकताओं को “बैसाखियों से सहारा” देते हैं। एक सामान्य बैसाखी सशर्त बैसाखी है: यदि iOS 15 है तो पैडिंग जोड़ें, यदि Huawei है तो बटन छिपाएँ। ऐसी जाँचें बढ़ती जाती हैं और कोड को प्लेटफ़ॉर्म और वर्जन शाखाओं के “लेयर केक” में बदल देती हैं।

बैसाखियाँ विभिन्न पैमानों पर आती हैं: एक बैसाखी शर्त वाली एक पंक्ति से लेकर पूरे रैपर मॉड्यूल तक जो लाइब्रेरी के व्यवहार को “ठीक” करता है। यह समझना महत्वपूर्ण है कि बैसाखी हमेशा बुरी नहीं होती: सही हाथों में, यह एक उपकरण है जो उत्पाद को समय पर जारी करने की अनुमति देता है। समस्या तब शुरू होती है जब बैसाखी हमेशा के लिए कोड में रह जाती है।

बैसाखियाँ क्यों दिखाई देती हैं: कारण और संदर्भ

मुख्य कारण बैसाखियों के प्रकट होने का आदर्श समाधान और प्रोजेक्ट की वास्तविक बाधाओं के बीच संघर्ष है। डेवलपर जानता है कि सही तरीके से कैसे करना है, लेकिन समय, पैसा या तकनीकी सीमाएँ इसे रोकती हैं। परिणामस्वरूप, एक समझौता समाधान उभरता है जो “बस काम करता है।”

आइए चार मुख्य कारणों पर नज़र डालें जिनके कारण डेवलपर्स सचेत रूप से बैसाखियों का सहारा लेते हैं। इन कारणों को समझने से बैसाखियों को गलती के रूप में नहीं बल्कि एक व्यावहारिक उपकरण के रूप में देखने में मदद मिलती है जिसे प्रबंधित करने की आवश्यकता है।

डेडलाइन

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

वर्जन असंगति

लाइब्रेरी A को Android 12 की आवश्यकता है, लेकिन आपका ऐप Android 10 का समर्थन करता है। समाधान एक रैपर लिखना है जो OS वर्जन की जाँच करता है और निष्पादन पथ का चयन करता है। यह एक बैसाखी है क्योंकि जब लाइब्रेरी अपडेट की जाती है, तो रैपर को फिर से लिखना होगा। लेकिन विकल्प — लाइब्रेरी या पुराने उपकरणों के समर्थन को छोड़ना — बदतर हो सकता है।

// API 29 संगतता के लिए बैसाखी
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.R) {
    useModernApi()
} else {
    useLegacyFallback()
}

बग वाली तृतीय-पक्ष निर्भरताएँ

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

सिस्टम की अपूर्ण समझ

एक लीगेसी प्रोजेक्ट में नया डेवलपर यह नहीं समझता कि कोड इस तरह क्यों काम करता है। समझने के बजाय, वे मौजूदा शर्तों के ऊपर एक नई शर्त जोड़ते हैं। यह सबसे खतरनाक प्रकार की बैसाखी है क्योंकि लेखक को यह एहसास नहीं होता कि यह एक बैसाखी है। एकमात्र उपाय कोड रिव्यू और नई टीम के सदस्यों के लिए पेयर प्रोग्रामिंग है।

बैसाखी कब उचित है: व्यावहारिक दृष्टिकोण

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

उचित बैसाखी के मानदंड: यह एक विशिष्ट समस्या का समाधान करती है, इसका एक मालिक है (कोई इसके हटाने के लिए जिम्मेदार), और एक रिफैक्टरिंग योजना मौजूद है। यदि इन तीन शर्तों में से कम से कम एक गायब है, तो बैसाखी तकनीकी ऋण में बदल जाती है। ट्रैकर में टिकट के साथ TODO टिप्पणियाँ जैसे उपकरण न्यूनतम दस्तावेज़ीकरण विधि हैं।

एक उचित बैसाखी का उदाहरण

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

// TODO: IT-1234 — AuthService रिफैक्टरिंग के बाद यह बैसाखी हटाएँ
guard let userId = session.user?.id else {
    return Result.failure(.notAuthenticated)
}

अस्थायी बैसाखी को आर्किटेक्चर समस्या से कैसे अलग करें

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

बैसाखी कब समस्या बन जाती है

स्थिति तब बिगड़ जाती है जब बैसाखियों की संख्या महत्वपूर्ण द्रव्यमान से अधिक हो जाती है। प्रत्येक नई बैसाखी सिस्टम की “नाजुकता” को बढ़ाती है: एक स्थान पर परिवर्तन दूसरे को तोड़ देता है। अंततः, डेवलपमेंट धीमा हो जाता है, बग बढ़ जाते हैं, और एक नया डेवलपर लेखक की मदद के बिना कोड नहीं समझ सकता। इस बिंदु पर, बैसाखियाँ अस्थायी समाधान नहीं रह जातीं और एक आर्किटेक्चर समस्या बन जाती हैं।

बैसाखी संकट के संकेत

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

• एक ही बैसाखी तीन या अधिक स्थानों पर दोहराई जाती है — एक समान समाधान बनाने का समय
• बैसाखी बिना हटाने की योजना के तीन स्प्रिंट से अधिक जीवित रहती है — यह पहले से ही तकनीकी ऋण है
• नया डेवलपर नहीं समझता कि कोड इस तरह क्यों काम करता है — बैसाखी दस्तावेज़ीकृत नहीं है
• बैसाखी को हटाने से त्रुटियों की श्रृंखला प्रतिक्रिया होती है — बैसाखी पर निर्भरता आर्किटेक्चरल हो गई है

बैसाखियों का रिफैक्टरिंग: रणनीति और अभ्यास

बैसाखियों का रिफैक्टरिंग अस्थायी समाधानों को आर्किटेक्चरली सही समाधानों से बदलने की प्रक्रिया है। इसमें समय लगता है, इसलिए प्राथमिकता रणनीति की आवश्यकता है: सभी बैसाखियों को तुरंत समाप्त करने की आवश्यकता नहीं है। एक अच्छी रणनीति प्रत्येक बैसाखी का मूल्यांकन दो मापदंडों पर करना है: कोड के उस क्षेत्र में परिवर्तनों की आवृत्ति और उपयोगकर्ताओं पर प्रभाव।

प्राथमिकता रणनीति

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

चरण-दर-चरण हटाने की प्रक्रिया

चरण 1: सूची — बैसाखियों से संबंधित सभी TODO और FIXME खोजें। चरण 2: मूल्यांकन — निर्धारित करें कि कौन से अभी भी प्रासंगिक हैं। चरण 3: योजना — उच्च प्राथमिकता वाली बैसाखियों से शुरू करते हुए, स्प्रिंट में बैसाखी रिफैक्टरिंग निर्धारित करें। चरण 4: प्रतिस्थापन — साफ समाधान लागू करें, बैसाखी और उसकी TODO टिप्पणी हटाएँ। चरण 5: सत्यापन — सुनिश्चित करें कि परीक्षण पास हों और कोई रिग्रेशन न हो।

# प्रोजेक्ट में सभी TODO बैसाखियाँ खोजें
grep -r "TODO\|FIXME\|HACK\|XXX" --include="*.kt" --include="*.swift" .

नई बैसाखियों को रोकना

बैसाखियों से लड़ने का सबसे अच्छा तरीका है उन्हें अनावश्यक रूप से न बनाना. बैसाखी लिखने से पहले, अपने आप से तीन प्रश्न पूछें: क्या मैं उचित समय में साफ समाधान लागू कर सकता हूँ? क्या कोई विकल्प है जो बैसाखी नहीं है? क्या टीम के पास वापस आकर इसे फिर से लिखने का समय होगा? यदि कम से कम एक प्रश्न का उत्तर “नहीं” है — कोड को “सहारा” देने से पहले फिर से सोचें।