🚲 👨🏿‍🚒 ☑️ पहले सामने, और फिर पीछे (किसी दिन) 👩🏿‍🤝‍👨🏼 🙇🏻 😪

इससे पहले कि आप एक नई सुविधा को लागू करना शुरू करें, आपको अपने सिर को काफी तोड़ना होगा।

जटिल कार्यक्षमता के विकास के लिए इंजीनियरों की एक टीम के प्रयासों का एक अच्छा समन्वय आवश्यक है।

और सबसे महत्वपूर्ण बिंदुओं में से एक समांतर कार्यों का मुद्दा है।

क्या बैक-एंड कार्यान्वयन के लिए प्रतीक्षा करने से फ्रंट-लाइन सैनिकों को बचाना संभव है? क्या यूआई के व्यक्तिगत टुकड़ों के विकास को समानांतर करने का एक तरीका है?

इस लेख में वेब डेवलपमेंट में टास्क समानांतरीकरण के विषय पर चर्चा की जाएगी।

समस्या

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

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

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

सवाल स्वतः उठता है: "फ्रंट-लाइन के सैनिक इस समय क्या करेंगे, जबकि एपीआई नहीं है?"।

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

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

चंचल हमारी मदद करने की कोशिश कर रहा है।

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

यह कैसे सुनिश्चित करें कि जब तक कि आवेदन की अन्य परतों के साथ निश्चितता न हो, तब तक मुखौटा के कार्यान्वयन में देरी न हो?

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

कुछ तकनीकी विवरण

इसलिए, मैंने पहले ही संक्षेप में बताया कि हम किस विशेषता को लागू करने जा रहे हैं। कुछ तकनीकी विवरण जोड़ें।

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

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

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

डेटाफ़्लो इस प्रकार देखा जाता है (संदर्भ के लिए):

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

विकास योजना

Mocap UI बनाम प्रोटोटाइप यूआई

आइए तुरंत वायरफ्रेम, मॉकअप, प्रोटोटाइप के बीच अंतर को उजागर करें।

ऊपर की छवि वायरफ्रेम दिखाती है। यह सिर्फ एक ड्राइंग है (संख्या में या कागज पर - यह कोई फर्क नहीं पड़ता)। अन्य दो अवधारणाएँ अधिक जटिल हैं।

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

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

अब बिंदु के करीब ...

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

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

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

हमें git में शाखाओं के निम्नलिखित पदानुक्रम मिलते हैं:

master ---------------------- > └ feature/import-dev ------ >

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

क्योंकि इस समय हमने पहले ही पृष्ठ पर मुख्य ब्लॉकों के लिए घटक बना लिए हैं, फिर आप तुरंत प्रत्येक UI ब्लॉक के लिए अलग-अलग शाखाएँ बना सकते हैं। अंतिम पदानुक्रम इस तरह लग सकता है:

 master ----------------------- > └ feature/import-dev ------- > ├ feature/import-head ---- > ├ feature/import-filter -- > ├ feature/import-table --- > ├ feature/import-pager --- > └ feature/import-footer -- >

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

ऊपर वर्णित दृष्टिकोण से, हम कई यूआई डेवलपर्स के संघर्ष-मुक्त संचालन को सुनिश्चित करते हैं। प्रोजेक्ट पदानुक्रम में प्रत्येक UI टुकड़े की अपनी निर्देशिका होती है। टुकड़ा सूची में मुख्य घटक, इसकी शैलियों का सेट और बाल घटकों का अपना सेट शामिल है। प्रत्येक टुकड़े का अपना राज्य प्रबंधक (MobX, Redux, VueX दलों) भी हो सकता है। शायद टुकड़े के घटक कुछ वैश्विक शैलियों का उपयोग करते हैं। हालांकि, नए पृष्ठ के टुकड़े को विकसित करते समय वैश्विक शैलियों को बदलना प्रतिबंधित है। डिजाइन के सामान्य परमाणु के डिफ़ॉल्ट व्यवहार और शैली को बदलना भी इसके लायक नहीं है।

नोट: "डिज़ाइन परमाणु" का अर्थ है हमारी सेवा के मानक घटकों के सेट से एक तत्व - परमाणु डिजाइन देखें; हमारे मामले में, यह माना जाता है कि परमाणु डिजाइन प्रणाली पहले ही लागू हो चुकी है।

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

लेकिन हम यह कैसे सुनिश्चित करते हैं कि यूआई टुकड़े एक दूसरे के साथ बातचीत कर सकते हैं?

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

इस सेवा को बनाने के लिए, हमें git में एक और शाखा की आवश्यकता है:

 master --------------------------- > └ feature/import-dev ----------- > ├ feature/import-js-service -- > ├ feature/import-head -------- > ├ feature/import-filter ------ > ├ feature/import-table ------- > ├ feature/import-pager ------- > └ feature/import-footer ------ >

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

 $/> git checkout -b feature/import-service $/> git commit . $/> git push origin HEAD $/> git checkout feature/import-dev $/> git merge feature/import-service

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

नकली डेटा

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

अब हमें एक अनुमानित डेटा मॉडल पर निर्णय लेने और इस डेटा को JSON या JS फ़ाइलों के रूप में बनाने की आवश्यकता है (एक या दूसरे के पक्ष में विकल्प आपकी परियोजना में आयात सेटिंग्स पर निर्भर करता है; json-loader कॉन्फ़िगर किया गया है)। हमारा आयात सेवा, साथ ही इसके परीक्षण (हम बाद में उनके बारे में सोचेंगे), इन फाइलों से आयात एक वास्तविक बैकएंड से प्रतिक्रियाओं का अनुकरण करने के लिए आवश्यक डेटा (यह अभी तक लागू नहीं हुआ है)। यह डेटा कहां रखा जाए यह महत्वपूर्ण नहीं है। मुख्य बात यह है कि वे आसानी से खुद को आयात कर सकते हैं और हमारे माइक्रो सर्विस में परीक्षण कर सकते हैं।

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

नोट: नकली डेटा मॉडल के साथ गलती करने से डरो मत; आपका कार्य डेटा अनुबंध का एक मसौदा संस्करण बनाना है, जो तब भी बैकएंड डेवलपर्स के साथ सहमत होगा।

ठेके

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

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

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

इकाई परीक्षण

नोट: मेरे लिए, यूनिट परीक्षणों का मूल्य बहुत कम है। यहाँ मैं डेविड हेंमियर हेंसन @ RailsConf से सहमत हूँ। "यूनिट परीक्षण यह सुनिश्चित करने का एक शानदार तरीका है कि आपका कार्यक्रम वह करता है जो आप कर सकते हैं ... जैसा कि अपेक्षित था।" लेकिन मैं विशेष मामलों को स्वीकार करता हूं जब यूनिट परीक्षणों से बहुत लाभ होता है।

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

 importService ├ importService.js └ importService.test.js

पोस्टफिक्स का विशिष्ट मूल्य आपकी परियोजना में जेएस पैकेज कलेक्टर की सेटिंग्स पर निर्भर करता है।

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

उदाहरण के लिए, यूनिट परीक्षणों के साथ विभिन्न प्रकार के सहायकों को कवर करना अच्छा है, जिसके माध्यम से जेएस घटकों और सेवाओं के बीच तर्क या कुछ एल्गोरिदम के टुकड़े साझा किए जाते हैं। इसके अलावा, ये परीक्षण उपयोगकर्ता डेटा परिवर्तनों के जवाब में MobX, Redux, VueX के घटकों और स्टोर में व्यवहार को कवर कर सकते हैं।

एकीकरण और E2E परीक्षण

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

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

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

इस तरह का परीक्षण कुछ यूआई स्वचालन ढांचे के साथ काम करता है। उदाहरण के लिए, यह सेलेनियम हो सकता है। सेलेनियम वेबड्राइवर के साथ इस तरह के परीक्षण कुछ ब्राउज़र में चलते हैं (आमतौर पर क्रोम "हेडलेस मोड" के साथ)। वे लंबे समय तक काम करते हैं, लेकिन क्यूए विशेषज्ञों पर बोझ को कम करते हैं, जिससे उनके लिए एक धुआं परीक्षण होता है।

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

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

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

मर्ज का सामान्य अनुक्रम निम्नानुसार होगा:

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

CI और परीक्षण स्वचालन

सीएलआई के माध्यम से काम करने वाले उपकरणों का उपयोग करके फ्रंट-एंड टेस्ट लागू किए जाते हैं। Package.json में, विभिन्न प्रकार के परीक्षण चलाने के लिए कमांड लिखे जाते हैं। ये कमांड न केवल स्थानीय वातावरण में डेवलपर्स द्वारा उपयोग किए जाते हैं। उन्हें सीआई (कंटीन्यूअस इंटीग्रेशन) वातावरण में परीक्षण चलाने की भी आवश्यकता है।

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

बैकएंड। ठूंठ नियंत्रक

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

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

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

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

अंत में, सभी जेएस को एक वास्तविक सर्वर के साथ काम करने के लिए स्थानांतरित किया जाना चाहिए।

बैकएंड। नियंत्रकों को अंतिम रूप देना। DAO स्टब्स

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

नोट: हम अभी भी इस बात पर निर्भर नहीं करते हैं कि डेटाबेस में डेटा स्कीम लागू है या नहीं।

बैकएंड। DAO को अंतिम रूप दें। असली डी.बी.

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

नोट: सामान्य तौर पर, डेटाबेस में डेटा योजना के साथ काम करने की बहुत अधिक संभावना के साथ, एक नई सुविधा के लिए बहुत कम होगा; शायद डेटाबेस में परिवर्तन बीएल में सेवाओं के कार्यान्वयन के साथ-साथ किए जाएंगे।

इस चरण के अंत में हमें एक पूर्ण माइक्रोफ़ोन, अल्फा संस्करण मिलता है। इस संस्करण को पहले से ही एक MVP के रूप में मूल्यांकन के लिए आंतरिक उपयोगकर्ताओं (उत्पाद स्वामी, एक उत्पाद प्रौद्योगिकीविद् या किसी और) को दिखाया जा सकता है।

बग्स को ठीक करने, अतिरिक्त चिप्स को लागू करने और अंतिम चमकाने के काम पर एजाइल के मानक पुनरावृत्तियां चलेंगी।

निष्कर्ष

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

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

आशा है आपको यह लेख सहायक लगा होगा।

आपका ध्यान के लिए धन्यवाद!

पहले सामने, और फिर पीछे (किसी दिन)