प्रोग्रामिंग में फ्रैंकेंस्टीन — यह क्या है, कारण और रोकथाम

प्रोग्रामिंग में फ्रैंकेंस्टीन क्या है

फ्रैंकेंस्टीन (फ्रैंकेंस्टीन कोड, फ्रैंकेंस्टीन पैटर्न) एक एंटीपैटर्न है जिसमें सॉफ्टवेयर सिस्टम को उन भागों से इकट्ठा किया जाता है जो एक साथ काम करने के लिए डिज़ाइन नहीं किए गए हैं। फ्रैंकेंस्टीन के राक्षस की तरह, ऐसा कोड काम कर सकता है, लेकिन यह बदसूरत, अप्रत्याशित और मामूली बदलावों पर खतरनाक होता है।

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

फ्रैंकेंस्टीन और स्पेगेटी कोड के बीच अंतर पैमाने और प्रकृति में है। स्पेगेटी कोड एक तकनीकी स्टैक के भीतर उलझी हुई संरचना है। फ्रैंकेंस्टीन आर्किटेक्चर स्तर पर एकलेक्टिसिज्म है: एक ही सिस्टम के भीतर विभिन्न तकनीकें, असंगत प्रतिमान, संघर्षशील दृष्टिकोण।

फ्रैंकेंस्टीन बनाम माइक्रोसर्विसेज

माइक्रोसर्विस आर्किटेक्चर विभिन्न सेवाओं के लिए विभिन्न तकनीकों के उपयोग की अनुमति देता है, लेकिन स्पष्ट सीमाओं और मानकीकृत इंटरैक्शन प्रोटोकॉल की शर्त पर। फ्रैंकेंस्टीन बिना सीमाओं का अराजक मिश्रण है: एक ही कंट्रोलर में REST और GraphQL, एक ही मॉड्यूल में दो ORM, एक ही एंटिटी के लिए SQL और NoSQL।

फ्रैंकेंस्टीन सिंड्रोम क्यों उत्पन्न होता है

तकनीकी नेता या आर्किटेक्ट की अनुपस्थिति मूल कारण है। जब प्रोजेक्ट में आर्किटेक्चर की अखंडता के लिए जिम्मेदार कोई व्यक्ति नहीं होता, प्रत्येक डेवलपर “अपने लिए” उपकरण चुनता है। एक को Spring पसंद है, दूसरे को Guice, तीसरा कस्टम DI का उपयोग करता है। परिणाम — आर्किटेक्चरल मिश्रण।

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

कॉर्पोरेट अधिग्रहण तीसरा परिदृश्य है। कंपनी A ने कंपनी B को खरीदा और उसके उत्पाद को अपने में एकीकृत करना चाहती है। पुनर्लेखन के बजाय — API, साझा डेटाबेस और पैच के माध्यम से चिपकाना। एक साल बाद, सिस्टम एक राक्षस बन जाता है जिसे कोई नहीं समझता।

“रचनात्मकता” का कारक

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

वास्तविक प्रोजेक्ट्स में फ्रैंकेंस्टीन के उदाहरण

एक क्लासिक उदाहरण एक एप्लिकेशन में कई ORM का उपयोग है। कुछ मॉड्यूल Hibernate का उपयोग करते हैं, कुछ MyBatis, और कुछ सीधे JDBC क्वेरी। लेन-देन बेकाबू हो जाते हैं, कैश असंगत हो जाता है, और नया डेवलपर नहीं जानता कि नई सुविधा के लिए कौन सा दृष्टिकोण चुनना है।

दूसरा उदाहरण आर्किटेक्चरल शैलियों का मिश्रण है। REST API कंट्रोलर में, आपको SOAP सेवा कॉल, सीधे SQL क्वेरी, फाइल सिस्टम एक्सेस और HTML जनरेशन मिलता है। ऐसे एप्लिकेशन का परीक्षण, विस्तार या दस्तावेजीकरण असंभव है।

तीसरा उदाहरण एक तकनीकी स्टैक है जहाँ Python का उपयोग बैकएंड के लिए, Node.js माइक्रोसर्विस के लिए, C# डेस्कटॉप क्लाइंट के लिए, और Java Android ऐप के लिए किया जाता है, जबकि सभी व्यावसायिक तर्क उनके बीच जिम्मेदारियों के स्पष्ट विभाजन के बिना फैले हुए हैं।

// फ्रैंकेंस्टीन — मिश्रित शैलियाँ और तकनीकें
// callbacks, Promises, और async/await संयुक्त

// callbacks
db.query("SELECT * FROM users", function(err, rows) {
  if (err) handleError(err);
  // callback के अंदर Promise
  fetch("/api/data").then(function(data) {
    // then के अंदर async/await
    (async () => {
      const result = await processData(data);
      sendResponse(result);
    })();
  });
});

// स्वच्छ कोड — एकीकृत async/await शैली
async function getUserData(userId) {
  const user = await db.query("SELECT * FROM users WHERE id = ?", [userId]);
  const data = await fetch("/api/data/" + userId);
  return await processData(user, data);
}

डेटा स्तर पर फ्रैंकेंस्टीन

एक डेटाबेस एक साथ SQL रिलेशनल (सामान्यीकरण के साथ) और NoSQL दस्तावेज़-उन्मुख (JSON कॉलम के साथ) के रूप में उपयोग किया जाता है। कुछ क्वेरी ORM के माध्यम से जाती हैं, कुछ संग्रहीत प्रक्रियाओं के माध्यम से, कुछ कोड से सीधे SQL के माध्यम से। DB स्कीमा दस्तावेजीकृत नहीं है, माइग्रेशन संघर्ष करते हैं।

फ्रैंकेंस्टीन कोड के परिणाम

ऑनबोर्डिंग जटिलता पहला परिणाम है। एक नए डेवलपर को सिस्टम को समझने के लिए 5 भाषाएँ, 3 फ्रेमवर्क, 2 आर्किटेक्चरल शैलियाँ जाननी चाहिए। ऑनबोर्डिंग हफ्तों से महीनों तक खिंचती है। LinkedIn (2023) के अनुसार, तकनीकी एकलेक्टिसिज्म वाले प्रोजेक्ट नए कर्मचारियों को 2 गुना अधिक खोते हैं।

व्यवहार की अप्रत्याशितता दूसरा परिणाम है। Python माइक्रोसर्विस में बदलाव अप्रत्याशित रूप से Java मॉड्यूल को तोड़ सकता है क्योंकि वे स्पष्ट अनुबंधों के बिना एक डेटाबेस साझा करते हैं। ऐसी समस्याओं की डिबगिंग के लिए स्टैक में सभी तकनीकों का एक साथ ज्ञान आवश्यक है।

सुरक्षा तीसरा परिणाम है। स्टैक में प्रत्येक तकनीक को अपने स्वयं के सुरक्षा कॉन्फ़िगरेशन, अपने स्वयं के पैच, अपनी स्वयं की निगरानी की आवश्यकता होती है। 5-6 विषम तकनीकों के लिए स्वीकार्य स्तर पर सुरक्षा बनाए रखना व्यावहारिक रूप से असंभव है। उनमें से एक अनिवार्य रूप से कमजोर होगी।

फ्रैंकेंस्टीन का तकनीकी ऋण

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

राक्षस बनाने से कैसे बचें

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

दूसरा — Architecture Decision Record (ADR) प्रक्रिया लागू करना। कोई भी महत्वपूर्ण आर्किटेक्चरल निर्णय (DB, फ्रेमवर्क, प्रोटोकॉल का चयन) एक छोटे टेक्स्ट के रूप में दस्तावेजीकृत किया जाता है: संदर्भ, मानी गई विकल्प, लिया गया निर्णय, परिणाम। ADR रिपॉजिटरी में संग्रहीत होते हैं और पूरी टीम के लिए उपलब्ध होते हैं।

तीसरा — “एक कार्य — एक उपकरण” का सिद्धांत स्थापित करना। HTTP अनुरोधों के लिए — एक क्लाइंट। ORM के लिए — एक लाइब्रेरी। लॉगिंग के लिए — एक फ्रेमवर्क। अपवाद केवल ADR के माध्यम से औचित्य के साथ अनुमत हैं। यदि प्रोजेक्ट में पहले से Axios है — fetch न जोड़ें, यदि SLF4J है — System.out के माध्यम से न लिखें।

• आर्किटेक्ट नई तकनीकों पर वीटो अधिकार के साथ
• Architecture Decision Records प्रत्येक महत्वपूर्ण विकल्प के लिए
• एकीकृत स्टैक प्रत्येक कार्य के लिए — एक HTTP क्लाइंट, एक ORM
• RFC पूरी टीम की चर्चा के साथ बड़े बदलावों के लिए
• तकनीकी रडार यह ट्रैक करने के लिए कि क्या अपनाया जा सकता है

प्रायोगिक तकनीक नीति

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

मौजूदा फ्रैंकेंस्टीन को कैसे रिफैक्टर करें

इन्वेंटरी — पहला कदम। तकनीकी स्टैक का पूरा नक्शा बनाएँ: कौन से फ्रेमवर्क, लाइब्रेरी, भाषाएँ, प्रोटोकॉल उपयोग किए जाते हैं, किन मॉड्यूल में और किन कार्यों के लिए। आप समस्या का पैमाना देखेंगे: उपकरण दोहराव, संघर्षशील तकनीकें, अप्रयुक्त निर्भरताएँ।

मानकीकरण — दूसरा कदम। प्रत्येक कार्य के लिए एक उपकरण चुनें। उदाहरण के लिए: ORM के लिए केवल Hibernate, लॉगिंग के लिए केवल SLF4J + Logback, API के लिए केवल REST। ADR में मानक का दस्तावेजीकरण करें। उन मॉड्यूल से बदलना शुरू करें जहाँ एकलेक्टिसिज्म सबसे अधिक समस्याएँ पैदा करता है।

Parallel Run रणनीति — तीसरा कदम। पुराने और नए उपकरण समानांतर में काम करते हैं जब तक नया अपनी विश्वसनीयता साबित नहीं करता। उदाहरण के लिए, पुराना HTTP क्लाइंट और नया एक साथ काम करते हैं, लेकिन नया केवल अनुरोधों के एक हिस्से को संभालता है। स्थिरीकरण अवधि के बाद, पुराना हटा दिया जाता है।

// फ्रैंकेंस्टीन — एक प्रोजेक्ट में तीन HTTP दृष्टिकोण
// मॉड्यूल A: OkHttp
OkHttpClient client = new OkHttpClient().newCall(request);

// मॉड्यूल B: RestTemplate (Spring)
restTemplate.getForObject(url, String.class);

// मॉड्यूल C: java.net.HttpURLConnection
HttpURLConnection conn = (HttpURLConnection) new URL(url).openConnection();

// एकीकृत दृष्टिकोण: सिंक के लिए RestTemplate, रिएक्टिव के लिए WebClient
@Autowired
private RestTemplate restTemplate;

public String callApi(String url) {
    return restTemplate.getForObject(url, String.class);
}

रोकथाम में तकनीकी नेता की भूमिका

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

RFC (Request for Comments) एक प्रक्रिया है जो ओपन सोर्स समुदायों से उधार ली गई है। किसी भी महत्वपूर्ण तकनीक को शुरू करने से पहले, लेखक RFC लिखता है: समस्या, प्रस्तावित समाधान, विकल्प, कार्यान्वयन योजना। टीम चर्चा करती है, वोट करती है, स्वीकार या अस्वीकार करती है। RFC पारदर्शिता बनाता है और “मूक” आर्किटेक्चरल निर्णयों को रोकता है।

तकनीकी रडार (ThoughtWorks Technology Radar) वर्गीकरण उपकरण है: Adopt, Trial, Assess, Hold। टीम नियमित रूप से रडार की समीक्षा करती है और स्थितियों को अपडेट करती है। यह “ट्रेंडी” को “उपयोगी” से अलग करने और महत्वपूर्ण कोड में अप्रमाणित तकनीकों को शुरू करने से बचने में मदद करता है।

संगति का सिद्धांत

आर्किटेक्चर का सबसे महत्वपूर्ण गुण संगति (consistency) है। पूरे प्रोजेक्ट में उपयोग किया जाने वाला एक बहुत अच्छा उपकरण भी नहीं, केवल एक मॉड्यूल में उपयोग किए जाने वाले सबसे अच्छे उपकरण से बेहतर है। संगति संज्ञानात्मक भार को कम करती है, ऑनबोर्डिंग को सरल बनाती है और कोड को पूर्वानुमेय बनाती है।