समय का भारी बोझ। समय के साथ काम करने में सामान्य गलतियों पर Yandex की रिपोर्ट

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



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

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



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

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

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



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



आप, या आपके बॉस, एक के बजाय दो दिनों के लिए रिपोर्ट प्राप्त करें। तकनीकी प्रबंधक और प्रबंधक आते हैं, शिकायत करते हैं और विनम्रता से छह महीने में दूसरी टीम में जाने की पेशकश करते हैं।



लेकिन तब आप नए ज्ञान से समृद्ध होते हैं। आप समझते हैं कि समय अभी भी खड़ा नहीं है। यही है, Date.now () को दो बार कॉल करना या नई तिथि प्राप्त करना (), आप समान मान प्राप्त करने की उम्मीद नहीं कर रहे हैं। यह कभी-कभी समान हो सकता है, लेकिन यह समान नहीं हो सकता है। तदनुसार, यदि आपके पास एक विधि, तर्क का कोई एक टुकड़ा है, तो सबसे अधिक संभावना है कि Date.now () या नई तिथि प्राप्त करने के लिए केवल एक ही कॉल होनी चाहिए (वर्तमान समय में बिंदु)।

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



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

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



आप बहुमूल्य ज्ञान प्राप्त करते हैं, जो वास्तव में, आपके द्वारा उपयोग की जाने वाली तारीख, समय प्राप्त करने के तरीके - वे सिर्फ यह दिखाते हैं कि आपके ऑपरेटिंग सिस्टम की घड़ी में आपके पास क्या है। न ही वे समान परिवर्तन की गारंटी देते हैं। यही है, आपके वास्तविक समय के दूसरे में, आपका Date.now () दोनों एक सेकंड के लिए कूद सकता है, और थोड़ा अधिक - थोड़ा कम। और सिद्धांत रूप में, वे आम तौर पर परिवर्तन की एकरसता की गारंटी नहीं देते हैं। अर्थात्, इस उदाहरण में, यह अचानक घट सकता है, Date.now () का मान अचानक घट सकता है।

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

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



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

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

और अगर आपको कोई समस्या लॉगिंग क्रिया है, तो आप बस एक वेक्टर के समय लॉग कर सकते हैं। आप, यह पता चला है, एक अनुरोध को संसाधित करने में शामिल एन सिस्टम से एन बार लॉग करता है। या आप बस अमूर्त काउंटर पर जाते हैं, जो बस बढ़ता है: 1, 2, 3, 4, 5, यह बस इस ऑपरेशन के साथ प्रत्येक मशीन पर समान रूप से टिक करता है। और आप इन काउंटरों को विभिन्न मशीनों पर अपने किसी भी अनुरोध को संसाधित करने के लिए, और कब, क्या होता है, किस क्रम में के बारे में कुछ समझ प्राप्त करने के लिए लिंक करने के लिए ऐसे काउंटर लिखते हैं।

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

पर्याप्त समय। दूसरा भाग अधिक अनिश्चित है।



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

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



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



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



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

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

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

उदाहरण के लिए, यदि आपके पास स्टोर है, यदि आप जल्दी से सामान को टोकरी में खींचते हैं। कुछ त्वरित, तेज उपयोगकर्ता ने दस सामान खींचे, और फिर वह देखता है कि उसकी कीमत कैसे झपकी ले रही है और, अपेक्षाकृत बोल, 100 रूबल, 10 रूबल, 50 रूबल, 75 रूबल, और एक रूबल पर रुक जाता है। वह आप पर विश्वास नहीं करता है, वह सोचता है कि आप खराब लिखते हैं, आप उसे धोखा देना चाहते हैं, और बिना कुछ खरीदे अपना स्टोर छोड़ देते हैं।

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



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

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



तदनुसार, समस्या लंबे समय से मौजूद है, और समाधान भी पहले से मौजूद है। उदाहरण के लिए, RxJS लाइब्रेरी में। यह सीधे दस्तावेज़ीकरण से एक उदाहरण है, सही हैलो दुनिया, कैसे सही स्वत: पूर्ण लिखने के लिए। बॉक्स के ठीक बाहर पुराने गलत अनुरोधों के जवाब के लिए ऐसी अवहेलना है।



यदि आप Redux और Redux-Saga पर लिखते हैं, तो यह भी, सामान्य तौर पर, और सब कुछ प्रलेखन में भी लिखा गया है। लेकिन वहां इसे गहराई से दफन किया गया है, और यह स्पष्ट रूप से नहीं कहा गया है कि यह एक ऐसी बग है और हम इसे उसी तरह ठीक करते हैं। बस एक विवरण है।

चूंकि हम रिएक्ट में चले गए हैं, इसलिए हम इसके करीब जाएंगे।



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

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

लेकिन अगर आप ध्यान से देखें कि इस कोड में क्या होता है, तो हम तीन सेकंड के बाद अपने घटक की स्थिति को समय में बदल देते हैं। इन तीन सेकंड में कुछ भी हो सकता है। उपयोगकर्ता को शामिल करना इस कार्ड को लंबे समय तक बंद कर सकता है, और आपका घटक अनमाउंट होगा, इसकी स्थिति को साफ करें।



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



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



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

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

तीसरा भाग दूसरे के विपरीत है। वह, इसके विपरीत, सिंक्रनाइज़ेशन के बारे में है।



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

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



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



पूर्णता के लिए, प्रॉमिस एपीआई में हमारे पास और क्या है? यहां Promise.all () है, जो समानांतर में सभी अनुरोधों को चलाता है, और निष्पादन का इंतजार करता है। वहाँ Promise.race () है, जो उनमें से पहले के सफल होने की प्रतीक्षा कर रहा है। और, सामान्य तौर पर, मानक एपीआई में और कुछ नहीं है।



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



एक अन्य विकल्प ब्लूबर्ड लाइब्रेरी है। वहाँ है, जैसा कि वे इसे कहते हैं, सही Promise.any ()। , , : N , N - , , . , , . .

Promise.race(), , promise , , , . . Promise.any() — reject. . reject , resolve , , . . promise — , .

, map, reduce, each, filter . API , Async JS, . promise . , , , promise. .

promise? , async/await.



. . . , «» . , webdriver. , , - , . . . webdriver.

, await. . , - . await, — , , ! .



— Promise.all(). , await.



: await , then . , .

, . : await, , — , .

, , :

• Promise Mozilla Developer Network.
• Async GitHub.
• Bluebird .
• RxJS 4 , RxJS 5+ .
• Monotonic Clocks in Windows and POSIX — , Windows POSIX- .
• , ntpd , , .

, -, :

• , - NTP daemon Hadoop.
• Cloudflare DNS , - , - .
• «» . . , , .

? , — Lodash, RxJS . . , . , - . . — , , . .