“काम कर रहा है तो मत छेड़ो” — यह क्या है, सिद्धांत का सार और जोखिम

“काम कर रहा है तो मत छेड़ो” का सिद्धांत क्या है?

“काम कर रहा है तो मत छेड़ो” — एक अनुभवजन्य नियम है जो डेवलपर्स को बिना पर्याप्त कारण के काम कर रहे कोड में बदलाव करने से सावधान करता है। सिद्धांत सरल आंकड़ों पर आधारित है: अधिकांश दोष मौजूदा कोड में संशोधन के दौरान ही आते हैं।

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

Microsoft कॉर्पोरेशन के एक अध्ययन (2024) के अनुसार, प्रोडक्शन में सभी गंभीर घटनाओं में से लगभग 60% हाल के कोड बदलावों से संबंधित हैं जो अच्छे इरादों से किए गए थे लेकिन वास्तविक लोड स्थितियों में पर्याप्त रूप से परीक्षण नहीं किए गए।

सिद्धांत का इतिहास और उत्पत्ति

यह कहावत “अगर यह टूटा नहीं है, तो इसे मत सुधारो” 20वीं सदी के मध्य की अमेरिकी इंजीनियरिंग संस्कृति से जुड़ी है। सबसे पुराना दस्तावेजी उपयोग बर्ट लांस (1977) को श्रेय दिया जाता है, जो अमेरिकी सीनेट वित्त समिति में काम करते थे और अत्यधिक नियमन के खिलाफ थे।

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

दिलचस्प बात यह है कि प्रोग्रामिंग में इस सिद्धांत का एक उल्टा पहलू भी है — “काम करता है, लेकिन बेहतर है न छेड़ा जाए” अक्सर रिफैक्टरिंग से बचने का बहाना बन जाता है, जो लंबी अवधि में तकनीकी ऋण के गंभीर संचय की ओर ले जाता है। परामर्श फर्म Thoughtworks (2023) के अनुसार, लगभग 40% प्रोजेक्ट्स बदलावों के प्रति अत्यधिक रूढ़िवादिता के कारण गंभीर समस्याओं का सामना करते हैं।

सिद्धांत कब लागू करें

“काम कर रहा है तो मत छेड़ो” का सिद्धांत विशेष रूप से उन स्थितियों में प्रासंगिक है जहां त्रुटि की कीमत बदलावों के संभावित लाभ से अधिक होती है।

बिना टेस्ट वाले लीगेसी प्रोजेक्ट्स

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

महत्वपूर्ण सिस्टम

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

सख्त समयसीमाएं

यदि रिलीज़ कल है और कोड काम कर रहा है — तो उसकी आर्किटेक्चर को बेहतर बनाने की कोशिश न करें। केवल वही बदलें जो सीधे रिलीज़ की कार्यक्षमता को प्रभावित करता है। रिफैक्टरिंग को अगले स्प्रिंट पर टाल दें (लेकिन इसे मत भूलें)।

सिद्धांत का पालन करने के जोखिम

अंधाधुंध सिद्धांत “काम कर रहा है तो मत छेड़ो” का पालन करना अंतहीन रिफैक्टरिंग से कम जोखिम नहीं रखता। आइए मुख्य खतरों पर विचार करें।

तकनीकी ऋण का संचय

यदि हर डेवलपर इस सिद्धांत का पालन करता है, तो कोडबेस जल्दी ही पुराने समाधानों, अस्थायी सुधारों और अनुकूलतम एल्गोरिदम का “लेयर केक” बन जाता है। देर-सबेर तकनीकी ऋण असहनीय हो जाता है — किसी भी बदलाव के लिए हफ्तों के विश्लेषण की आवश्यकता होती है।

छूटा हुआ अनुकूलन

कभी-कभी बदलाव जो जोखिम भरा लगता है, वास्तव में प्रदर्शन या सुरक्षा में काफी सुधार करता है। “काम कर रहा है तो मत छेड़ो” का सिद्धांत उन बदलावों को अवरुद्ध नहीं करना चाहिए जो मापने योग्य लाभ लाते हैं — सर्वर लागत कम करना, पेज लोडिंग तेज करना, सुरक्षा बढ़ाना।

दक्षता का नुकसान

जब टीम वर्षों तक कोड के कुछ हिस्सों को नहीं छेड़ती, तो वह यह समझ खो देती है कि वे कैसे काम करते हैं। मुख्य डेवलपर चला जाता है — और कोड बिना समर्थन क्षमता के लीगेसी बन जाता है। सिद्धांत को प्रोजेक्ट के दीर्घकालिक रखरखाव को ध्यान में रखते हुए लागू किया जाना चाहिए।

सुनहरा मध्य: बिना कट्टरता के रिफैक्टरिंग

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

बॉय स्काउट का नियम

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

टेस्ट के संरक्षण में रिफैक्टरिंग

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

// उदाहरण: टेस्ट कवरेज के तहत सुरक्षित रिफैक्टरिंग
class PriceCalculator {
    fun calculatePrice(basePrice: Double, discount: Double): Double {
        // पुराना लेकिन काम कर रहा कोड
        return basePrice - (basePrice * discount / 100.0)
    }
}

// परीक्षण जो प्रतिगमन से बचाता है
class PriceCalculatorTest {
    fun testCalculatePrice() {
        val calc = PriceCalculator()
        assertEquals(90.0, calc.calculatePrice(100.0, 10.0))
    }
}

यह उदाहरण सही दृष्टिकोण दिखाता है: पहले टेस्ट, फिर रिफैक्टरिंग। अगर टेस्ट पास होता है, तो बदलाव सुरक्षित है। “काम कर रहा है तो मत छेड़ो” का सिद्धांत बदल जाता है “टेस्ट के तहत काम करता है — साहसपूर्वक रिफैक्टर करो” में।

व्यवहार से वास्तविक उदाहरण

आइए वास्तविक परिदृश्यों पर नज़र डालें जहां “काम कर रहा है तो मत छेड़ो” का सिद्धांत जीवन रक्षक और विनाशकारी दोनों साबित हुआ।

जीवन रक्षक मामला: Y2K जैसी समस्या

एक डेवलपर ने पाया कि दिनांक प्रसंस्करण कोड YYYY के बजाय DD/MM/YY प्रारूप का उपयोग कर रहा था। कोड 2000 से 2025 तक सही ढंग से काम कर रहा था। “ठीक” करने की इच्छा के बावजूद, उसने कोड को ज्यों का त्यों छोड़ दिया, केवल एक टिप्पणी जोड़ी। 2026 में, कंपनी ने सिस्टम अपडेट किया, और नए समाधान ने शताब्दियों को सही ढंग से संभाला। समय से पहले बदलाव ने काम कर रहे तर्क को तोड़ दिया होता।

विनाशकारी मामला: “सुधार” के कारण डेटा हानि

एक इंजीनियर ने पुराने लेकिन काम कर रहे डेटा आयात कोड को आधुनिक लाइब्रेरी से बदलकर “सुधारने” का निर्णय लिया। उसने इस बात पर ध्यान नहीं दिया कि पुरानी लाइब्रेरी एक विशिष्ट किनारे के मामले को संभालती थी जो दस्तावेजीकृत नहीं था। रिलीज़ के बाद — बड़े पैमाने पर डेटा हानि। “काम कर रहा है तो मत छेड़ो” के सिद्धांत का उल्लंघन हुआ, और त्रुटि की कीमत टीम के दो सप्ताह के पुनर्प्राप्ति कार्य के बराबर थी।