लेगसी C# कोड का रीफैक्टरिंग: उन्नत तकनीकें और अभ्यास

परिचय: जब कोड लेगसी में बदल जाता है

एक बड़ी कंपनी में काम करने वाला हर C# डेवलपर, देर-सबेर उन प्रोजेक्ट्स का सामना करता है जो 5, 10 या 15 साल पुराने होते हैं। ऐसे कोड को लेगसी कहा जाता है। यह काम करता है, पैसा कमाता है, लेकिन इसमें हर बदलाव एक जोखिम होता है। परीक्षणों की कमी, टाइट कपलिंग (tight coupling), हज़ारों पंक्तियों वाली विशाल क्लासेस, मैजिक स्ट्रिंग्स और कॉपी-पेस्ट — यही लेगसी की वास्तविकता है।

यहाँ सरल "अंदाज़ से" रीफैक्टरिंग काम नहीं करेगी। उन्नत रणनीतियों की आवश्यकता है जो बिज़नेस लॉजिक को तोड़े बिना धीरे-धीरे कोड को बेहतर बनाने की अनुमति दें। इस लेख में, हम उन्नत स्तर पर C# (.NET) लेगसी सिस्टम के रीफैक्टरिंग के लिए 4 प्रमुख दृष्टिकोणों पर चर्चा करेंगे।

1. "Strangler Fig" रणनीति: सिस्टम को रोके बिना मॉड्यूल बदलना

Strangler Fig (गला घोंटने वाला फ़िकस) पैटर्न — लेगसी घटकों को धीरे-धीरे बदलने के लिए एक क्लासिक तरीका है। सार: आप पूरे सिस्टम को एक साथ फिर से नहीं लिखते, बल्कि धीरे-धीरे पुराने मॉड्यूल के कॉल को इंटरसेप्ट करते हैं और उन्हें नए मॉड्यूल पर रीडायरेक्ट करते हैं।

C# में कैसे कार्यान्वित करें

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

// पुराना इंटरफ़ेस (पहले से मौजूद)\npublic interface IOrderProcessor\n{\n    void Process(Order order);\n}\n\n// पुराना कार्यान्वयन (लेगसी)\npublic class OldOrderProcessor : IOrderProcessor\n{\n    public void Process(Order order)\n    {\n        // कई वर्षों से काम कर रहा, लेकिन गंदा कोड\n    }\n}

हम एक नया कार्यान्वयन और फ़ीचर टॉगल के साथ एक फ़ैक्टरी बनाते हैं:

public class NewOrderProcessor : IOrderProcessor\n{\n    public void Process(Order order)\n    {\n        // नया, साफ कोड\n    }\n}\n\npublic class OrderProcessorFactory\n{\n    public IOrderProcessor Create()\n    {\n        // उदाहरण: कॉन्फ़िग के अनुसार स्विच करें\n        if (ConfigurationManager.AppSettings["UseNewProcessor"] == "true")\n            return new NewOrderProcessor();\n        return new OldOrderProcessor();\n    }\n}

अब आप 5% उपयोगकर्ताओं के लिए नया प्रोसेसर चालू कर सकते हैं, त्रुटियों की निगरानी कर सकते हैं और धीरे-धीरे प्रतिशत बढ़ा सकते हैं। जब पुराना कोड अनावश्यक हो जाए, तो उसे हटा दें।

2. कोर को अलग करना: Dependency Injection के माध्यम से Separation of Concerns

लेगसी कोड अक्सर God-क्लासेस (देवता क्लासेस) और डेटाबेस, फ़ाइल सिस्टम, बाहरी API पर सीधी निर्भरता से ग्रस्त होता है। Dependency Injection (DI) का कार्यान्वयन — मॉड्यूलरिटी की ओर पहला कदम है।

व्यावहारिक उदाहरण

कल्पना करें कि आपके पास एक क्लास ReportGenerator है जो आंतरिक रूप से SqlConnection बनाती है:

public class ReportGenerator\n{\n    public void Generate()\n    {\n        using (var conn = new SqlConnection("..."))\n        {\n            // क्वेरीज़\n        }\n    }\n}

वास्तविक डेटाबेस के बिना इसका परीक्षण करना असंभव है। रीफैक्टरिंग:

public interface IDataRepository\n{\n    IEnumerable<DataRow> GetReportData();\n}\n\npublic class ReportGenerator\n{\n    private readonly IDataRepository _repository;\n\n    public ReportGenerator(IDataRepository repository)\n    {\n        _repository = repository;\n    }\n\n    public void Generate()\n    {\n        var data = _repository.GetReportData();\n        // रिपोर्ट तैयार करना\n    }\n}

अब आप यूनिट टेस्ट में रिपॉजिटरी को मॉक से बदल सकते हैं। निर्भरता इंजेक्ट करने के लिए मानक .NET Core DI कंटेनर (Microsoft.Extensions.DependencyInjection) या Autofac का उपयोग करें।

3. लेगसी कोड का परीक्षण: Golden Master और Characterization Tests

परीक्षणों के बिना रीफैक्टरिंग बिना पैराशूट के कूदने जैसा है। लेगसी कोड के लिए Characterization Tests (विशेषता परीक्षण) या Golden Master Testing दृष्टिकोण आदर्श है।

यह कैसे काम करता है

आप