नमस्कार दोस्तों। पाठ्यक्रम के शुभारंभ की प्रत्याशा में , परंपरागत रूप से आपके साथ उपयोगी सामग्री का अनुवाद साझा करते हैं।
सॉफ्टवेयर अधिक से अधिक जटिल होते हुए, अधिक से अधिक रोजमर्रा के कार्यों को हल करता है। जैसा कि मार्क एंड्रेसन ने एक बार कहा था, यह दुनिया को खा जाता है।
नतीजतन, जिस तरह से अनुप्रयोगों को विकसित और वितरित किया जाता है, पिछले कुछ वर्षों में नाटकीय रूप से बदल गया है। ये विवर्तनिक पैमाने के बदलाव थे, जिसके परिणामस्वरूप सिद्धांतों का एक समूह बना। ये सिद्धांत टीम के निर्माण, डिजाइन, विकास और आपके एप्लिकेशन को अंतिम उपयोगकर्ताओं तक पहुंचाने में मददगार साबित हुए हैं।
सिद्धांतों को निम्नानुसार संक्षेपित किया जा सकता है: एप्लिकेशन छोटा, वेब-आधारित होना चाहिए, और एक डेवलपर-केंद्रित आर्किटेक्चर होना चाहिए. इन तीन सिद्धांतों को ध्यान में रखते हुए, आप एक मजबूत, एंड-टू-एंड एप्लिकेशन बना सकते हैं जिसे अंतिम उपयोगकर्ता को जल्दी और सुरक्षित रूप से डिलीवर किया जा सकता है, और आसानी से स्केलेबल और एक्स्टेंसिबल है।
प्रस्तावित सिद्धांतों में से प्रत्येक के कई पहलू हैं जिन पर हम यह दिखाने के लिए चर्चा करेंगे कि कैसे प्रत्येक सिद्धांत अंतिम लक्ष्य में योगदान देता है, जो विश्वसनीय अनुप्रयोगों का तेजी से वितरण है जिसे बनाए रखना और उपयोग करना आसान है। हम सिद्धांतों को उनके विपरीत के संबंध में देखेंगे ताकि यह स्पष्ट किया जा सके कि इसका क्या अर्थ है, कहते हैं, "सुनिश्चित करें कि आप उपयोग करते हैं लघुता सिद्धांत'.
हम आशा करते हैं कि यह लेख आपको आधुनिक अनुप्रयोगों के निर्माण के लिए प्रस्तावित सिद्धांतों का उपयोग करने के लिए प्रोत्साहित करेगा, जो एक सतत बढ़ती प्रौद्योगिकी ढेर के संदर्भ में डिजाइन के लिए एक एकीकृत दृष्टिकोण प्रदान करेगा।
इन सिद्धांतों को लागू करके, आप स्वयं को सॉफ़्टवेयर विकास में नवीनतम रुझानों का लाभ उठाते हुए पाएंगे, जिनमें शामिल हैं: अनुप्रयोगों के विकास और वितरण के लिए, कंटेनरों का उपयोग (उदाहरण के लिए, ) और कंटेनर ऑर्केस्ट्रेशन फ्रेमवर्क (उदाहरण के लिए, ), माइक्रोसर्विसेज का उपयोग (माइक्रोसर्विस आर्किटेक्चर सहित и माइक्रोसेवा अनुप्रयोगों के लिए।
एक आधुनिक अनुप्रयोग क्या है?
आधुनिक अनुप्रयोग? आधुनिक ढेर? "आधुनिक" का वास्तव में क्या अर्थ है?
अधिकांश डेवलपर्स के पास केवल एक सामान्य विचार है कि आधुनिक एप्लिकेशन में क्या शामिल है, इसलिए इस अवधारणा को स्पष्ट रूप से परिभाषित करना आवश्यक है।
एक आधुनिक ऐप कई क्लाइंट्स को सपोर्ट करता है, चाहे वह रिएक्ट जावास्क्रिप्ट लाइब्रेरी यूजर इंटरफेस हो, एंड्रॉइड या आईओएस मोबाइल ऐप हो या कोई ऐप जो किसी अन्य एपीआई से जुड़ता हो। एक आधुनिक एप्लिकेशन का तात्पर्य ग्राहकों की अनिश्चित संख्या से है, जिसके लिए यह डेटा या सेवाएं प्रदान करता है।
एक आधुनिक एप्लिकेशन अनुरोधित डेटा और सेवाओं तक पहुंचने के लिए एक एपीआई प्रदान करता है। एपीआई अपरिवर्तनीय और स्थिर होना चाहिए, और विशेष रूप से किसी विशिष्ट ग्राहक से विशिष्ट अनुरोध के लिए नहीं लिखा जाना चाहिए। एपीआई HTTP (एस) पर उपलब्ध है और जीयूआई या सीएलआई में उपलब्ध सभी कार्यक्षमताओं तक पहुंच प्रदान करता है।
डेटा JSON जैसे सामान्य रूप से स्वीकृत, इंटरऑपरेबल प्रारूप में उपलब्ध होना चाहिए। एक एपीआई स्वच्छ, संगठित तरीके से वस्तुओं और सेवाओं को उजागर करता है, जैसे कि रेस्टफुल एपीआई या ग्राफकॉल एक अच्छा इंटरफ़ेस प्रदान करते हैं।
आधुनिक अनुप्रयोग आधुनिक स्टैक पर बनाए गए हैं, और आधुनिक स्टैक वह स्टैक है जो क्रमशः ऐसे अनुप्रयोगों का समर्थन करता है। यह स्टैक एक डेवलपर को आसानी से एक HTTP इंटरफ़ेस और स्पष्ट एपीआई समापन बिंदुओं के साथ एक एप्लिकेशन बनाने की अनुमति देता है। चुना गया दृष्टिकोण आपके एप्लिकेशन को JSON प्रारूप में आसानी से डेटा प्राप्त करने और भेजने की अनुमति देगा। दूसरे शब्दों में, आधुनिक स्टैक ट्वेल्व-फैक्टर एप्लिकेशन के तत्वों से मेल खाता है .
इस प्रकार के स्टैक के लोकप्रिय संस्करण आधारित हैं , , , , и . माइक्रोसर्विस आर्किटेक्चर उल्लिखित भाषाओं में से प्रत्येक में लागू आधुनिक स्टैक का एक उदाहरण प्रस्तुत करता है।
कृपया ध्यान दें कि हम विशेष रूप से माइक्रोसर्विस दृष्टिकोण की वकालत नहीं कर रहे हैं। आप में से कई मोनोलिथ्स के साथ काम कर रहे हैं जिन्हें विकसित करने की आवश्यकता है, जबकि अन्य SOA अनुप्रयोगों के साथ काम कर रहे हैं जो विस्तार कर रहे हैं और माइक्रोसर्विस एप्लिकेशन बनने के लिए विकसित हो रहे हैं। अभी भी अन्य सर्वर रहित अनुप्रयोगों की ओर बढ़ रहे हैं, और कुछ उपरोक्त संयोजनों को लागू कर रहे हैं। लेख में उल्लिखित सिद्धांत इनमें से प्रत्येक प्रणाली पर केवल कुछ मामूली संशोधनों के साथ लागू होते हैं।
सिद्धांतों
अब जबकि हमारे पास आधुनिक एप्लिकेशन और आधुनिक स्टैक के बारे में एक सामान्य समझ है, तो यह आर्किटेक्चर और विकास सिद्धांतों में गोता लगाने का समय है जो आधुनिक एप्लिकेशन को विकसित करने, कार्यान्वित करने और बनाए रखने में आपकी अच्छी सेवा करेंगे।
सिद्धांतों में से एक "छोटे अनुप्रयोग बनाएं" जैसा लगता है, चलो इसे कहते हैं लघुता सिद्धांत. अविश्वसनीय रूप से जटिल अनुप्रयोग हैं जो कई चलती भागों से बने होते हैं। बदले में, छोटे, असतत घटकों से एक एप्लिकेशन का निर्माण करना इसे समग्र रूप से डिजाइन करना, बनाए रखना और इसके साथ काम करना आसान बनाता है। (ध्यान दें कि हमने कहा "सरलीकृत करता है" न कि "सरल बनाता है")।
दूसरा सिद्धांत यह है कि हम विकासकर्ता की उत्पादकता को उनके द्वारा विकसित की जा रही सुविधाओं पर ध्यान केंद्रित करने में मदद करके बढ़ा सकते हैं, जबकि कार्यान्वयन के दौरान उन्हें बुनियादी ढांचे और सीआई/सीडी चिंताओं से मुक्त कर सकते हैं। तो, संक्षेप में, हमारा दृष्टिकोण डेवलपर्स पर केंद्रित है.
अंत में, आपके एप्लिकेशन के बारे में सब कुछ नेटवर्क से जुड़ा होना चाहिए। पिछले 20 वर्षों में, हमने नेटवर्क से जुड़े भविष्य की दिशा में काफी प्रगति की है क्योंकि नेटवर्क तेज हो गए हैं और एप्लिकेशन अधिक जटिल हो गए हैं। जैसा कि हमने देखा है, एक आधुनिक एप्लिकेशन का उपयोग कई अलग-अलग ग्राहकों द्वारा नेटवर्क पर किया जाना चाहिए। नेटवर्क सोच को आर्किटेक्चर पर लागू करने के महत्वपूर्ण लाभ हैं जो अच्छी तरह से चलते हैं लघुता सिद्धांत और दृष्टिकोण की अवधारणा, डेवलपर उन्मुख.
यदि आप किसी एप्लिकेशन को डिजाइन और कार्यान्वित करते समय इन सिद्धांतों को ध्यान में रखते हैं, तो आपको अपने उत्पाद के विकास और वितरण में एक निर्विवाद लाभ होगा।
आइए इन तीन सिद्धांतों को अधिक विस्तार से देखें।
लघुता सिद्धांत
मानव मस्तिष्क के लिए एक ही समय में बड़ी मात्रा में जानकारी प्राप्त करना कठिन होता है। मनोविज्ञान में, संज्ञानात्मक भार शब्द स्मृति में जानकारी बनाए रखने के लिए आवश्यक मानसिक प्रयासों की कुल मात्रा को संदर्भित करता है। डेवलपर्स पर संज्ञानात्मक भार को कम करना एक प्राथमिकता है क्योंकि यह उन्हें संपूर्ण एप्लिकेशन के वर्तमान जटिल मॉडल और उनके सिर में विकसित की जा रही सुविधाओं को रखने के बजाय समस्या को हल करने पर ध्यान केंद्रित करने की अनुमति देता है।
अनुप्रयोग निम्न कारणों से विघटित होते हैं:
- डेवलपर्स पर कम संज्ञानात्मक भार;
- परीक्षण का त्वरण और सरलीकरण;
- आवेदन में परिवर्तनों का तेजी से वितरण।
डेवलपर्स पर संज्ञानात्मक भार को कम करने के कई तरीके हैं, और यहीं पर लघुता का सिद्धांत चलन में आता है।
तो यहाँ संज्ञानात्मक भार को कम करने के तीन तरीके हैं:
- एक नई सुविधा विकसित करते समय उनके द्वारा विचार की जाने वाली समय सीमा को कम करें - समय सीमा जितनी कम होगी, संज्ञानात्मक भार उतना ही कम होगा।
- कोड की मात्रा कम करें जिस पर एक बार काम किया जाता है - कम कोड - कम भार।
- किसी एप्लिकेशन में वृद्धिशील परिवर्तन करने की प्रक्रिया को सरल बनाएं।
विकास की समय सीमा को कम करना
आइए उन दिनों में वापस जाएं जब कार्यप्रणाली waterfall विकास प्रक्रिया के लिए मानक था, और किसी एप्लिकेशन को विकसित करने या अद्यतन करने के लिए छह महीने से दो साल की समय सीमा आम बात थी। विशिष्ट रूप से, इंजीनियर पहले प्रासंगिक दस्तावेज़ जैसे उत्पाद आवश्यकताएँ (PRD), सिस्टम संदर्भ दस्तावेज़ (SRD), आर्किटेक्चर ब्लूप्रिंट पढ़ते हैं, और इन सभी चीज़ों को एक साथ एक संज्ञानात्मक मॉडल में संयोजित करना शुरू करते हैं, जिसके अनुसार उन्होंने कोडिंग की। आवश्यकताओं के रूप में और, परिणामस्वरूप, वास्तुकला बदल गई, पूरी टीम को संज्ञानात्मक मॉडल के अपडेट के बारे में सूचित करने के लिए एक गंभीर प्रयास करना पड़ा। इस तरह का दृष्टिकोण, कम से कम, काम को पंगु बना सकता है।
अनुप्रयोग विकास प्रक्रिया में सबसे बड़ा परिवर्तन फुर्तीली पद्धति का परिचय था। कार्यप्रणाली की मुख्य विशेषताओं में से एक agile पुनरावर्ती विकास है। बदले में, इससे इंजीनियरों पर संज्ञानात्मक भार में कमी आती है। एक लंबे चक्र में एप्लिकेशन को लागू करने के लिए विकास दल की आवश्यकता के बजाय, agile दृष्टिकोण आपको कम मात्रा में कोड पर ध्यान केंद्रित करने की अनुमति देता है जिसे प्रतिक्रिया प्राप्त करते समय जल्दी से परीक्षण और तैनात किया जा सकता है। ऐप का संज्ञानात्मक भार छह महीने से दो साल की समय सीमा में स्थानांतरित हो गया है, जिसमें दो सप्ताह के ऐड या फीचर परिवर्तन के लिए बड़ी मात्रा में चश्मा एक बड़े ऐप की अधिक धुंधली समझ को लक्षित करता है।
बड़े पैमाने पर एप्लिकेशन से विशिष्ट छोटी विशेषताओं पर ध्यान केंद्रित करना, जो दो सप्ताह के स्प्रिंट में पूरा किया जा सकता है, अगले स्प्रिंट को ध्यान में रखते हुए एक से अधिक सुविधाओं के साथ, एक महत्वपूर्ण बदलाव है। इसने हमें संज्ञानात्मक भार को कम करते हुए विकास उत्पादकता बढ़ाने की अनुमति दी, जिसमें लगातार उतार-चढ़ाव आया।
कार्यप्रणाली में agile अंतिम आवेदन मूल अवधारणा का थोड़ा संशोधित संस्करण होने की उम्मीद है, इसलिए विकास का अंतिम बिंदु अनिवार्य रूप से अस्पष्ट है। केवल प्रत्येक विशिष्ट स्प्रिंट के परिणाम स्पष्ट और सटीक हो सकते हैं।
छोटे कोडबेस
संज्ञानात्मक भार को कम करने में अगला कदम कोड आधार को कम करना है। एक नियम के रूप में, आधुनिक अनुप्रयोग बड़े पैमाने पर हैं - एक मजबूत, उद्यम अनुप्रयोग में हजारों फाइलें और कोड की सैकड़ों हजारों लाइनें शामिल हो सकती हैं। फ़ाइलों को कैसे व्यवस्थित किया जाता है, इस पर निर्भर करते हुए, कोड और फ़ाइलों के बीच लिंक और निर्भरता स्पष्ट हो सकती है, या इसके विपरीत। यहां तक कि डिबगिंग कोड निष्पादन भी समस्याग्रस्त हो सकता है, उपयोग किए गए पुस्तकालयों के आधार पर और डीबगिंग टूल पुस्तकालयों/पैकेजों/मॉड्यूल और कस्टम कोड के बीच कितनी अच्छी तरह अंतर करते हैं।
किसी एप्लिकेशन के कोड के कार्यशील मानसिक मॉडल का निर्माण करने में काफी समय लग सकता है, और एक बार फिर डेवलपर पर एक बड़ा संज्ञानात्मक बोझ डाल सकता है। यह मोनोलिथिक कोड बेस के लिए विशेष रूप से सच है, जहां बड़ी मात्रा में कोड होता है, जिसके कार्यात्मक घटकों के बीच की बातचीत स्पष्ट रूप से परिभाषित नहीं होती है, और ध्यान देने वाली वस्तुओं का पृथक्करण अक्सर धुंधला होता है क्योंकि कार्यात्मक सीमाओं का सम्मान नहीं किया जाता है।
इंजीनियरों पर संज्ञानात्मक भार को कम करने के प्रभावी तरीकों में से एक माइक्रोसर्विस आर्किटेक्चर में जाना है। एक माइक्रोसर्विस दृष्टिकोण में, प्रत्येक सेवा सुविधाओं के एक सेट पर केंद्रित होती है; जबकि सेवा का अर्थ आमतौर पर परिभाषित और समझने योग्य होता है। एक सेवा की सीमाएँ भी स्पष्ट हैं - याद रखें कि एक सेवा के साथ संचार एक एपीआई के माध्यम से किया जाता है, इसलिए एक सेवा द्वारा उत्पन्न डेटा आसानी से दूसरे को भेजा जा सकता है।
अन्य सेवाओं के साथ सहभागिता आमतौर पर कुछ उपयोगकर्ता सेवाओं और कुछ प्रदाता सेवाओं तक सीमित होती है जो सरल और साफ एपीआई कॉल का उपयोग करती हैं, जैसे कि REST का उपयोग करना। इसका मतलब है कि इंजीनियर पर संज्ञानात्मक भार गंभीर रूप से कम हो गया है। सबसे बड़ी चुनौती सर्विस इंटरेक्शन मॉडल को समझना और विभिन्न सेवाओं में लेन-देन जैसी चीजें कैसे होती हैं, यह समझना है। नतीजतन, माइक्रोसर्विसेज का उपयोग कोड की मात्रा को कम करके, स्पष्ट सेवा सीमाओं को परिभाषित करके और उपयोगकर्ताओं और प्रदाताओं के बीच संबंधों की समझ प्रदान करके संज्ञानात्मक भार को कम करता है।
छोटे वृद्धिशील परिवर्तन
सिद्धांत का अंतिम तत्व लघुता परिवर्तन प्रबंधन है। डेवलपर्स के लिए कोड बेस (यहां तक कि शायद उनका अपना, पुराना कोड भी) देखने के लिए यह एक विशेष प्रलोभन है, "यह बकवास है, हमें इसे फिर से लिखने की जरूरत है।" कई बार यह सही फैसला होता है और कई बार नहीं। यह वैश्विक मॉडल परिवर्तन का बोझ विकास टीम पर डालता है, जो बदले में बड़े पैमाने पर संज्ञानात्मक भार की ओर जाता है। इंजीनियरों के लिए यह बेहतर है कि वे स्प्रिंट के दौरान किए जा सकने वाले परिवर्तनों पर ध्यान केंद्रित करें, ताकि वे धीरे-धीरे ही सही समय पर आवश्यक कार्यक्षमता को रोल आउट कर सकें। अंतिम उत्पाद पूर्व नियोजित उत्पाद जैसा होना चाहिए, लेकिन ग्राहक की आवश्यकताओं के अनुरूप कुछ संशोधनों और परीक्षण के साथ।
कोड के बड़े हिस्से को फिर से लिखते समय, कभी-कभी बदलाव को जल्दी से वितरित करना संभव नहीं होता है क्योंकि अन्य सिस्टम निर्भरताएँ खेल में आ जाती हैं। परिवर्तनों के प्रवाह को नियंत्रित करने के लिए, आप सुविधा छिपाने का उपयोग कर सकते हैं। सिद्धांत रूप में, इसका मतलब है कि कार्यक्षमता उत्पादन में है, लेकिन यह पर्यावरण चर सेटिंग्स (env-var) या कुछ अन्य कॉन्फ़िगरेशन तंत्र का उपयोग करके उपलब्ध नहीं है। यदि कोड ने सभी गुणवत्ता नियंत्रण प्रक्रियाओं को पारित कर दिया है, तो यह अव्यक्त अवस्था में उत्पादन में समाप्त हो सकता है। हालाँकि, यह रणनीति तभी काम करती है जब सुविधा अंततः सक्षम हो। अन्यथा, यह केवल कोड को अव्यवस्थित करेगा और एक संज्ञानात्मक भार जोड़ देगा जिससे डेवलपर को उत्पादक होने के लिए निपटना होगा। परिवर्तन प्रबंधन और वृद्धिशील परिवर्तन स्वयं डेवलपर्स के संज्ञानात्मक भार को एक किफायती स्तर पर रखने में मदद करते हैं।
अतिरिक्त कार्यक्षमता के सरल परिचय से भी इंजीनियरों को कई कठिनाइयों को दूर करना पड़ता है। प्रबंधन की ओर से टीम पर अनावश्यक बोझ को कम करना विवेकपूर्ण होगा ताकि यह प्रमुख कार्यात्मक तत्वों पर ध्यान केंद्रित कर सके। आप अपनी विकास टीम की मदद करने के लिए तीन चीज़ें कर सकते हैं:
- पद्धति का प्रयोग करें
agileउस समय सीमा को सीमित करने के लिए जिसमें टीम को प्रमुख विशेषताओं पर ध्यान केंद्रित करना चाहिए। - अपने एप्लिकेशन को कई माइक्रोसर्विसेज के रूप में लागू करें। यह उन विशेषताओं की संख्या को सीमित करेगा जिन्हें लागू किया जा सकता है और उन सीमाओं को सुदृढ़ करेगा जो काम पर संज्ञानात्मक भार रखती हैं।
- बड़े और बोझल से अधिक वृद्धिशील परिवर्तनों को प्राथमिकता दें, कोड के छोटे टुकड़े बदलें। परिवर्तनों को लागू करने के लिए सुविधा छिपाने का उपयोग करें भले ही वे उन्हें जोड़ने के तुरंत बाद दिखाई न दें।
यदि आप अपने काम में छोटेपन के सिद्धांत को लागू करते हैं, तो आपकी टीम अधिक खुश होगी, आवश्यक सुविधाओं को लागू करने पर बेहतर ध्यान केंद्रित करेगी, और गुणात्मक परिवर्तनों को तेज़ी से लागू करने की अधिक संभावना होगी। लेकिन इसका मतलब यह नहीं है कि काम अधिक जटिल नहीं हो सकता है, कभी-कभी, इसके विपरीत, नई कार्यक्षमता की शुरूआत के लिए कई सेवाओं के संशोधन की आवश्यकता होती है, और यह प्रक्रिया एक अखंड वास्तुकला में समान से अधिक कठिन हो सकती है। किसी भी मामले में, लघुता के दृष्टिकोण को अपनाने के लाभ इसके लायक हैं।
पहले भाग का अंत।
जल्द ही हम अनुवाद का दूसरा भाग प्रकाशित करेंगे, और अब हम आपकी टिप्पणियों की प्रतीक्षा कर रहे हैं और आपको इसके लिए आमंत्रित करते हैं , जो आज 20.00 बजे होगा।
स्रोत: www.habr.com