स्पेगेटी कोड के बारे में स्पेगेटी लेख

माइकल ओ। चर्च अनुच्छेद अनुवाद - स्पेगेटी कोड क्या है?

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

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

गोटो ऑपरेटर को पढ़ना मुश्किल हो जाता है, क्योंकि यदि प्रोग्राम का नियंत्रण एक स्थान से दूसरे स्थान पर जा सकता है, तो यह निश्चित रूप से कहना असंभव है कि कोड के एक विशिष्ट अनुभाग को निष्पादित करते समय प्रोग्राम क्या स्थिति है। गोटो-आधारित कार्यक्रमों को आसानी से घटक भागों में नहीं तोड़ा जा सकता है, क्योंकि कोड का कोई भी बिंदु कोड के किसी अन्य भाग के लिए एक वर्महोल हो सकता है। नतीजतन, ऐसा कोड "सब कुछ हर जगह है," में बदल जाता है और कोड के एक अलग हिस्से को समझने के लिए, आपको इस सभी भ्रम को समझने की आवश्यकता है, और बाद में बड़े कार्यक्रमों के लिए यह असंभव हो जाता है। इसकी तुलना आसानी से स्पेगेटी के एक कटोरे से की जा सकती है, जहां एक पास्ता को निकालने पर पास्ता की एक बड़ी गेंद के माध्यम से नेविगेट करना भी शामिल है। आप केवल प्लेट को नहीं देख सकते हैं और समझ सकते हैं कि कौन सा पास्ता किस उलझन में है, इसके बजाय आपको पूरी उलझन को उजागर करना होगा।

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

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

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

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

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

तुलना सॉफ्टवेयर के साथ सबसे बड़ी समस्याओं में से एक (चाहे वह दृष्टिकोणों, तकनीकों, भाषाओं या प्लेटफार्मों की तुलना हो) यह है कि अधिकांश तुलनाएं सरल उदाहरणों पर ध्यान केंद्रित करती हैं। कोड की बीस पंक्तियों पर कुछ भी भयावह प्रकट करना संभव नहीं है, जब तक कि इन पंक्तियों को जानबूझकर मतलबी इरादे से नहीं लिखा जाता है। गोटो का उपयोग करके लिखा गया एक बीस-लाइन प्रोग्राम आम तौर पर स्वीकार्य है, और बिना उपयोग किए लिखे जाने की तुलना में सरल भी हो सकता है। बीस लाइनों पर, कुछ स्पष्ट नियंत्रण हस्तांतरण के साथ चरण-दर-चरण निर्देशों का एक सेट एक कार्यक्रम का प्रतिनिधित्व करने का एक बहुत ही स्वाभाविक तरीका है। स्थिर कार्यक्रमों के लिए (उदाहरण के लिए, एक प्लैटोनिक रूप जिसे कभी नहीं बदला जाएगा और रखरखाव प्राप्त होगा) जिसे एक बैठे में पढ़ा जा सकता है, यह संरचना बस ठीक हो सकती है। लेकिन पहले से ही गोटो के साथ कार्यक्रम की बीस हजार लाइनें समझ से बाहर हो जाती हैं। बीस हजार लाइनों पर, गोटो कार्यक्रम खुद को इतने सारे हैक, एक्सटेंशन और अनुकूलन के लिए उधार देते हैं कि चीजों के निर्माण की प्रारंभिक दृष्टि बस खो जाती है। और तथ्य यह है कि कार्यक्रम "कहीं से भी" कोड के किसी भी भाग में दिखाई दे सकता है इसका मतलब है कि कोड को सुरक्षित रूप से बदलने के लिए इन "कहीं से भी" की विश्वसनीय जानकारी की आवश्यकता है। सब जगह सब कुछ है। इससे न केवल कोड को समझना मुश्किल हो जाता है, बल्कि इसका अर्थ यह भी है कि अप्रत्याशित परिणामों के कारण कोड के हर संशोधन के खराब होने की संभावना है। समय के साथ, सॉफ्टवेयर "जैविक" हो जाता है। इस शब्द से मेरा मतलब है कि यह एक व्यवहार मॉडल विकसित करता है जिसमें सभी घटक स्वतंत्र होते हैं, लेकिन कुछ मॉड्यूल में एक छिपा हुआ कनेक्शन हो सकता है।

गोटो ऑपरेटर एक प्रोग्रामिंग भाषा के निर्माण के रूप में नहीं हुआ, क्योंकि इसके उपयोग के साथ लिखे गए प्रोग्राम के निरंतर निदान के साथ बहुत सारी समस्याएं जुड़ी थीं। कम शक्तिशाली, लेकिन अधिक संकीर्ण रूप से विशिष्ट, प्रक्रियाओं, कार्यों और अच्छी तरह से परिभाषित डेटा संरचनाओं जैसी संरचनाओं को अधिक एहसान मिला। एकमात्र मामले के लिए जहां लोगों को वैश्विक प्रवाह नियंत्रण (त्रुटि से निपटने) की आवश्यकता थी, अपवाद विकसित किए गए थे। यह चरम सार्वभौमिकता और विशिष्ट समस्याओं को हल करने के लिए भागों (जैसे प्रक्रियाओं) की संक्षिप्तता और विशिष्टता के लिए गोटो का उपयोग करके लिखे गए कार्यक्रमों के अमूर्तता से एक संक्रमण था। गैर-संरचनात्मक प्रोग्रामिंग में, आप एक महान कार्यक्रम लिख सकते हैं जो बहुत सारी चीजें करता है: यह हर स्वाद के लिए नई सुविधाएँ जोड़ता है और चीजों के पाठ्यक्रम को बदलता है जैसे आपको आवश्यकता होती है। यह किसी प्रकार की "समस्या" को हल नहीं करना चाहिए (यह बहुत उबाऊ है ...), लेकिन यह एक अंतर्निहित रूपरेखा के साथ एक मेटा-फ्रेमवर्क हो सकता है। संरचनात्मक प्रोग्रामिंग लोगों को एक समस्या से निपटने के लिए विशिष्ट कार्यक्रमों में अपने कार्यक्रमों को तोड़ने के लिए प्रोत्साहित करती है, और यदि संभव हो तो, इन भागों को पुन: प्रयोज्य बनाएं। यह सिद्धांत यूनिक्स सिस्टम (एक काम करो और इसे अच्छी तरह से करो) और कार्यात्मक प्रोग्रामिंग के दर्शन का आधार बन गया है (वैश्विक राज्यों से बचने के लिए सटीक गणितीय शब्दार्थ को परिभाषित करना आसान है)।

एक और बात जो मैं गोटो ऑपरेटर के बारे में कहना चाहता हूं, वह यह है कि भाषा-स्तर के आदिम के रूप में इसकी शायद ही कभी जरूरत होती है। आप लूप का उपयोग करके समान प्रभाव प्राप्त कर सकते हैं - लूप के बाहर घोषित एक काउंटर चर और स्विच-केस निर्माण द्वारा उपयोग किया जाता है, या तो वृद्धि (चरण), लूप जारी रखें, या शून्य ( गोटो )। यदि आप चाहें, तो इसे एक विशाल कार्यक्रम में विस्तारित किया जा सकता है जो इस तरह के एक चक्र के रूप में काम करेगा, लेकिन ऐसा कोड कभी नहीं लिखा जाता है। तथ्य यह है कि यह लगभग कभी नहीं किया गया है इस तथ्य को इंगित करता है कि गोटो का उपयोग करना शायद ही कभी आवश्यक होता है। इस प्रकार, संरचनात्मक प्रोग्रामिंग पागलपन को इंगित करता है, जिसमें से कुछ तब गिरते हैं जब जोरदार गैर-स्थानीय प्रवाह को नियंत्रित करने की कोशिश करते हैं।

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

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

इसका उत्तर यह है कि शक्ति का होना हमेशा अच्छा नहीं होता है। प्रोग्रामिंग पावर उस व्यक्ति के लिए एक फायदा है जो कोड लिखता है, न कि उस व्यक्ति के लिए जो इसे बाद में पढ़ता है, और रखरखाव (उदाहरण के लिए, कोड को समझने की आवश्यकता) लगभग 2,000 लाइनों या छह सप्ताह के साथ शुरू होता है, और परियोजना पर एक से अधिक डेवलपर उद्देश्य से। वास्तविक परियोजनाओं पर, कोई भी केवल कोड नहीं लिखेगा। अक्सर हमें अपना कोड और अन्य लोगों का कोड दोनों पढ़ना पड़ता है। एक अपठनीय कोड केवल अस्वीकार्य है, और केवल इसकी अनुमति है क्योंकि इसमें बहुत सारे हैं, और इसलिए भी कि कई सॉफ्टवेयर कंपनियों द्वारा अपनाई गई OOP की "सर्वोत्तम प्रथाओं", इसे जन्म देती हैं। एक अधिक "शक्तिशाली" अमूर्तता अधिक सामान्य है और इसलिए कम विशिष्ट है, जिसका अर्थ है कि जो लोग इस तरह के कोड को पढ़ते हैं, उन्हें यह निर्धारित करना मुश्किल है कि यह किसके लिए उपयोग किया जाता है। लेकिन अकेले कोड लिखने वाले लोग अक्सर काफी सीधे होते हैं - एक शक्तिशाली अमूर्त में 18 संभावित उपयोग हो सकते हैं , लेकिन उनमें से केवल एक ही वास्तव में शामिल है। इस मामले में, एक अजीब व्यक्तिगत दृष्टि है (हालांकि आमतौर पर दस्तावेज नहीं है), जो भ्रम से बचने में मदद करता है। खतरे तब पैदा होते हैं जब कोई व्यक्ति जो इस दृष्टि से शुरू नहीं किया जाता है वह कोड को संशोधित करना शुरू कर देता है। अक्सर, ये संशोधन हैक होते हैं जो स्पष्ट रूप से स्पष्ट नहीं होते हैं कि शेष 17 में से एक का उपयोग होता है। यह, एक नियम के रूप में, विरोधाभासों की ओर जाता है, और वे, बदले में, त्रुटियों के लिए। दुर्भाग्य से, इन बग्स को ठीक करने के लिए जिम्मेदार लोगों को कोड के पीछे छिपी प्रारंभिक दृष्टि का भी कम पता है, और उनके संशोधनों में और भी अधिक हैक शामिल हैं। कुछ स्थानों पर सुधार हो सकते हैं, लेकिन कोड की समग्र गुणवत्ता कम हो जाती है। यह कोड की "स्पैगेटिफिकेशन" की प्रक्रिया है। कोई भी बस नहीं बैठता है और अपने लिए स्पेगेटी कोड लिखना शुरू कर देता है। यह प्रक्रिया को धीरे-धीरे "स्ट्रेचिंग" करके होता है और लगभग हमेशा कई डेवलपर्स जिम्मेदार होते हैं। सॉफ्टवेयर में, "खड़ी ढलान" वास्तव में वास्तविक हैं और गिरावट बहुत अचानक हो सकती है।

ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग, जिसे मूल रूप से स्पेगेटी कोड को रोकने के लिए डिज़ाइन किया गया है, अपने सबसे खराब स्रोतों में से एक (पूर्ण समझ के बिना "डिज़ाइन पैटर्न" के उपयोग के कारण) बन गया है। एक "ऑब्जेक्ट" आसानी से कोड और डेटा को संयोजित कर सकता है, जबकि किसी भी संख्या में इंटरफेस होने पर, एक ही समय में एक वर्ग स्वतंत्र रूप से पूरे कार्यक्रम में उपवर्ग उत्पन्न कर सकता है। ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग महान शक्ति से भरा हुआ है, और अनुशासित उपयोग के साथ, यह बहुत प्रभावी हो सकता है। लेकिन अधिकांश प्रोग्रामर इसे संभाल नहीं सकते हैं, और समय के साथ, उनका कोड स्पेगेटी में बदल जाता है।

स्पेगेटी कोड के साथ समस्याओं में से एक यह है कि यह धीरे-धीरे बनता है, जिससे कोड सत्यापन प्रक्रिया के दौरान इसे पहचानना मुश्किल हो जाता है, क्योंकि "स्पेगेटी" की ओर जाने वाला हर बदलाव तस्वीर के बाहर विशुद्ध रूप से सकारात्मक दिख सकता है। प्लस यह है कि प्रबंधक या क्लाइंट को "बस कल" की आवश्यकता वाले परिवर्तन कोड में दिखाई देते हैं, और दूसरी तरफ, यह सब कुछ अतिरिक्त कठिनाइयों की एक मध्यम राशि की तरह दिखता है। गोटो के अंधेरे युग में भी , कोई भी नहीं बैठ पाया और कहा: "मैं एक कोड में एक बिंदु की ओर इशारा करते हुए 40 गोटो बयानों के साथ एक पूरी तरह से समझ में नहीं आने वाला कार्यक्रम लिखने जा रहा हूं।" धीरे-धीरे गड़बड़ हो गया, जबकि कार्यक्रम का विकास एक व्यक्ति से दूसरे व्यक्ति में पारित हो गया। वस्तु-उन्मुख स्पेगेटी के लिए भी यही सच है। एक साफ प्रारंभिक डिजाइन से एक अतुलनीय स्पेगेटी कोड में कोई विशिष्ट संक्रमण बिंदु नहीं है। यह समय के साथ होता है, जब लोग अस्पष्ट हैक को धकेलने के लिए ओओपी की शक्ति का दुरुपयोग करते हैं, जो आवश्यक नहीं होगा अगर हर कोई यह समझे कि कैसे प्रोग्राम जो वे काम को संशोधित करते हैं, और यदि अधिक स्पष्ट (यद्यपि कम शक्तिशाली) सार का उपयोग किया जाता है । इसका मतलब यह है कि "स्पैगेटाइजेशन" का दोष सभी के साथ है और एक ही समय में नहीं है: कोई भी व्यक्तिगत डेवलपर विश्वास के साथ कह सकेगा कि यह उसका परिवर्तन नहीं था जिसने कोड को सीधे नरक में भेज दिया था। यही कारण है कि बड़े सॉफ़्टवेयर निर्माता (यूनिक्स प्रणालियों के न्यूनतम दर्शन के विपरीत) निम्नलिखित नीति का पालन करते हैं: कोई नहीं जानता कि वास्तव में किसी चीज़ के लिए किसे दोषी ठहराया जाए।

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

जवाब, यह मुझे लगता है, यह है कि बिग कोड सिर्फ काम नहीं करता है। बड़े कार्यक्रमों में डायनामिक टाइपिंग क्रैश, और स्टैटिक टाइपिंग दूसरे तरीके से क्रैश होती है। यह सब ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग, अनिवार्य प्रोग्रामिंग और कुछ हद तक अभी भी कार्यात्मक प्रोग्रामिंग के लिए ध्यान देने योग्य डिग्री (थ्रेड में रखे गए मापदंडों में वृद्धि में प्रकट) के लिए सच है। " गोटो के साथ समस्याएं"नहीं था, क्योंकि इसकी प्रकृति ने कोड को बहुत जल्दी बिग कोड बनने दिया। लेकिन क्रूर वास्तविकता यह है कि बिग कोड "चांदी की गोली" नहीं है। बड़े कार्यक्रम बस समझ से बाहर हो जाते हैं। जटिलता और बड़े आकार "कभी-कभी वांछनीय नहीं" होते हैं, इसके विपरीत - वे हमेशा खतरनाक होते हैं। स्टीव येग जैसे लोगों ने लंबे समय से इसे समझा है ।

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

विडंबना यह है कि ओओपी का उद्देश्य मूल रूप से न्यूनतम सॉफ्टवेयर विकास के समान कुछ को प्रोत्साहित करना था। ओओपी की प्रारंभिक दृष्टि का मतलब यह नहीं था कि लोगों को बैठना चाहिए और विशाल, जटिल वस्तुओं को लिखना चाहिए, लेकिन इसका मतलब यह था कि उन्हें विशेष रूप से ओईआर होना चाहिएजब जटिलता अपरिहार्य है। इस क्षेत्र में सफल उपयोग का एक उदाहरण डेटाबेस हैं। लेन-देन की अखंडता, स्थायित्व, उपलब्धता, संक्षिप्तता और प्रदर्शन के संदर्भ में लोगों को संबंधपरक डेटाबेस की आवश्यकता होती है, इसलिए जटिलता एक आवश्यक है। डेटाबेस अविश्वसनीय रूप से जटिल हैं, और मैं विश्वास के साथ कह सकता हूं कि कंप्यूटर की दुनिया ने अपने योग्य कार्यान्वयन को प्राप्त करने में दशकों लग गए, इसके बावजूद इसे तेजी से बनाने के लिए वित्तीय प्रोत्साहन। लेकिन एक ही समय में, जब डेटाबेस जटिल हो सकता है (यदि आवश्यक हो), इसके उपयोग के लिए इंटरफ़ेस बहुत सरल (SQL) है। आप यह नहीं दर्शाते हैं कि डेटाबेस को किस खोज रणनीति का उपयोग करना चाहिए, आप बस SELECT लिखिए (वर्णन करें कि उपयोगकर्ता क्या प्राप्त करना चाहता है,)लेकिन यह नहीं है कि इसे कैसे प्राप्त करें) और क्वेरी ऑप्टिमाइज़र को इस बात का ध्यान रखने दें।

मैं ध्यान देता हूं कि बिग कोड के प्रति मेरी नापसंदगी में डेटाबेस एक तरह का अपवाद है। उनकी जटिलता एक अच्छी तरह से समझी गई आवश्यकता है, और ऐसे लोग हैं जो अपने करियर को विशेष रूप से अपने अध्ययन के लिए समर्पित करने के लिए तैयार हैं। लेकिन लोगों को विशिष्ट व्यावसायिक अनुप्रयोगों को समझने के लिए अपने करियर का आदान-प्रदान नहीं करना चाहिए। और वे नहीं करेंगे। वे इसे मना कर देंगे, और कोड को दूसरे हाथों में स्थानांतरित कर देंगे, जिससे इसके स्पैगेटाइजेशन में तेजी आएगी।

बड़ा कोड क्यों? इसके नुकसान के बावजूद इसका अस्तित्व क्यों है? और प्रोग्रामर ओओपी टूल्स का उपयोग शुरू करने के लिए इतनी जल्दबाजी क्यों कर रहे हैं, यह पूछे बिना कि क्या वास्तव में उनकी शक्ति और जटिलता की आवश्यकता है? मुझे लगता है कि इसके कई कारण हैं। उनमें से एक आलस्य है: लोग एक बड़े सामान्य-उद्देश्य अमूर्तता का अध्ययन करना पसंद करेंगे, बजाय इसके कि अत्यधिक विशिष्ट सार और स्थितियों में महारत हासिल करने में समय व्यतीत किया जाए जिसमें उन्हें लागू करने की आवश्यकता होती है। अगर हम पहले से ही एक ArrayList है तो कोई भी जुड़े हुए सूचियों और सरणियों या पेड़ों की तरह इन सभी अस्पष्ट संरचनाओं का अध्ययन क्यों करेगा? क्यों पता है कि एक प्रोग्राम लिंक-पारदर्शी कार्यों का उपयोग कैसे करता है यदि ऑब्जेक्ट एक ही काम कर सकते हैं (और इससे भी अधिक)? कमांड लाइन का उपयोग करना क्यों सीखें,अगर आधुनिक आईडीई आपको अपने जीवन में कम से कम एक बार इस लानत चीज को देखने में सक्षम होने से बचा सकता है? यदि जावा पहले से ही ट्यूरिंग पूर्ण है तो नई प्रोग्रामिंग भाषाएँ क्यों सीखें? बड़े कोड निम्न स्थिति के प्रसार से उत्पन्न होते हैं: आधुनिक कंपाइलरों को कोड की हजारों-हजारों लाइनों के साथ आसानी से सामना करने पर मॉड्यूल में एक बड़े कार्यक्रम को क्यों तोड़ दिया जाता है? यदि कंप्यूटर बिग कोड में चलते हैं, तो हमें परवाह नहीं है, तो हमें क्यों परवाह करनी चाहिए?तो फिर हमें इसकी परवाह क्यों करनी चाहिए?तो फिर हमें इसकी परवाह क्यों करनी चाहिए?

फिर भी, अगर बिंदु के करीब, तो मेरा मानना ​​है कि यह सब कुछ और कुछ नहीं बल्कि थोड़े से लालच के साथ अहंकार है। बिग कोड इस विश्वास से आता है कि एक सॉफ्टवेयर परियोजना इतनी लोकप्रिय और सफल होगी कि लोग इसकी जटिलता - विचारों को इस तरह से सहन करेंगे कि आपकी खुद की डोमेन-विशिष्ट प्रोग्रामिंग भाषा (डीएसएल) सी या एसक्यूएल जितनी विशाल हो जाएगी। यह समस्या को हल करने के लिए तत्परता की कमी के कारण भी प्रकट होता है, और कार्यक्रम तब भी पूरा होता है जब काम का एक महत्वपूर्ण हिस्सा पहले ही पूरा हो चुका होता है। यह भी गलतफहमी से उभरता है कि प्रोग्रामिंग वास्तव में क्या है। मौजूदा स्पष्ट रूप से परिभाषित समस्याओं को हल करने और रास्ते से हटने के बजाय, जैसा कि एक न्यूनतम कार्यप्रणाली के साथ डिज़ाइन किए गए कार्यक्रम करते हैं, बिग कोड वाले कार्यक्रम आवश्यकता से बहुत अधिक करते हैं।इस तरह की परियोजनाएं प्रायः सभी में शामिल होती हैं और एक अनुचित "दृष्टि" के साथ जिसमें सॉफ्टवेयर के लिए सॉफ्टवेयर बनाना शामिल है। यह एक गड़बड़ है क्योंकि कॉर्पोरेट वातावरण में "दृष्टि" जल्दी से राजनीति में आ जाती है। बिग कोड वाले कार्यक्रम हमेशा उस वातावरण का प्रतिबिंब होते हैं जो उन्हें उत्पन्न करता है (कॉनवे का नियम ), और वे हमेशा गणित और कंप्यूटर विज्ञान की सार्वभौमिक भाषा की तुलना में पैरोडी और विशिष्ट हास्य के संग्रह की तरह हैं।

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

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

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