घटक आधारित विकास गाइड

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

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


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

यदि आप वेब घटकों के क्षेत्र में अब क्या हो रहा है, को करीब से देखते हैं, तो आप देखेंगे कि CDD विकास को आगे बढ़ाने के लिए एक मानकीकृत दृष्टिकोण बन रहा है।

सामग्री, जिसे हम आज के अनुवाद में प्रकाशित करते हैं, एक घटक-आधारित विकास मार्गदर्शिका है।

उपयोगकर्ता इंटरफ़ेस विकास में सीडीडी

बिट पर काम: घटकों पर बनाना, अलग करना, पुन: उपयोग करना और सहयोग करना

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

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

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

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

एडी उस्मानी ने सीडीडी के उपयोग के कुछ प्रमुख लाभों को रेखांकित किया। उन्होंने उन्हें सिद्धांतों के एक समूह में डिज़ाइन किया जिसे FIRST कहा जाता है।

ये सिद्धांत हैं:

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

सीडीडी उपकरण

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

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

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

▍बिट: व्यक्तिगत और टीम घटकों का विकास

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

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

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

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


समझाया घटकों का उपयोग कर परियोजना का विकास

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

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


सीडीडी में क्लाउड क्षमताएं

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

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

यूआई घटकों का विकास और अनुसंधान: स्टोरीबुक और स्टाइलगाइडिस्ट

स्टोरीबुक और स्टाइलगाइडिस्ट रिएक्ट का उपयोग करके उपयोगकर्ता इंटरफ़ेस तत्वों को जल्दी से विकसित करने के लिए वातावरण हैं। ये दोनों परियोजनाएं घटक विकास को गति देने के लिए महान उपकरण हैं।

कहानियों का संग्रह

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


स्टोरीबुक पर काम करते हैं

स्टोरीबुक आवेदन से अलगाव में डिजाइन घटकों की मदद करता है। यह घटकों की पुन: प्रयोज्य में सुधार करने में मदद करता है और घटकों की परीक्षण क्षमता में सुधार करता है।

स्टोरीबुक का उपयोग करके, आप लाइब्रेरी में संग्रहीत घटकों को देख सकते हैं, और उनके गुणों के साथ ऑनलाइन प्रयोग कर सकते हैं। पृष्ठ को फिर से लोड किए बिना, तुरंत घटक को किए गए परिवर्तन की कल्पना की जाती है। यहाँ StoryBook में बनाए गए घटकों के कुछ उदाहरण दिए गए हैं।

विभिन्न प्लगइन्स हैं जो स्टोरीबुक का उपयोग करके घटकों के विकास को गति दे सकते हैं। यह आपको घटक कोड को बदलने और इसके दृश्य प्रतिनिधित्व के गठन के बीच बीता समय को कम करने की अनुमति देता है। यह ध्यान दिया जाना चाहिए कि StoryBook, React के अलावा, React Native और Vue.js. का भी समर्थन करता है।

रिएक्ट स्टाइलगिडिस्ट

रिएक्ट स्टाइलगाइडिस्ट एक घटक विकास वातावरण है। इस वातावरण में एक विकास सर्वर होता है जो हॉट बूट का समर्थन करता है। इसमें एक इंटरैक्टिव शैली प्रबंधन प्रणाली भी है जो घटकों के propTypes प्रदर्शित propTypes और डेवलपर्स को .md फाइलों के आधार पर घटकों के उपयोग के संपादन योग्य उदाहरण प्रदान करती है।


रिएक्ट स्टाइलगिडिस्ट

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

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

StoryBook और Styleguidist के बीच अंतर

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

सीडीआर पद्धति का उपयोग करते हुए वास्तु निर्णय

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

अवयवों को आवेदन के ढांचे के भीतर दोनों को बनाया जा सकता है (अर्थात, एक ही परियोजना, रिपॉजिटरी में), और एक अलग प्रोजेक्ट (रिपॉजिटरी) के प्रारूप में - एक घटक पुस्तकालय के रूप में।

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

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

एक घटक पुस्तकालय क्यों बनाएं?

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


विभिन्न परियोजनाओं में एक घटक साझा करना

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

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

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

मान लीजिए कि आप एक घटक पुस्तकालय बनाने का निर्णय लेते हैं। यदि हां - तो हम आपको कुछ सुझाव प्रदान करते हैं जो आपकी मदद करेंगे।

गुणवत्ता सीडीडी-उन्मुख पुस्तकालयों के विकास के लिए 7 सिद्धांत

1. मानक। अपनी लाइब्रेरी बनाते समय आप किन विकास मानकों का पालन करते हैं? घटक कहाँ स्थित हैं? परीक्षण कहाँ स्थित हैं? शैलियों के बारे में क्या? आप किस टेक्नोलॉजी स्टैक का उपयोग कर रहे हैं? उदाहरण के लिए - क्या आप टाइपस्क्रिप्ट का उपयोग करने की योजना बनाते हैं? घटकों को कैसे विभाजित किया जाता है? क्या "तालिका" घटक, उदाहरण के लिए, "पंक्तियों" और "कोशिकाओं" से मिलकर बनता है? क्या टैब वाले पैनल में अलग टैब होते हैं (क्या समान प्रश्न अन्य समान संस्थाओं के संबंध में पूछे जा सकते हैं)? मुझे लगता है कि आप पहले से ही इस सिफारिश का मतलब समझ गए थे। मानकों को बनाने की प्रक्रिया में डिजाइनरों को शामिल करना भी बहुत महत्वपूर्ण है। यह सुनिश्चित करेगा कि पुस्तकालय पर्याप्त लचीला है और भविष्य में दिखाई देने वाली डिजाइन आवश्यकताओं को पूरा करेगा।
2. स्टाइल। आप घटकों को स्टाइल करने की योजना कैसे बनाते हैं? क्या आप प्रत्येक घटक के अनुरूप सीएसएस कोड लिंक करेंगे? यदि हां, तो क्या होता है जब एक डिजाइनर को एक अलग अनुप्रयोग के लिए कुछ बदलने की जरूरत होती है जो एक घटक का उपयोग करता है? शायद शैलियों से घटकों के अलगाव को बेहतर बनाने के लिए यह पुस्तकालयों का उपयोग करने के लायक है जो जेएस प्रौद्योगिकी में सीएसएस को लागू करते हैं? शायद यह स्टाइल के लिए कुछ अन्य दृष्टिकोण की तलाश में है? उदाहरण के लिए, बिट का उपयोग करके, आप अलग-अलग घटकों के रूप में विषयों को उजागर कर सकते हैं। ऐसे विषयों को उन घटकों पर लागू किया जा सकता है जो किसी प्रकार के तर्क को लागू करते हैं। यह आपको ऐसे एप्लिकेशन बनाने की अनुमति देता है जिसमें डिज़ाइनर और लॉजिक को ठीक वैसे ही संयोजित किया जाता है जैसा कि डेवलपर को चाहिए होता है। यहां मॉड्युलरिटी के सिद्धांत का उपयोग करके निर्मित प्रणालियों के चरम लचीलेपन का एक उदाहरण है।
3. परीक्षण। आप लाइब्रेरी में शामिल घटकों का परीक्षण कैसे कर रहे हैं? कीट और एंजाइम का उपयोग? घटक परीक्षण उपकरणों के एक अच्छे संयोजन के चयन को सभी जिम्मेदारी के साथ संपर्क किया जाना चाहिए। यह ऐसे उपकरणों को सीडीडी कार्यप्रणाली को लागू करने में आपकी सहायता करने की अनुमति देगा। उपकरण का खराब विकल्प काम में हस्तक्षेप करेगा। इकाई परीक्षण अच्छे हैं। लेकिन उन्हें घटकों के कार्यात्मक एपीआई की जांच करनी चाहिए, न कि उनके कार्यान्वयन का विवरण। एकीकरण और एंड-टू-एंड परीक्षण इकाई परीक्षणों के समान ही महत्वपूर्ण हैं। सीडीडी का उपयोग करने वाली परियोजनाओं में लागू होने पर टीडीडी पद्धति अच्छी तरह से काम करती है।
4. कोड असेंबली प्रक्रिया। कोड को संकलित करने की आवश्यकता है। आप अपने पुस्तकालय के लिए कोड निर्माण प्रक्रिया को कैसे व्यवस्थित करने जा रहे हैं? रिलीज़ को कैसे लागू किया जाएगा? क्या आप आवेदन से कोड को कॉपी करके लाइब्रेरी में पेस्ट करना चाहते हैं (शायद इसे थोड़ा संशोधित कर रहे हैं)? क्या आप प्रत्येक घटक (लर्न) के लिए असेंबली कॉन्फ़िगरेशन को परिभाषित करने जा रहे हैं और इसे प्रकाशित करने से पहले कोड के लिए उपयुक्त तंत्र लागू करते हैं? क्या आप उन सभी, या (व्यक्तिगत) घटकों पर लागू होने वाली निर्माण प्रक्रियाओं को अनुकूलित करने के लिए पहले से ही उल्लेखित बिट का उपयोग करने की योजना बनाते हैं? यदि आप असेंबली प्रक्रिया को बहुत अधिक जटिल करते हैं, तो विकास में संलग्न होना कठिन हो जाएगा, परियोजना की प्रतिरूपकता बिगड़ जाएगी। विकास में भाग लेने के लिए आवश्यक सीखने की अवस्था बहुत खड़ी हो जाएगी।
5. कोड प्रबंधन। पुस्तकालय का मालिक कौन है? काफी बड़े संगठनों में, अक्सर फ्रंट-एंड डेवलपर्स की टीमें होती हैं और कभी-कभी, आर्किटेक्ट। वे "साझा पुस्तकालय" नामक एक उत्पाद बना रहे हैं। अन्य फ्रंट-एंड डेवलपमेंट टीमें समान लाइब्रेरीज़ का उपयोग करके एप्लिकेशन बनाती हैं। इस इंटरैक्शन स्कीम के साथ, ऐसी प्रणाली का उपयोग करना बहुत महत्वपूर्ण है जो आपको आवश्यक घटकों (बिट, स्टोरीबुक) को आसानी से खोजने की अनुमति देता है। अधिक महत्वपूर्ण बात, शायद, वह तंत्र है जिसके द्वारा घटक उपयोगकर्ता घटक सुधार का प्रस्ताव कर सकते हैं। यदि संगठन में ऐसे कोई तंत्र नहीं हैं, तो घटक उपयोगकर्ता टीम लाइब्रेरी के साथ अपने अनुप्रयोगों को जोड़ना नहीं चाहेंगे और अपने पीआर के स्वीकार किए जाने की प्रतीक्षा करेंगे, जो कि वे अच्छी तरह से इंतजार नहीं कर सकते हैं। प्रोग्रामर को कुछ भी करने के लिए मजबूर करने की आवश्यकता नहीं है। स्वस्थ सहयोग स्थापित करना आवश्यक है। यदि आप इसके लिए प्रयास नहीं करते हैं, तो कोई भी पुस्तकालय का उपयोग नहीं करेगा। प्रोग्रामर बस कोड को कॉपी और पेस्ट करेंगे, और कोई भी इसके बारे में कुछ भी नहीं करेगा। इसके अलावा, यह आपकी गलती होगी। यदि आप एक छोटी सी टीम में काम करते हैं, तो स्पष्ट रूप से निर्धारित करें कि कोड का प्रबंधन कौन कर रहा है। यहां तक ​​कि अगर कोई भी हर समय कोड आधार में नहीं है, तो कुछ विशेषज्ञों का चयन करें जो इस कोड का समर्थन करेंगे। बाकी पीआर करेगा - ठीक वैसे ही जैसे यह GitHub पर करता है।
6. घटकों को ढूँढना। यदि प्रोग्रामर को उन घटकों की आवश्यकता नहीं है, जो इन घटकों के काम नहीं कर सकते हैं, तो लाइब्रेरी बहुत लाभ नहीं लाएगी, और यह उनके कोड में उपयोग नहीं कर सकती है। बिट में अंतर्निहित क्षमताएं हैं जो डेवलपर्स को घटकों को खोजने में मदद करती हैं। इस प्लेटफ़ॉर्म (या इसके बजाय) के अलावा, आप स्टोरीबुक या किसी प्रकार के स्वयं के समाधान की क्षमताओं का उपयोग कर सकते हैं। कोडैंडबॉक्स प्लेटफॉर्म घटकों के चयन और उनके लिए प्रलेखन के साथ काम करने से संबंधित मुद्दों को हल करने में कुछ लाभ प्रदान कर सकता है।
7. घटकों पर सहयोग का संगठन। क्या होता है जब एक डेवलपर (शायद किसी अन्य टीम से, या किसी अन्य देश से भी) को आपके पुस्तकालय से एक घटक से संबंधित कुछ बदलने की आवश्यकता होती है? क्या उसे आपके पुस्तकालय के लिए एक पीआर बनाने में गहराई तक जाने की जरूरत है, और, अपनी उंगलियों को पार करते हुए, परिणामों की प्रतीक्षा करें। कई डेवलपर्स के लिए, यह बहुत जटिल है, वे ऐसा नहीं करेंगे भले ही आप किसी तरह उन्हें प्रभावित करने की कोशिश करें। यदि आप एक निश्चित मंच का उपयोग करते हैं जो परियोजनाओं पर सहयोग को सरल करता है तो यह बहुत बेहतर होगा।

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

सीडीडी टीम के लाभ

त्वरित विकास से सीडीडी सिद्धांत लाभ का उपयोग करने वाली टीमें, कोड की पुन: प्रयोज्यता में सुधार, टीडीडी में सुधार और एक सुसंगत डिजाइन सिस्टम इंटरफ़ेस।

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

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

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

Uber, Airbnb, Shopify और अन्य जैसी कंपनियां एक घटक दृष्टिकोण पेश कर रही हैं।

परिणाम

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

प्रिय पाठकों! क्या आप अपनी परियोजनाओं पर काम करते समय सीडीडी पद्धति का उपयोग करते हैं?