वेबिनार खोलें "पायथन में कैसे न लिखें"

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

वीडियो देखें और विवरण के लिए सारांश। चेतावनी: कुछ कोड उदाहरणों को आपके कंप्यूटर पर चलाने की अनुशंसा नहीं की जाती है!


खुले पाठ के दौरान, शिक्षक ने ज्यूपिटर नोटबुक के साथ उत्पन्न स्लाइड्स को दिखाया।

तो चलिए शुरू करते है!

तो पायथन में क्यों नहीं लिखा?

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

• डायपर पैटर्न। यह तथाकथित "डायपर" पैटर्न के बारे में था, जिसका अर्थ है आमतौर पर बहुत व्यापक प्रयास को छोड़कर। उदाहरण के लिए, आप किसी फ़ंक्शन को किसी चीज़ के लिए एक आवरण कहते हैं, उदाहरण के लिए, यह किसी प्रकार के डेटाबेस के लिए क्लाइंट लिबास को लपेटता है। एक अच्छे मामले में (सिस्टम छोटा है) 99% मामलों में सबकुछ ठीक हो जाएगा, लेकिन अगर सिस्टम बड़ा है, तो किसी समस्या की संभावनाओं को सबसे अच्छे तरीके से गुणा नहीं किया जाता है। नतीजतन, कुछ लगातार गिरता है या टूट जाता है।
• Antiglobalism। हर कोई जानता है कि वैश्विक चर कुछ असाधारण मामलों को छोड़कर, अक्षम हैं। वांछित परिणामों को प्राप्त करने, आदि कार्यों के लिए, आदि, आदि के रूप में सब कुछ पारित करना बेहतर है। हालांकि, कुछ एक "महान विचार" के साथ आते हैं - परस्पर वस्तुओं का उपयोग करने के लिए। इसमें वैश्विक चर नहीं, बल्कि परिवर्तनशील वस्तुओं को कार्य में पारित करना, फिर उन्हें अंदर बदलना और फिर कुछ भी वापस नहीं करना शामिल है। यह बहुत अच्छा है!) वास्तव में, सी भाषा से प्रोग्रामिंग टेम्पलेट का एक टुकड़ा, पायथन दुनिया में स्थानांतरित कर दिया गया।
• स्वर्ग की सीढ़ी। जैसा कि आप अनुमान लगा सकते हैं, यह एक "स्वर्ग की सीढ़ी" है। यह समस्या एक साधारण तस्वीर की विशेषता है:
  
  
• Javatar। इस योजना की त्रुटियां अक्सर उन प्रोग्रामरों द्वारा बनाई जाती हैं जो एक कारण से या किसी अन्य ने जावा से पायथन में स्विच किया। स्वाभाविक रूप से, वे अपने स्वयं के चार्टर के साथ आते हैं, इसलिए वे पायथन विकास नियमों का उल्लंघन करते हैं। यह पागल इंडेंटेशन, और CamelCase की उपस्थिति है, और अधिक कक्षाएं बनाने की इच्छा ... नतीजतन, कोड संरचना अधिक जटिल हो जाती है। जहां 300 लाइनों के आकार वाली एक स्क्रिप्ट के साथ भेजा जा सकता है, हम 10-20 फाइलें देखते हैं।
• Overengineering। बहुत बार, किसी परियोजना का दूसरा पुनरावृत्ति या तो कभी पूरा नहीं होता है या बहुत जटिल तरीके से लागू किया जाता है। यदि आप किसी मौजूदा लेकिन त्रुटिपूर्ण कोड को फिर से लिखना चाहते हैं, तो यह आदर्श बनता है। इसी समय, आप भूल जाते हैं कि सबसे अच्छा अच्छे का दुश्मन है। नतीजतन, प्रोग्रामर पुनर्मिलन के मानक जाल में गिर जाता है, जब कार्यान्वयन कार्यों को हल करने के लिए आवश्यक से अधिक महंगा, भारी और बोझिल हो जाता है। और वास्तव में: क्या पारिवारिक सेडान को 350 किमी / घंटा तक की गति तक पहुंचना चाहिए, और स्मार्टफोन, जिस फैशन के लिए हर साल बदलाव होता है, 100 साल तक काम करता है?
• Oneliner। एक और जरूरी समस्या है "सिंगल लाइन"। यह प्रोग्रामर के बारे में है जो हर चीज को एक पंक्ति में, पांच मंजिलों पर विज्ञापनों में धकेलने के लिए एक उत्साही उत्साह के साथ प्रयास कर रहे हैं))। पायथन में मशीन-नियमित अभिव्यक्तियों के कार्यान्वयन के लिए कोड की अत्यधिक जटिलता और विशिष्टताओं के कारण, ऐसी स्क्रिप्ट कभी-कभी पार्सिंग के लिए "छड़ी" करती हैं, इसलिए आपको समस्या को ठीक करने के लिए एक विशेष मॉड्यूल का उपयोग करना होगा।
• कॉपी-ऑन-पढ़ें। यह पायथन प्रोग्रामिंग की एक विशेषता के रूप में इतनी गलती नहीं है। कई लोग कॉपी-ऑन-अप दृष्टिकोण से परिचित हैं। उनका विचार है कि डेटा क्षेत्र को पढ़ते समय, एक साझा प्रतिलिपि का उपयोग किया जाता है, और बदलते समय, एक नई प्रतिलिपि बनाई जाती है, अर्थात हम प्रदर्शन प्रक्रियाओं के अनुकूलन के बारे में बात कर रहे हैं। यदि हम पायथन के बारे में बात करते हैं, तो कुछ मामलों में हम केवल तत्वों से सरणी को नहीं पढ़ते हैं, लेकिन उन सभी अंतर्निहित संरचनाओं का उल्लेख करते हैं जो स्मृति में हैं, अर्थात्, हम स्मृति को "फिर से लिखना" करते हैं, इसे बदल रहे हैं। इस प्रकार, कॉपी-ऑन-राइट के बजाय, हम कॉपी-ऑन-रीड प्राप्त करते हैं जब हम मेमोरी को पढ़ने लगते हैं, लेकिन वास्तव में हमें इस जानकारी को पेरेंट स्पेस से खुद को चाइल्ड प्रोसेस के रूप में कॉपी करना पड़ता है, जो दृष्टिकोण के बाद से दुखी करता है अनुकूलन काम नहीं करता है, और खपत बढ़ रही है।
• कोई कांटा नहीं है। कांटा - एक नई प्रक्रिया के उद्भव का क्लोनिंग। समस्या यूनिक्स प्रणालियों के साथ काम करने की बारीकियों और कार्यान्वयन में छिपी कुछ डेटा संरचनाओं की गैर-स्पष्टता से संबंधित है। एक "कांटा" प्रक्रिया एक ऐसी प्रक्रिया है जो उस समय शुरू होती है जब धागे ने कतार में लॉग को पकड़ लिया है ताकि उसमें कुछ डाला जा सके। यही है, जो नई प्रक्रिया उत्पन्न हुई है, वह भी कुछ लिखना चाहती है, लेकिन इसके लिए उसे इस कतार से लॉग को हथियाने की जरूरत है, लेकिन वह ऐसा नहीं कर सकता, क्योंकि लॉग पहले ही कैप्चर हो चुका है। नतीजतन, हमें एक ताला मिलता है। यह सब केवल एक बार फिर से पुष्टि करता है कि यह प्रोग्रामिंग के लायक नहीं है, पर्यावरण के कार्यान्वयन की विशेषताओं को नहीं जानता जिसमें आप काम करते हैं और आपके द्वारा उपयोग किए जाने वाले उपकरण।

अभी भी बहुत सारी दिलचस्प चीजें थीं, इसलिए बेहतर वीडियो देखें, क्योंकि रिटेलिंग अभी भी कम है।

हमेशा की तरह, हम यहाँ या खुले दरवाजे पर प्रश्नों, टिप्पणियों और सुझावों की प्रतीक्षा कर रहे हैं।