पाइथन कोडको ४ मिलियन लाइनहरू टाइप चेक गर्ने बाटो। भाग 4

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

→ अघिल्लो भागहरू: पहिलो и दोस्रो

टाइप गरिएको कोडको 4 मिलियन लाइनहरू पुग्दै

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

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

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

एनोटेट कोडको लाइनहरूको संख्या: सर्भर

एनोटेटेड कोडको लाइनहरूको संख्या: ग्राहक

एनोटेटेड कोडका लाइनहरूको कुल संख्या

यहाँ हामीले ड्रपबक्समा एनोटेट कोडको मात्रा बढाउनका लागि गरेका चीजहरूको मुख्य विशेषताहरूको सिंहावलोकन छ:

एनोटेसन कठोरता। हामीले बिस्तारै नयाँ कोड एनोटेट गर्ने कठोरताका लागि आवश्यकताहरू बढाएका छौं। हामीले पहिले नै केही एनोटेसनहरू भएका फाइलहरूमा एनोटेसनहरू थप्न सुझाव दिने linter सुझावहरूसँग सुरु गर्यौं। हामीलाई अब नयाँ पाइथन फाइलहरू र धेरै अवस्थित फाइलहरूमा टाइप एनोटेसनहरू चाहिन्छ।

रिपोर्टहरू टाइप गर्दै। हामी टोलीहरूलाई तिनीहरूको कोडमा टाइप गर्ने स्तरमा साप्ताहिक रिपोर्टहरू पठाउँछौं र पहिले के एनोटेट गर्नुपर्छ भनेर सल्लाह दिन्छौं।

Mypy को लोकप्रियता। हामी घटनाहरूमा mypy बारे कुरा गर्छौं र टोलीहरूलाई टाइप एनोटेसनहरू सुरु गर्न मद्दत गर्नको लागि कुरा गर्छौं।

मतदान। हामी प्रमुख समस्याहरू पहिचान गर्न आवधिक प्रयोगकर्ता सर्वेक्षणहरू सञ्चालन गर्छौं। हामी यी समस्याहरू समाधान गर्न धेरै टाढा जान तयार छौं (mypy को गति बढाउन नयाँ भाषा सिर्जना गर्न पनि!)

प्रदर्शन। हामीले डेमन र mypyc प्रयोग गरेर mypy को कार्यसम्पादनमा धेरै सुधार गरेका छौं। यो एनोटेसन प्रक्रियाको क्रममा उत्पन्न हुने असुविधाहरूलाई सहज बनाउन र कोडको ठूलो मात्रामा काम गर्न सक्षम हुनको लागि गरिएको थियो।

सम्पादकहरूसँग एकीकरण। हामीले Dropbox मा लोकप्रिय सम्पादकहरूमा चलिरहेको mypy लाई समर्थन गर्न उपकरणहरू निर्माण गरेका छौं। यसमा PyCharm, Vim र VS कोड समावेश छ। यसले कोड एनोटेट गर्ने र यसको कार्यक्षमता जाँच गर्ने प्रक्रियालाई धेरै सरल बनायो। अवस्थित कोड एनोटेट गर्दा यी प्रकारका कार्यहरू सामान्य हुन्छन्।

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

तेस्रो पक्ष पुस्तकालयहरूको लागि समर्थन। हाम्रा धेरै परियोजनाहरूले SQLAlchemy टूलकिट प्रयोग गर्छन्। यसले पाइथनको गतिशील क्षमताहरूको फाइदा लिन्छ कि PEP 484 प्रकारहरू सीधा मोडेल गर्न असमर्थ छन्। हामीले, PEP 561 को अनुसार, सम्बन्धित स्टब फाइल सिर्जना गर्यौं र mypy को लागी प्लगइन लेख्यौं (खुला स्रोत), जसले SQLAlchemy समर्थन सुधार गर्दछ।

हामीले सामना गरेका कठिनाइहरू

टाइप गरिएको कोड को 4 मिलियन लाइनहरु को मार्ग सधैं हाम्रो लागि सजिलो भएको छैन। यो बाटोमा हामीले धेरै खाल्डाहरू सामना गर्यौं र धेरै गल्तीहरू गर्यौं। यी हामीले सामना गरेका केही समस्याहरू हुन्। हामी आशा गर्छौं कि तिनीहरूको बारेमा बताउनुभयो भने अरूलाई यस्तै समस्याहरूबाट बच्न मद्दत गर्नेछ।

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

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

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

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

नतिजाहरू: 5 मिलियन लाइनहरू कोड र नयाँ क्षितिजहरूको मार्ग

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

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

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

प्रिय पाठकहरु! के तपाइँ तपाइँको पाइथन परियोजनाहरूमा टाइप जाँच प्रयोग गर्नुहुन्छ?

स्रोत: www.habr.com