स्पेगेटी कार्यप्रणाली के गुणों पर

हाल ही में, प्रोग्रामिंग के लिए क्लासिक स्पेगेटी दृष्टिकोण की प्रस्तुति के साथ एक दोस्ताना सेवा कंपनी का एक विशेषज्ञ हमारी कंपनी में आया। निम्नलिखित उनके व्याख्यान की एक वापसी है। प्रस्तुति में रुचि और चर्चा हुई (प्रबंधकों के बीच)।

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

प्रबंधन प्रस्तुति के परिणामों से प्रेरित था, क्योंकि परियोजना में नए कार्यों को शुरू करने के चरण में दृष्टिकोण के फायदे स्पष्ट रूप से थे:
1) नए डेवलपर्स के लिए न्यूनतम प्रवेश सीमा;
2) स्क्रम और एजाइल पद्धति के साथ उत्कृष्ट एकीकरण;
3) बाहरी परावर्तन के संबंध में परियोजना स्थिरता;
4) परियोजना में नई प्रोग्रामिंग भाषाओं और आधुनिक प्रौद्योगिकियों का सरल एकीकरण;
5) एक परियोजना तत्व विकसित करने की लागत कम;
6) एक कार्यशील परियोजना के लिए प्रस्तुतियाँ, पैच और परिवर्धन बनाने की उच्चतम गति।

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

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

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

आइए स्पेगेटी पद्धति की मूल बातों पर करीब से नज़र डालें

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

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

स्पेगेटी से प्रस्थान की नई सदी ने क्या नया दिया है?

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

क्यों एक नौसिखिया प्रोग्रामर लगभग हमेशा स्पेगेटी दृष्टिकोण की कोशिश करता है, केवल कार्यप्रणाली का एक स्तर उसके विचारों को पूर्वाग्रह करता है? क्यों बैसाखी प्रोग्रामर हैं जो आसानी से अपने द्वारा लिखे गए ऐसे कोड को आसानी से पचा सकते हैं, बिना किसी सिस्टम को ठीक किए, लगभग किसी बग का स्रोत खोज सकते हैं?

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

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

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

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

स्पेगेटी पद्धति प्रोग्रामिंग में एक आविष्कार नहीं है, जैसा कि आमतौर पर सोचा जाता है

एक समान दृष्टिकोण लंबे समय से विमानन में सफलतापूर्वक उपयोग किया गया है:


(एक मॉड्यूलर दृष्टिकोण के साथ दृश्य एकीकरण),

शहरी नियोजन और रसद में:



कृषि में:



सिस्टम प्रशासन में:



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

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

1. निर्णय लेने के लिए उच्च स्तरीय पदानुक्रमित संगठन।
2. लक्ष्यों को स्थापित करने और संशोधित करने में लचीलापन।
3. अत्यधिक वित्तपोषण की स्थिति।
4. कम कर्मचारियों के कारोबार के कारण पर्याप्त स्टाफिंग स्तर।
5. क्लॉज 2 के साथ संयोजन में दीर्घकालिक योजना

निजी व्यवसाय राज्य से पीछे नहीं है। स्मरण करो कि पहले कंप्यूटर और सिस्टम इस दृष्टिकोण पर सटीक रूप से बनाए गए थे, और केवल प्रौद्योगिकी और कंप्यूटर विज्ञान के विकास ने प्रोग्रामर और प्रबंधकों के लिए रोजगार के नए रूप पाए। अब यह मूल में लौटने और 20 वीं शताब्दी के 50 के दशक के बाद मानवता को प्राप्त हुए सभी सर्वश्रेष्ठ को आकर्षित करने का प्रस्ताव है।

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

स्पीकर ने जटिल समस्याओं को हल करने के लिए कुछ तरीके दिखाए जो पद्धति के लचीलेपन के परिणामस्वरूप उत्पन्न होते हैं।

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

बड़ी संख्या में संबंधों के साथ, थ्रेड कलर मार्कर मदद करते हैं। देखें कि उनके द्वारा अंतर्निहित विचार कितना सरल और समझ में आता है:

और शुरू में जटिल योजना को समझना कितना आसान हो जाता है:



यह आपको उदाहरण के रूप में शिथिल युग्मित घटना में भी संबंध देखने की अनुमति देता है।
यदि नोड्स का वर्गीकरण आवश्यक है - इसी तरह:


आमतौर पर इस स्तर पर, वक्ता ने कहा, प्रबंधकों और डेवलपर्स के थोक पहले से ही दृष्टिकोण का स्वागत करते हैं, और केवल एक छोटा सा हिस्सा अपने अनुभव के बारे में सोचता है और आरेखों को न देखने की कोशिश करता है।

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

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

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

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

हम डिजाइन में स्पेगेटी दृष्टिकोण के पेशेवरों और विपक्षों को सूचीबद्ध करते हैं।

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

निष्कर्ष *)

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

* व्याख्याता की राय हमेशा संपादक के दृष्टिकोण से मेल नहीं खाती है ।