👹 🐃 🛳️ NoVerify: VKontakte टीम से PHP के लिए लाइनर अब सार्वजनिक डोमेन में है 🤸🏼 👩🏾‍🎓 🙃

मैं आपको बताता हूं कि हम कैसे एक लिंटर लिखने में कामयाब रहे जो प्रत्येक गिट पुश के दौरान परिवर्तनों की जांच करने के लिए काफी तेज़ हो गया और इसे 5-10 सेकंड में PHP में 5 मिलियन लाइनों के कोड बेस के साथ किया। हमने इसे NoVerify कहा।

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

हमें अपने लिंटर की आवश्यकता क्यों है

2018 के मध्य में, हमने फैसला किया कि यह PHP कोड के लिए एक लाइनर को लागू करने का समय था। दो लक्ष्य थे: उन त्रुटियों की संख्या को कम करने के लिए जो उपयोगकर्ता देखते हैं, और कोड शैली के अनुपालन की अधिक सख्ती से निगरानी करते हैं। मुख्य त्रुटि विशिष्ट त्रुटियों की रोकथाम पर थी: कोड में अघोषित और अप्रयुक्त चर की उपस्थिति, अनुपलब्ध कोड, और अन्य। मैं यह भी चाहता था कि स्टेटिक एनालाइज़र हमारे कोड बेस (लेखन के समय PHP कोड की 5-6 मिलियन लाइन्स) पर जल्दी से जल्दी काम करे।

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

क्यों नहीं

PHP कोड की मात्रा को देखते हुए (मैं आपको याद दिलाता हूं कि यह 5-6 मिलियन लाइनें हैं), इसे तुरंत "ठीक" करना संभव नहीं है ताकि यह लाइनर में हमारी जांचों को पास कर सके। फिर भी, मैं चाहता हूं कि बदलते कोड धीरे-धीरे क्लीनर बन जाएं और अधिक सख्ती से कोडिंग मानकों का पालन करें, और इसमें कम त्रुटियां भी हैं। इसलिए, हमने तय किया कि लिंटर को उन परिवर्तनों की जांच करने में सक्षम होना चाहिए जो डेवलपर लॉन्च करने जा रहा है, और बाकी की कसम नहीं खाता है।

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

लेकिन ऐसी परिस्थितियां होती हैं जब यह व्यवहार अवांछनीय होता है, और फिर डेवलपर्स बिना स्थानीय हुक के धक्का दे सकते हैं - git push --no-verify का उपयोग करते हुए। विकल्प --no-verify और एक लाइनर को एक नाम दिया :)

क्या विकल्प थे

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

हमने निम्नलिखित स्थैतिक विश्लेषण उपकरणों की जांच की:

PHPStan - एकल-थ्रेडेड, ऑटोलैड की आवश्यकता होती है, कोड आधार विश्लेषण आधे घंटे में 30% तक पहुंच गया है;
फ़ान - यहां तक कि 20 प्रक्रियाओं के साथ त्वरित मोड में, विश्लेषण 20 मिनट के बाद 5% तक रुक गया;
भजन - ऑटोलैड की आवश्यकता है, विश्लेषण में 10 मिनट लगे (मैं अभी भी बहुत तेज होना चाहूंगा);
PHPCS - शैली की जांच करता है, लेकिन तर्क नहीं;
phpcf - केवल स्वरूपण के लिए जाँच करता है।

जैसा कि आप लेख के शीर्षक से अनुमान लगा सकते हैं, इनमें से कोई भी उपकरण हमारी आवश्यकताओं को पूरा नहीं करता है, इसलिए हमने अपना लिखा।

प्रोटोटाइप कैसे बनाया गया था?

सबसे पहले, हमने यह समझने के लिए एक छोटे से प्रोटोटाइप का निर्माण करने का फैसला किया कि क्या यह पूर्ण-आधारित लाइनर बनाने की कोशिश करने लायक है। चूंकि लिंटर के लिए महत्वपूर्ण आवश्यकताओं में से एक इसकी गति है, PHP के बजाय हमने गो को चुना। "फास्ट" डेवलपर को जल्द से जल्द प्रतिक्रिया देना है, अधिमानतः 10 is20 सेकंड से अधिक नहीं। अन्यथा, चक्र "कोड को सही करें, लिंटर फिर से चलाएं" विकास को धीमा करना और लोगों के लिए मूड को खराब करना शुरू कर देता है :)

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

प्रोटोटाइप के लिए, पहली नज़र में सबसे सरल में से एक को लागू करने का प्रयास करने का निर्णय लिया गया था, निरीक्षण: एक अपरिभाषित चर तक पहुंच।

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

 <?php if (rand()) { $a = 42; //  : { $a: int } } else { $b = "test"; $a = "another_test"; //  : { $b: string, $a: string } } //   : { $b: string?, $a: int|string } echo $a, $b; //       , //   $b

यह सरल लगता है, है ना? साधारण सशर्त बयानों के मामले में, सब कुछ अच्छी तरह से काम करता है। लेकिन हमें संभालना चाहिए, उदाहरण के लिए, ब्रेक के बिना स्विच करें;

 <?php switch (rand()) { case 1: $a = 1; // { $a: int } case 2: $b = 2; // { $a: int, $b: int } default: $c = 3; // { $a: int, $b: int, $c: int } } // { $a: int?, $b: int?, $c: int }

यह कोड से तुरंत स्पष्ट नहीं है कि $ c वास्तव में हमेशा परिभाषित किया जाएगा। विशेष रूप से, यह उदाहरण काल्पनिक है, लेकिन यह अच्छी तरह से दिखाता है कि लिंटर (और इस मामले में व्यक्ति के लिए भी) के लिए क्या मुश्किल क्षण हैं।

अधिक जटिल उदाहरण पर विचार करें:

 <?php exec("hostname", $out, $retval); echo $out, $retval; // { $out: ???, $retval: ??? }

निष्पादन समारोह के हस्ताक्षर को जाने बिना, यह नहीं कहा जा सकता है कि क्या $ आउट और $ रिटेल को परिभाषित किया जाएगा। अंतर्निहित कार्यों के हस्ताक्षर भंडार github.com/JetBrains/phpstorm-stubs से लिए जा सकते हैं। लेकिन उपयोगकर्ता-परिभाषित कार्यों को कॉल करने पर समान समस्याएं होंगी, और उनके हस्ताक्षर केवल पूरे प्रोजेक्ट को अनुक्रमित करके ही खोजे जा सकते हैं। निष्पादन फ़ंक्शन संदर्भ द्वारा दूसरे और तीसरे तर्क को लेता है, जिसका अर्थ है कि चर $ बाहर और $ रिटवल को परिभाषित किया जा सकता है। यहाँ, इन चरों को एक्सेस करना एक त्रुटि नहीं है, और लिंटर को ऐसे कोड की कसम नहीं खानी चाहिए।

अंतर्निहित लिंक के साथ इसी तरह की समस्याएं विधियों के साथ उत्पन्न होती हैं, लेकिन एक ही समय में, चर प्रकारों को कम करने की आवश्यकता को जोड़ा जाता है:

 <?php if (rand()) { $a = some_func(); } else { $a = other_func(); } $a->some_method($b); echo $b;

हमें यह जानने की आवश्यकता है कि इन वर्गों में some_method नामक एक विधि को खोजने के लिए some_func () और other_func () फ़ंक्शन किस प्रकार वापस आते हैं। इसके बाद ही हम कह सकते हैं कि चर $ b को परिभाषित किया जाएगा या नहीं। स्थिति इस तथ्य से जटिल है कि अक्सर सरल कार्यों और विधियों में phpdoc एनोटेशन नहीं होते हैं, इसलिए आपको अभी भी उनके कार्यान्वयन के आधार पर कार्यों और विधियों के प्रकारों की गणना करने में सक्षम होने की आवश्यकता है।

प्रोटोटाइप का विकास करते समय, मुझे लगभग आधी कार्यक्षमता को लागू करना पड़ा, ताकि सबसे सरल निरीक्षण के रूप में काम करना चाहिए।

भाषा सर्वर के रूप में कार्य करें

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

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

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

चर नाम, स्थिरांक, कार्य, गुण और विधियों के लिए युक्तियाँ।
व्युत्पन्न प्रकारों को हाइलाइट करें।
परिभाषा पर जाएं।
उपयोग के लिए खोजें।

"आलसी" प्रकार का अनुमान

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

 <?php //  A.php,  1 class A { /** @var int */ public $prop; } //  B.php,   class B { public static function something() { $obj = new A; return $obj->prop; } } //  C.php,   $c = B::something(); // $c   int //  A.php,  2 class A { /** @var string <---   string */ public $prop; } //  C.php,   $c = B::something(); // $c   string,   B.php,  C.php

यह देखते हुए कि हम डेवलपर्स को हमेशा PHPDoc (विशेष रूप से ऐसे सरल मामलों में) लिखने के लिए मजबूर नहीं करते हैं, हमें बी :: कुछ प्रकार () फ़ंक्शन रिटर्न के बारे में जानकारी संग्रहीत करने का एक तरीका चाहिए। ताकि जब A.php फ़ाइल बदले, C.php फ़ाइल में टाइप जानकारी तुरंत अप टू डेट हो।

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

काम के दो चरण: अनुक्रमण और विश्लेषण

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

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

अनुक्रमण चरण

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

परियोजना के बारे में सभी मेटा-जानकारी का एक वैश्विक शब्दकोश, जो भविष्य में नहीं बदलता है, * व्यक्तिगत टुकड़ों से संकलित किया जाता है।

* भाषा सर्वर के रूप में ऑपरेशन के मोड के अलावा, जब परिवर्तित फ़ाइल का अनुक्रमण और विश्लेषण प्रत्येक संपादन के लिए किया जाता है।

विश्लेषण चरण

इस चरण में, हम मेटा-सूचना (फ़ंक्शंस, क्लासेस ...) का उपयोग कर सकते हैं और पहले से ही कोड का सीधे विश्लेषण कर सकते हैं। यहां इस बात की सूची दी गई है कि NoVerify डिफ़ॉल्ट रूप से क्या जांच सकता है:

अगम्य कोड;
एक सरणी के रूप में वस्तुओं तक पहुंच;
फ़ंक्शन को कॉल करते समय अपर्याप्त संख्या में तर्क;
एक अपरिभाषित विधि / फ़ंक्शन को कॉल करना;
लापता वर्ग की संपत्ति / निरंतर तक पहुंच;
कक्षा की कमी;
अमान्य PHPDoc
एक अपरिभाषित चर तक पहुंच;
एक चर की पहुंच जो हमेशा परिभाषित नहीं होती है;
"ब्रेक" की कमी स्विच / केस कंस्ट्रक्शन में केस के बाद;
वाक्यविन्यास त्रुटि
अप्रयुक्त चर।

सूची बहुत कम है, लेकिन आप अपने प्रोजेक्ट के लिए विशिष्ट चेक जोड़ सकते हैं।

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

काम की गति

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

परिणाम क्या है?

चूंकि समाधान को गो में लिखा गया है, इसलिए PHP में निर्मित सभी कार्यों और वर्गों की परिभाषाओं के लिए github.com/JetBrains/phpstorm-stubs रिपॉजिटरी का उपयोग करना आवश्यक है। बदले में, हमें काम की एक उच्च गति मिली (प्रति सेकंड 1 मिलियन लाइनों को अनुक्रमित करना, प्रति सेकंड 100 हजार लाइनों का विश्लेषण) और लाइनर के साथ चेक जोड़ने में सक्षम थे जो गिट पुश हुक में पहले चरणों में से एक था।

नए निरीक्षण बनाने के लिए एक सुविधाजनक आधार विकसित किया गया था और PHPStorm के निकट कोड समझ का स्तर हासिल किया गया था। इस तथ्य के कारण कि बॉक्स से अलग गणना के साथ मोड का समर्थन किया जाता है, नए कोड में नए संभावित समस्याग्रस्त निर्माणों से बचने के लिए, धीरे-धीरे कोड में सुधार करना संभव है।

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

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

खुला स्रोत

GitHub पर खुले स्रोत पर उपलब्ध NoVerify

अपनी परियोजना में अपने उपयोग का आनंद लें!

UPD: मैंने एक डेमो तैयार किया जो WebAssembly के माध्यम से काम करता है । इस डेमो की एकमात्र सीमा phststorm-stubs से फ़ंक्शन परिभाषाओं की कमी है, इसलिए लिंटर अंतर्निहित कार्यों पर शपथ लेंगे।

यूरी नसेरेतिनोव, VKontakte के बुनियादी ढांचे विभाग के डेवलपर

NoVerify: VKontakte टीम से PHP के लिए लाइनर अब सार्वजनिक डोमेन में है