अजगर कोड की 4 मिलियन लाइनों की जाँच करने का तरीका। भाग 3

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



→ पिछले भाग: पहला और दूसरा

टाइप किए गए कोड की 4 मिलियन पंक्तियों तक पहुंचना

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

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

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


एनोटेट कोड की पंक्तियों की संख्या: सर्वर


एनोटेट कोड की लाइनों की संख्या: क्लाइंट


एनोटेट कोड की कुल पंक्तियों की संख्या

ड्रॉपबॉक्स में एनोटेट कोड की मात्रा बढ़ाने के लिए हमने जो कार्य किए हैं, उनकी मुख्य विशेषताओं का अवलोकन यहां दिया गया है:

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

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

मैपी को लोकप्रिय बनाना। हम विभिन्न घटनाओं पर मैपी के बारे में बात करते हैं और टाइप एनोटेशन का उपयोग शुरू करने में मदद करने के लिए टीमों के साथ संवाद करते हैं।

पोल। हम प्रमुख मुद्दों की पहचान करने के लिए आवधिक उपयोगकर्ता सर्वेक्षण करते हैं। हम इन समस्याओं को हल करने के लिए बहुत दूर जाने के लिए तैयार हैं (ठीक है, खसखस ​​को तेज करने के लिए एक नई भाषा बनाने के लिए)।

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

संपादकों के साथ एकीकरण। हमने ड्रॉपबॉक्स पर लोकप्रिय संपादकों में mypy के लॉन्च का समर्थन करने के लिए उपकरण बनाए हैं। इसमें PyCharm, Vim और VS कोड शामिल हैं। इसने कोड को एनोटेट करने और उसके प्रदर्शन को सत्यापित करने की प्रक्रिया को बहुत सरल बना दिया। मौजूदा कोड को एनोटेट करते समय ऐसी क्रियाएं आमतौर पर विशिष्ट होती हैं।

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

तृतीय-पक्ष पुस्तकालयों के लिए समर्थन। हमारी कई परियोजनाएँ SQLAlchemy टूलकिट का उपयोग करती हैं। यह पायथन की गतिशील क्षमताओं का उपयोग करता है, जिसे पीईपी 484 प्रकार सीधे मॉडल करने में असमर्थ हैं। PEP 561 के अनुसार, हमने संबंधित स्टब फ़ाइल बनाई और Mypy ( ओपन सोर्स ) के लिए एक प्लगइन लिखा जो SQLAlchemy सपोर्ट को बेहतर बनाता है।

जो मुश्किलें हमें मिलीं

टाइप किए गए कोड की 4 मिलियन लाइनों का रास्ता हमारे लिए हमेशा आसान नहीं था। इस तरह हम बहुत सारे छेदों से मिले और कुछ गलतियाँ कीं। यहाँ कुछ समस्याओं का सामना करना पड़ा है। हमें उम्मीद है कि उनके बारे में कहानी दूसरों को ऐसी समस्याओं से बचने में मदद करेगी।

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

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

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

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

सारांश: 5 मिलियन लाइनों का कोड और नए क्षितिज

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

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

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

प्रिय पाठकों! क्या आप अपने पायथन प्रोजेक्ट्स में टाइप कंट्रोल का उपयोग करते हैं?