सभी लोग कोड लिखना नहीं जानते हैं

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




- हमें अपने और अपने काम के बारे में कुछ शब्द बताएं।

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

- मॉस्को पायथन कॉन्फ ++ में आप बात करेंगे, जिसमें आपके अपने लिंटर भी शामिल होंगे। आपका काम ऑडिटिंग और कोड जटिलता प्रबंधन से कैसे संबंधित है?

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

- आप विशेष रूप से पायथन में डेवलपर्स से बात करेंगे। क्या कोड जटिलता के संदर्भ में पायथन की कोई विशेषता है?

बेशक!

सबसे पहले, डायनेमिक टाइपिंग वाली सभी भाषाएं अनपेक्षित जटिलता से अधिक से अधिक डिग्री तक पीड़ित होती हैं, कम से कम कोड पढ़ते समय अतिरिक्त संदर्भ की कमी के कारण। और आपको अधिक गंदगी की अनुमति है।

दूसरे, पायथन सक्रिय रूप से विकसित हो रहा है। इसमें नए सिंटैक्स तत्व, नई अवधारणाएं और मानक पुस्तकालयों में मॉड्यूल हैं जो पहले होने वाली हर चीज को तोड़ते हैं।

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

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

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

पायथन में, स्थिति काफी बेहतर है। भाषा काफी व्यवस्थित रूप से विकसित हो रही है, और इस विकास में समझने योग्य मील के पत्थर हैं। इसमें, आप विन्यास में दो पंक्तियों के साथ वाक्यविन्यास को मौलिक रूप से नहीं बदल सकते। और यह अभी भी एक बैकेंड है, जिसके लिए हम सीमांत की तुलना में अधिक मांग करने के आदी हैं। हालाँकि, मेरी राय में, पायथन में कुछ नए बदलाव हुए हैं, जो पहले हुए थे, जो संदिग्ध लाभ ला रहे हैं।

- यानी, भाषा के विकास के साथ, सब कुछ खराब हो जाता है?

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

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

लेकिन पायथन में, जो पांच साल पहले लिखा गया था, वास्तव में कुछ भी नहीं बदला, और इसके विपरीत, उपकरण दिखाई दिए जो कोड को सरल बनाते हैं, उदाहरण के लिए, एनोटेशन और प्रकार की जाँच।

- क्या जटिलता का प्रबंधन इस तथ्य को प्रभावित करता है कि प्रोग्रामिंग में अब कमजोर तकनीकी आधार वाले बहुत सारे लोग हैं?

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

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

- किसी और के कोड की विशिष्ट समस्याएं क्या हैं?

आमतौर पर वे दो भागों में विभाजित होते हैं।

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

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

- और यह अभ्यास में कैसा दिखता है?

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

"आप इन समस्याओं के मुख्य कारण के रूप में क्या देखते हैं?"

सभी लोग कोड लिखना नहीं जानते हैं।

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

"लेकिन विभिन्न प्रोग्रामिंग पैटर्न का उपयोग अनिवार्य रूप से एक इंजीनियरिंग खोज है?" क्या यह वास्तव में बुरा है?

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

मुझे रचनात्मक खोजों का अवलोकन करने की अधिक संभावना है। ऐसे कोई प्रतिबंध नहीं हैं, प्राप्त परिणामों का सत्यापन भी। गुणवत्ता - समकालीन कला में - मापा नहीं जा सकता।

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

- कुछ अन्य दृष्टिकोण की आवश्यकता है?

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

मैं रिपोर्ट के अंदर एक छोटा सा दे दूंगा। हर किसी की समझ है कि कोड में लाइनें शामिल हैं - यह सबसे सरल इकाई है जिसमें यह शामिल हो सकता है। प्रत्येक पंक्ति के रूप में लिखा जा सकता है

x = 1

या शायद पसंद है

x = Math.median(forecast_data) if forecast_data else compute_probability(default_model) ।

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

परिणामस्वरूप, हम कई चीजों को करने से मना नहीं करते हैं। क्योंकि प्रबंधन निषेध के बारे में है।

- क्या आप किसी और के कोड में किसी मज़ेदार चीज़ को लेकर आए हैं?

बेशक। मेरे पास एक रिपॉजिटरी भी है जहां मैं ऐसे कोड उदाहरण एकत्र करता हूं।

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

एक मामला था जब हमने कोड में कई मजेदार टिप्पणियां देखीं। किसी ने जीवन के बारे में शिकायत की, काम के बारे में, ऐसे लोग थे जिन्होंने लिखा था: "मैं समझता हूं कि मैं बकवास लिख रहा हूं, लेकिन ग्राहक मुझे मजबूर करता है।" हालांकि, ग्राहक आमतौर पर आपको खराब कोड लिखने के लिए मजबूर नहीं करते हैं। वे अपनी समस्या को हल करने के लिए कहते हैं, और आप वहां क्या कोड लिखते हैं, वे परवाह नहीं करते हैं।

- लिंटर, कोड की समीक्षा - बचा नहीं?

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

लेकिन वास्तव में - वे नहीं बचाते हैं। क्योंकि जो परियोजनाएं इसका उपयोग करती हैं वे दुर्लभ हैं।

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

- क्या इस सवाल का कोई सामान्य जवाब है?

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

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

- अंत में, क्या यह एक प्रशासनिक समस्या है?

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

यही है, सभी मुद्दों को यहां हल किया जाता है: कोई अघुलनशील विरोधाभास नहीं हैं।

- एक कोड शैली है - PEP 8. यह जल्दी से समझने में मदद नहीं करता है कि क्या अच्छा है?

अल्पविराम के संदर्भ में, यह मदद करता है। लेकिन क्या बात है अगर आप कॉमा को सही रखते हैं और बाकी सब खराब है?

- कुछ प्रसिद्ध उच्च स्तरीय सामान गुम?

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

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

सामान्य तौर पर, हमारा अप्राप्य वैश्विक कार्य कोड समीक्षा को स्वचालित करना है ताकि पायथन खुद (यदि हम अपने मामले के बारे में बात कर रहे हैं) जानता है कि इसे कैसे लिखना है। यह एक उपकरण होना चाहिए जो न केवल अवसर प्रदान करता है, बल्कि डेवलपर्स के लिए सीमाएं भी है।

- आप लिंटर भी क्यों विकसित कर रहे हैं? क्या मौजूदा का उपयोग करना (या विकसित करना) संभव है?

वास्तव में, हम ऐसा करते हैं। वास्तव में हमारा लिंटर फ्लेक 8 के लिए एक प्लगइन है। हम इसे एक पूर्ण टूल के रूप में स्थिति देते हैं, और केवल प्लग-इन नहीं।

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

- इस लिंटर के आधार पर किस गाइड का गठन किया गया? या यह केवल आपका अपना अनुभव है?

अब यह उन नियमों पर आधारित है जिन्हें हम कई वर्षों से कोड समीक्षा में खुद के लिए तैयार कर रहे हैं। कुछ नियमों को अन्य लिंटर्स से चित्रित किया गया था: ESLint, Pylint, SonarQube, Credo। CognitiveComplexity के उत्कृष्ट कार्य से बहुत कुछ लिया गया है। हमेशा मिलर के बटुए को देखा। अलग-अलग नियम - यह मेरी दृष्टि है, जो बड़ी संख्या में अन्य लोगों के कोड का मूल्यांकन करने के बाद दिखाई देती है। यही है, इस स्तर पर यह एक "हॉजपॉज" है।

- मॉस्को पायथन कॉन्फ ++ में आप किस बारे में बात करेंगे?

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

- रिपोर्ट किस पर केंद्रित है?

मुझे लगता है कि ये अभी भी स्थापित डेवलपर्स हैं, क्योंकि नौसिखिए प्रोग्रामर ने अभी तक अपनी स्पष्ट राय नहीं बनाई है। हालांकि उनके लिए सुनना और बोलना दिलचस्प होगा। वे निश्चित रूप से हमारे उपयोगकर्ता हैं।

---

, , Moscow Python Conf++ . . , .