पायथन कोड की बड़ी मात्रा का स्थैतिक विश्लेषण: इंस्टाग्राम अनुभव। भाग 1

इंस्टाग्राम सर्वर कोड विशेष रूप से पायथन में लिखा गया है। खैर, मूल रूप से यह है। हम थोड़ा सायथॉन का उपयोग करते हैं, और निर्भरता में बहुत सी सी + + कोड शामिल होता है जिसे सी-एक्सटेंशन के साथ पायथन से संचालित किया जा सकता है।



हमारा सर्वर एप्लिकेशन एक मोनोलिथ है, जो एक बड़ी कोड बेस है जिसमें कई मिलियन लाइनें शामिल हैं और कई हजार Django के एंडपॉइंट्स शामिल हैं ( यहां इंस्टाग्राम पर Django का उपयोग करने के बारे में एक बात है)। यह सब एक इकाई के रूप में लोड और परोसा जाता है। मोनोलिथ से कई सेवाओं को आवंटित किया गया है, लेकिन हमारी योजना में मोनोलिथ का मजबूत अलगाव शामिल नहीं है।

हमारा सर्वर सिस्टम एक मोनोलिथ है जो बहुत बार बदलता है। हर दिन, सैकड़ों प्रोग्रामर कोड करने के लिए सैकड़ों आवागमन करते हैं। हम लगातार इन परिवर्तनों को तैनात करते हैं, हर सात मिनट में ऐसा करते हैं। नतीजतन, परियोजना दिन में लगभग सौ बार उत्पादन में तैनात की जाती है। हम यह सुनिश्चित करने का प्रयास करते हैं कि मास्टर शाखा में कमिटमेंट प्राप्त करने और उत्पादन में संबंधित कोड को लागू करने के बीच एक घंटे से भी कम समय गुजरता है ( यहाँ PyCon 2019 में इस बारे में बात की गई है)।

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

यह सामग्री इस बात पर ध्यान केंद्रित करती है कि हम पायथन कोडबेस को प्रबंधित करने के लिए कैसे आसान बनाने के लिए लाइनिंग और स्वचालित रीफैक्टरिंग का उपयोग करते हैं।

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

→ दूसरा भाग

लाइनिंग: वह दस्तावेज़ीकरण जहाँ यह आवश्यक है प्रकट होता है

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


अलसी की किस्में

लाइनिंग कई प्रकार के स्थिर कोड विश्लेषणों में से एक है जिसका हम इंस्टाग्राम पर उपयोग करते हैं।

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

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

जब हम इंस्टाग्राम पर लाइनिंग के बारे में बात करते हैं, तो हम आम तौर पर एक सार वाक्यविन्यास पेड़ पर आधारित सरल नियमों के साथ काम करते हैं। यह ठीक कुछ इस तरह है कि सर्वर कोड के लिए हमारे स्वयं के linting नियमों को रेखांकित करता है।

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


Python Parse Tree (CST का एक प्रकार) lib2to3 द्वारा उत्पन्न

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

पायथन पार्स ट्री को एक सार वाक्यविन्यास ट्री (एएसटी) में संकलित करता है। इस रूपांतरण के दौरान स्रोत कोड के बारे में कुछ जानकारी खो जाती है। हम "अतिरिक्त वाक्यविन्यास जानकारी" के बारे में बात कर रहे हैं - जैसे कि टिप्पणी, कोष्ठक, अल्पविराम। हालांकि, एएसटी में कोड के शब्दार्थ को बरकरार रखा गया है।


एस्ट्रो मॉड्यूल द्वारा उत्पन्न अजगर सार वाक्यविन्यास वृक्ष

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


एक विशिष्ट LibCST वाक्यविन्यास पेड़ का प्रतिनिधित्व

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

मान लीजिए कि एक निश्चित मॉड्यूल में टाइप आयात के कारण चक्रीय निर्भरता है। if TYPE_CHECKING ब्लॉक में टाइप इंपोर्ट कमांड रखकर पायथन इस समस्या को हल करता है। यह रनटाइम पर कुछ भी आयात करने के खिलाफ सुरक्षा है।

 #    from typing import TYPE_CHECKING from util import helper_fn #    if TYPE_CHECKING:    from circular_dependency import CircularType 

बाद में, किसी ने दूसरे प्रकार के आयात को जोड़ा और दूसरा if कोड को ब्लॉक किया। हालाँकि, ऐसा करने वाले को यह नहीं पता होगा कि इस तरह का तंत्र मॉड्यूल में पहले से मौजूद है।

 #    from typing import TYPE_CHECKING from util import helper_fn #    if TYPE_CHECKING:    from circular_dependency import CircularType if TYPE_CHECKING: #   !    from other_package import OtherType 

लिंटर नियम का उपयोग करके आप इस अतिरेक से छुटकारा पा सकते हैं!

आइए कोड में पाए जाने वाले "सुरक्षात्मक" ब्लॉकों के काउंटर को शुरू करके शुरू करें।

 class OnlyOneTypeCheckingIfBlockLintRule(CstLintRule):    def __init__(self, context: Context) -> None:        super().__init__(context)        self.__type_checking_blocks = 0 

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

 def visit_If(self, node: cst.If) -> None:    if node.test.value == "TYPE_CHECKING":        self.__type_checking_blocks += 1        if self.__type_checking_blocks > 1:            self.context.report(                node,                "More than one 'if TYPE_CHECKING' section!"            ) 

इसी तरह के लाइनिंग नियम LibCST के पेड़ को देखकर और जानकारी इकट्ठा करके काम करते हैं। हमारे लिंटर में, यह विज़िटर पैटर्न का उपयोग करके कार्यान्वित किया जाता है। जैसा कि आपने देखा होगा, नियम visit तरीकों को ओवरराइड करते हैं और नोड प्रकार से जुड़े तरीकों को छोड़ देते हैं। इन "विज़िटर" को एक विशिष्ट क्रम में बुलाया जाता है।

 class MyNewLintRule(CstLintRule):    def visit_Assign(self, node):        ... #      def visit_Name(self, node):        ... #        def leave_Assign(self, name):        ... #      

नोड्स के वंशजों का दौरा करने से पहले यात्रा के तरीकों को बुलाया जाता है। सभी वंशज का दौरा करने के बाद छुट्टी के तरीकों को बुलाया जाता है

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


साझा स्थिति का उपयोग करते हुए एक फ़ाइल, एक "आगंतुक"

Single Visitor वर्ग को हमारे सभी लाइनिंग नियमों की स्थिति और तर्क के बारे में जानकारी होनी चाहिए जो इससे संबंधित नहीं हैं। इसके अलावा, यह हमेशा स्पष्ट नहीं होता है कि कौन सा राज्य किसी विशेष नियम से मेल खाता है। यह दृष्टिकोण खुद को एक ऐसी स्थिति में अच्छी तरह से दिखाता है जहां सचमुच आपके स्वयं के कुछ नियम हैं, लेकिन हमारे पास इनमें से लगभग सौ नियम हैं, जो single-visitor पैटर्न के समर्थन को बहुत जटिल करते हैं।


यह जानना मुश्किल है कि प्रत्येक चेक के साथ राज्य और तर्क क्या जुड़े हैं।

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


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

अपने आप में कुछ इसी तरह लागू करने के बजाय, हम अन्य प्रोग्रामिंग भाषाओं के इकोसिस्टम में इस्तेमाल किए गए लिंटर से प्रेरित थे - जैसे कि जावास्क्रिप्ट से ESLint , और "विज़िटर" (विज़िटर रजिस्ट्री) का एक केंद्रीकृत रजिस्टर बनाया।


"आगंतुकों" का केंद्रीकृत रजिस्टर। हम प्रभावी रूप से यह निर्धारित कर सकते हैं कि लिंटर के प्रत्येक नियम में कौन सा नोड रुचि रखता है, इसमें रुचि रखने वाले नोड्स पर समय की बचत होती है।

जब लिंटर नियम को प्रारंभ किया जाता है, तो नियम विधियों के सभी ओवरराइड रजिस्ट्री में संग्रहीत किए जाते हैं। जब हम पेड़ के चारों ओर जाते हैं, तो हम सभी पंजीकृत "आगंतुकों" को देखते हैं और उन्हें कॉल करते हैं। यदि विधि लागू नहीं है, तो इसका मतलब है कि आपको इसे कॉल करने की आवश्यकता नहीं है।

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

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

 class MyCustomLintRuleTest(CstLintRuleTest):    RULE = MyCustomLintRule       VALID = [        Valid("good_function('this should not generate a report')"),        Valid("foo.bad_function('nor should this')"),    ]       INVALID = [        Invalid("bad_function('but this should')", "IG00"),    ] 

निरंतरता → दूसरा भाग

प्रिय पाठकों! क्या आप लिंटर का उपयोग करते हैं?