🧝🏽 ✌🏾 🍒 रनटाइम से पहले जीवन। यैंडेक्स रिपोर्ट ➡️ 🕺🏾 📢

एक बड़ी परियोजना में, एप्लिकेशन फ्रंट-एंड कोड के अंतर से अंतिम उपयोगकर्ता के लिए परिवर्तनों की पहचान करने का कार्य उत्पन्न हो सकता है। Yandex.Market की डेवलपर निकिता सिदोरोव @nickshevr ने बताया कि हमने इस प्रॉब्लम को कैसे प्रॉफ़ेक्टर लाइब्रेरी का उपयोग करके हल किया, Node.js एप्लिकेशन में मॉड्यूल ग्राफ के निर्माण और विश्लेषण के बारे में और लॉन्च होने से पहले कोड में दोष खोजने के बारे में।

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

और इस शपथ ग्रहण के दौरान, मैंने आपके साथ जीवन के बारे में बात करने का फैसला किया, जिसके बारे में हम सभी भाग लेते हैं। ज्यादातर समय से पहले जीवन के बारे में। अब मैं समझाऊंगा कि यह सब क्या होगा।

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

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

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

आज हम पहले भाग के बारे में बात करेंगे। पहले क्या होता है, इसके बारे में, लेकिन वास्तव में परीक्षणों के बारे में नहीं।

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

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

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

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

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

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

आइए एक सामान्य उदाहरण देखें। फ़ाइल ए है। यहाँ, फ़ाइल B से कुछ को इसमें आयात किया गया है, और यह नोड्स के बीच ऐसा संबंध है।

यदि आप आयात को आवश्यकता के साथ प्रतिस्थापित करते हैं तो वही होगा। वास्तव में, यहां सब कुछ इतना सरल नहीं है।

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

एक बार जब हम किसी तरह ग्राफ का वर्णन करते हैं, तो हम इस बात पर सहमत होंगे कि हम इसे कैसे बनाएंगे।

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

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

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

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

यह वास्तव में प्लस और माइनस दोनों है। यह इस तरह के एक डबल एज (दोधारी तलवार) को प्राप्त किया जाता है। तथ्य यह है कि यह ग्राफ विधानसभा के दौरान बनाया गया है। यह एक तरह से अच्छा है, अर्थात्, हम परियोजना को इकट्ठा कर सकते हैं और तुरंत विधानसभा परिणाम का पुन: उपयोग कर सकते हैं। लेकिन क्या होगा अगर हम एक परियोजना को इकट्ठा नहीं करना चाहते हैं, लेकिन सिर्फ इस ग्राफ को प्राप्त करना चाहते हैं?

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

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

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

इसके अलावा, कृपया usedExports और provideExports पर ध्यान दें। हम उनके बारे में थोड़ी देर बाद बात करेंगे। लेकिन ये भी बहुत महत्वपूर्ण चीजें हैं।

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

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

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

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

^{_{स्लाइड से लिंक करें}}

आज हमने डिपेंडेंसी इंजेक्शन के बारे में भी बात की। मैं कुछ ऐसा नहीं था जो प्रेरित था, लेकिन समर्थन में मैंने यहां के एक पुस्तकालय को देखा। इसे inversify JS कहा जाता है। जैसा कि आप देख सकते हैं, यह एक बल्कि कस्टम सिंटैक्स प्रदान करता है: lazyInject, nameProvider, और यहाँ यह है। और, आपको स्वीकार करना चाहिए, यह स्पष्ट नहीं है कि यह किस प्रकार का प्रदाता है, यह वास्तव में यहां किस तरह का मॉड्यूल है। और हमें इसकी आवश्यकता है, और हमें इसे समझना होगा। यही है, फिर से, निर्माण प्रणाली हल नहीं होगी, और हमें इसे स्वयं करना होगा।

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

क्या विचार है? यहाँ, वास्तव में, सीधे हमारा डेटा है। हमने हाल ही में Yandex.Market में अपनी डिज़ाइन प्रणाली लागू की है और विशेष रूप से, इस डिज़ाइन सिस्टम के भाग के रूप में एक घटक लाइब्रेरी को लागू किया है। और यहां आप देख सकते हैं: हम आयात की संख्या, हमारे पुस्तकालय से प्रतिक्रिया घटक, सामान्य घटक पर विचार करते हैं। और आप निर्देशिकाओं में वितरित कर सकते हैं। इस मामले में, हमारे पास इस तरह के एक गैर-मोनो भंडार है, और इसलिए हमारे पास platform.desktop, platform.touch और src है।

जब हम इन नंबरों को देखते हैं तो हम क्या सोच सकते हैं? हम परिकल्पना कर सकते हैं कि स्पर्श कमांड सामान्य घटकों के उपयोग को बढ़ाता नहीं है। इसका मतलब है कि या तो घटक मोबाइल के लिए खराब हैं - खराब तरीके से बनाए गए हैं, या टच कमांड आलसी है। लेकिन क्या वास्तव में ऐसा है?

अगर हम एक लंबी अवधि में, लंबे समय में कटौती करते हैं, तो यह हमें प्रत्येक रिलीज़ के बाद ग्राफ़ का भंडारण करने की अनुमति देता है, तो हम समझेंगे कि, वास्तव में, स्पर्श के लिए सब कुछ ठीक है, इसमें संकेतक बढ़ रहा है। Src के लिए, यह डेस्कटॉप के लिए और भी बेहतर है, यह पता नहीं है।

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

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

चलो परिपत्र निर्भरता के साथ शुरू करते हैं।

यहां सब कुछ काफी सरल प्रतीत होता है। आपके पास पहले से ही एक निर्देशित ग्राफ है, आपको बस वहां एक लूप खोजने की आवश्यकता है। मैं बताऊंगा कि मैं इस बारे में क्यों बात कर रहा हूं। तथ्य यह है कि इससे पहले कि मैंने लिखा, मूल रूप से, Node.js पर सर्वर पक्ष, और हमने सिद्धांत रूप में, किसी भी वेबपैक / बैबेल का उपयोग नहीं किया, कुछ भी नहीं। यही है, वे के रूप में शुरू किया है। और आवश्यकता थी। कौन याद करता है कि आयात आवश्यकता से कैसे भिन्न है? सब सही है। यदि आपने कोड खराब तरीके से लिखा था, लेकिन मैंने वास्तव में किया था, तो आप अपने सर्वर पर पता लगा सकते हैं कि आपका मॉड्यूल किसी प्रकार के चक्रीय निर्भरता में है, जब कुछ अनुरोध उपयोगकर्ताओं से आते हैं, या कोई अन्य घटना काम करेगी। यह एक बल्कि वैश्विक समस्या है। जब तक रनटाइम समझ नहीं आता। यानी आयात ज्यादा बेहतर है, ऐसी कोई समस्या नहीं होगी।

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

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

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

लेकिन एक और तरीका है। यदि आपने ग्राफ़ एकत्र नहीं किया है, और आपके पास बस एक बिल्ड सिस्टम है, तो यह इसे करने का सबसे सस्ता तरीका कैसे है? चलो विधानसभा के दौरान विधानसभा में आने वाली सभी फाइलों को चिह्नित करें। उन्हें टैग करें और कई बनाएं। उसके बाद, हमें उन सभी फ़ाइलों को प्राप्त करना चाहिए जो आपके पास प्रोजेक्ट में हैं, और बस उन्हें घटाएं। यह एक बहुत ही सरल ऑपरेशन है।

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

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

आप उपयोग कर सकते हैं, यहां तक कि लिंक भी है। और ताकि आप यह न सोचें कि मैं आपको धोखा दे रहा हूं - हम आज फ्रैंक हैं - मैंने वास्तव में समीक्षाओं को देखा। मुझे लगता है कि आप उन पर विश्वास कर सकते हैं।

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

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

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

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

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

आइए एक उदाहरण देखें कि कैसे भिन्न कार्य करता है। यहां हमारे पास एक निश्चित निर्देशिका, Pages.desktop / * है। इसमें केवल पृष्ठों की एक सूची है। और पृष्ठों को कई फाइलों द्वारा भी वर्णित किया गया है। नियंत्रक पृष्ठ का सर्वर पक्ष है। दृश्य किसी प्रकार का प्रतिक्रिया भाग है। और deps, यह एक और बिल्ड सिस्टम से है। हमारे पास न केवल वेबपैक है, बल्कि ईएनबी भी है।

और मैंने परियोजना में कुछ बदलाव किए, एक खाली फाइल के लिए, जिसकी संरचना आपने देखी। यह वही है जो मुझे अलग करता है। मैंने अभी इसे शुरू किया है, diffector एक कमांड लाइन एप्लीकेशन है। मैंने इसे लॉन्च किया, वह बताता है कि मैंने एक पृष्ठ बदल दिया है, जिसे BindBonusPage कहा जाता है।

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

लेकिन देखते हैं कि अगर हम कुछ और बदलते हैं तो क्या होता है।

मैंने कुछ और बदल दिया। और डिफेक्टर ने मुझे बताया कि मैंने नौ पेज बदले हैं। और इससे मुझे कोई खुशी नहीं होगी, जैसे कि वह वास्तव में मेरी मदद नहीं करेगा।