स्पेगेटी कोड क्या है

स्पेगेटी कोड — एक रूपक है जो ऐसे कोड का वर्णन करता है जिसकी संरचना स्पेगेटी की प्लेट जैसी होती है: अलग-अलग धागे (तार्किक ब्लॉक) आपस में उलझे, चिपके और एक-दूसरे से अविभाज्य होते हैं। ऐसे कोड में परतों, मॉड्यूल या घटकों को अलग करना असंभव है — सब कुछ एक बड़े द्रव्यमान में मिश्रित होता है।

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

IEEE (2022) के अनुसार, बड़ी परियोजनाओं में लगभग 35% त्रुटियां उलझी हुई कोड संरचना के कारण होती हैं, न कि डेवलपर की तार्किक गलतियों के कारण। डेवलपर गलती इसलिए नहीं करता क्योंकि उसने कार्य को गलत समझा, बल्कि इसलिए कि वह स्पेगेटी कोड में निष्पादन प्रवाह का पता नहीं लगा सका।

अन्य एंटी-पैटर्न से मुख्य अंतर

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

शब्द का इतिहास और goto युग

शब्द “स्पेगेटी कोड” 1970 के दशक में goto स्टेटमेंट की आलोचना के साथ दिखाई दिया। प्रारंभिक प्रोग्रामिंग भाषाओं (BASIC, FORTRAN, COBOL) में, goto निष्पादन प्रवाह को नियंत्रित करने का मुख्य तरीका था। एक प्रोग्राम क्रमांकित पंक्तियों का एक अनुक्रम था, और goto उनमें से किसी पर भी कूदने की अनुमति देता था। इसने कूद का एक “उलझन” बनाया जिसे सुलझाना असंभव था।

1968 में, एड्सगर डेक्सट्रा ने अपना प्रसिद्ध पत्र “Go To Statement Considered Harmful” प्रकाशित किया, जिसने संरचित प्रोग्रामिंग युग की शुरुआत को चिह्नित किया। डेक्सट्रा ने साबित किया कि किसी भी एल्गोरिदम को goto के बिना, केवल तीन निर्माणों का उपयोग करके लागू किया जा सकता है: अनुक्रम, शाखा (if) और लूप (while)। यह आधुनिक प्रोग्रामिंग की नींव बन गया।

संरचित प्रोग्रामिंग ने समस्या को पूरी तरह से समाप्त नहीं किया। स्पेगेटी कोड एक नए स्तर पर चला गया — भौतिक gotos के बजाय, डेवलपर्स ने तार्किक “goto” बनाना शुरू किया: वैश्विक चर, जावास्क्रिप्ट में कॉलबैक हेल, जटिल कॉल श्रृंखलाएं और घटकों के बीच अंतर्निहित निर्भरताएं। समस्या बनी रही, केवल रूप बदल गया।

goto के आधुनिक रूप

कॉलबैक हेल, गहराई से नेस्टेड Promises, त्रुटि प्रबंधन के बिना async/await, ऐसी घटनाएं जिन्हें कोई नहीं समझता कि कौन या कब ट्रिगर करता है — ये सभी स्पेगेटी कोड की आधुनिक किस्में हैं। एंटी-पैटर्न जीवित है और फल-फूल रहा है, बस अब यह goto स्टेटमेंट का उपयोग नहीं करता।

प्रोजेक्ट में स्पेगेटी कोड के संकेत

परतों की कमी — पहला और मुख्य संकेत। स्पेगेटी कोड में, व्यावसायिक तर्क, डेटाबेस संचालन, HTML मार्कअप और नेटवर्क संचार सभी एक फ़ाइल या एक विधि में मिश्रित होते हैं। डेटाबेस क्वेरी बदलने से UI प्रदर्शन टूट सकता है क्योंकि इन परतों का कोड अलग नहीं है।

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

गॉड क्लासेज़ और गॉड फंक्शन — तीसरा संकेत। 2000+ पंक्तियों वाला एक वर्ग जो व्यावसायिक तर्क, प्रदर्शन और डेटा संचालन संभालता है — यह विशिष्ट स्पेगेटी कोड है। एक फंक्शन जो 10 पैरामीटर लेता है और 5 अलग-अलग काम करता है — भी स्पेगेटी।

परीक्षणों के माध्यम से निदान

अगर आप 15 मॉक ऑब्जेक्ट बनाए बिना किसी फंक्शन के लिए यूनिट टेस्ट नहीं लिख सकते — यह स्पेगेटी कोड है। अगर एक मॉड्यूल के परीक्षण के लिए संपूर्ण एप्लिकेशन इंफ्रास्ट्रक्चर चालू करने की आवश्यकता है — यह स्पेगेटी कोड है। अयोग्यता उलझे हुए आर्किटेक्चर का एक वस्तुनिष्ठ संकेतक है।

नूडल कोड क्यों दिखाई देता है

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

क्रमिक विकास — दूसरा कारण। एक प्रोजेक्ट एक छोटी स्क्रिप्ट के रूप में शुरू होता है, फिर सुविधाओं के साथ बढ़ता है, फिर एक एप्लिकेशन बन जाता है, और फिर एक मोनोलिथ। इस बीच, आर्किटेक्चर पर पुनर्विचार नहीं किया जाता है। जो कोड की 100 पंक्तियों के लिए काम करता था, वह 100,000 पंक्तियों के लिए आपदा बन जाता है।

SOLID सिद्धांतों का उल्लंघन — तीसरा कारण। विशेष रूप से एकल जिम्मेदारी सिद्धांत (S) और निर्भरता उलटा सिद्धांत (D)। जब एक वर्ग हर चीज के लिए जिम्मेदार होता है, निर्भरताएं कठोर होती हैं, और मॉड्यूल कसकर जुड़े होते हैं — आपको स्पेगेटी कोड मिलता है।

समय कारक

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

स्पेगेटी कोड के परिणाम

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

टीम की उत्पादकता तेजी से गिरती है। Microsoft Research (2023) ने दिखाया कि स्पेगेटी कोड में नई सुविधा जोड़ने का समय कोडबेस आकार के सापेक्ष द्विघात रूप से बढ़ता है। साफ आर्किटेक्चर के लिए, यह वृद्धि रैखिक है। अंतर 50,000+ पंक्तियों के कोड पर महत्वपूर्ण हो जाता है।

सुरक्षा — एक और शिकार। स्पेगेटी कोड में, अनहैंडल्ड अपवाद, गलत इनपुट वैलिडेशन, या डेटा रिसाव को याद करना आसान है। उलझे हुए आर्किटेक्चर वाले प्रोजेक्ट में सुरक्षा ऑडिट व्यावहारिक रूप से असंभव है — उन सभी स्थानों को ढूंढना जहां उपयोगकर्ता इनपुट का उपयोग किया जाता है, अव्यावहारिक है।

टीम पर प्रभाव

टर्नओवर स्पेगेटी कोड वाली परियोजनाओं में औसत से अधिक है। अनुभवी डेवलपर्स चले जाते हैं क्योंकि वे “नूडल्स” के साथ काम नहीं करना चाहते। नए कर्मचारी कोड को समझ नहीं पाते और पहले महीनों में चले जाते हैं। प्रोजेक्ट विशेषज्ञता खो देता है, जो कोड गुणवत्ता को और खराब करता है — एक दुष्चक्र।

स्पेगेटी कोड को कैसे रीफैक्टर करें

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

दूसरा — डिपेंडेंसी इंजेक्शन लागू करें। कंस्ट्रक्टर या पैरामीटर के माध्यम से निर्भरताओं के प्रत्यक्ष निर्माण को बदलें। यह घटकों के बीच कठोर कनेक्शन को तोड़ता है और प्रत्येक मॉड्यूल को अलग-थलग परीक्षण करने की अनुमति देता है।

तीसरा — गॉड क्लासेज़ और गॉड फंक्शन निकालें। उन्हें एकल जिम्मेदारी वाले छोटे वर्गों और विधियों में तोड़ें। जटिल उप-प्रणालियों को सरल बनाने के लिए Facade पैटर्न का उपयोग करें। याद रखें: 20 पंक्तियों का वर्ग 2000 पंक्तियों के वर्ग से अधिक स्पष्ट है।

// स्पेगेटी — सब कुछ एक विधि में
function handleRequest(req, res) {
  const db = new Database("mysql://...");
  const user = db.query("SELECT * FROM users WHERE id =" + req.params.id);
  let html = "";
  html += "
" + user.name + "
";
  html += "
Balance: " + user.balance + "
";
  html += "";
  res.send(html);
}

// स्वच्छ आर्किटेक्चर — अलग परतें
class UserController {
  constructor(userService) {
    this.userService = userService;
  }

  async getUser(req, res) {
    const user = await this.userService.findById(req.params.id);
    res.json(new UserResponse(user));
  }
}

class UserService {
  constructor(userRepository) {
    this.userRepository = userRepository;
  }

  async findById(id) {
    return await this.userRepository.findById(id);
  }
}

रीफैक्टरिंग रणनीति: शल्य चिकित्सा विधि

नहीं एक बार में पूरे कोडबेस को फिर से लिखने का प्रयास करें — यह गारंटीकृत विफलता है। एक मॉड्यूल चुनें, वर्तमान व्यवहार को कैप्चर करने वाले लक्षण वर्णन परीक्षण (characterization tests) लिखें, और उसके बाद ही रीफैक्टर करें। धीरे-धीरे, मॉड्यूल दर मॉड्यूल, आप स्पेगेटी को सुलझा लेंगे।

नूडल कोड की रोकथाम

आर्किटेक्चरल योजना — रोकथाम की नींव। विकास शुरू करने से पहले, एक आर्किटेक्चरल शैली स्वीकृत करें: MVC, MVVM, Clean Architecture, VIPER या कोई अन्य। चुनाव को सही ठहराते हुए एक ADR (Architecture Decision Record) लिखें। कोड समीक्षा पर आर्किटेक्चर अनुपालन की मांग करें।

निर्भरता उलटा सिद्धांत (DIP) — स्पेगेटी कोड के खिलाफ एक शक्तिशाली उपकरण। उच्च-स्तरीय मॉड्यूल को निम्न-स्तरीय मॉड्यूल पर निर्भर नहीं होना चाहिए। दोनों को अमूर्तताओं पर निर्भर होना चाहिए। डिपेंडेंसी इंजेक्शन इस सिद्धांत का व्यावहारिक कार्यान्वयन है।

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

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

स्पेगेटी कोड से लड़ने के उपकरण

SonarQube — चक्रीय जटिलता, विरासत गहराई, विधि आकार को ट्रैक करता है। JDepend (Java) — पैकेजों के बीच निर्भरताएं मापता है। PhpMetrics — PHP परियोजनाओं के लिए रखरखाव सूचकांक प्रदान करता है। CI/CD में मेट्रिक्स की निगरानी करें — नूडल्स को दिखने से रोकें न कि बाद में उनसे लड़ें।