सामान्य घटकों के पुस्तकालय पर काम कैसे व्यवस्थित करें

यदि आपकी कंपनी एक ही शैली में कई उत्पाद बनाती है, तो एक दिन आप एक आम कोड के साथ एक पुस्तकालय बनाने के विचार के साथ आएंगे। उदाहरण के लिए, UI घटक, एक प्राधिकरण सेवा, या तृतीय-पक्ष API के साथ काम करने के लिए। आप सोच रहे होंगे: इस कोड का समर्थन किसे करना चाहिए? उपयोगकर्ताओं को परिवर्तन कैसे संवाद करें? आखिरकार, आप उन्हें अपने पुस्तकालय का उपयोग करने के लिए कैसे प्राप्त करेंगे?

2015 से, मैं व्यवसाय सेवा विभाग में टिंकॉफ़ में काम कर रहा हूं। इस समय के दौरान, हमारी टीम 3 से 60+ डेवलपर्स तक बढ़ गई है, और टिंकॉफ बिजनेस पारिस्थितिकी तंत्र 3 से 50 वेब अनुप्रयोगों तक बढ़ गया है। हमारे विकास के विभिन्न चरणों में, हमने अलग-अलग तरीकों से समान कोड के साथ काम किया, और मैं इस लेख में इस बारे में बात करना चाहता हूं।

फाउंडेशन: सस्ता और हंसमुख

इसलिए, 2015 के लिए तेजी से आगे बढ़ें। हमारे पास केवल तीन वेब एप्लिकेशन हैं: नकद प्रबंधन सेवाएं, पेरोल परियोजना और नियंत्रण कक्ष। और कई डेवलपर्स के रूप में।

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

यह पैकेज में फाउंडेशन कनेक्शन क्या है। इस तरह देखा:

"dependencies": { ... "sme-foundation": "git+https://stash_url/sme-foundation.git#develop" ... }, 

इस समय पुस्तकालय का मुख्य सिद्धांत सामान्य कोड स्वामित्व है।

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

यदि आप एक परियोजना में पुन: उपयोग करना चाहते हैं जो पहले से ही दूसरे में है - यह भी कोई समस्या नहीं है, तो बस इसे पुस्तकालय में ले जाएं।

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

• सामान्य कोड एक स्थान पर था और परियोजनाओं में पुन: उपयोग किया गया।
• परियोजनाओं का तेजी से विकास हुआ।
• लाइब्रेरी बढ़ रही थी।
• सभी को सामान्य कोड और परियोजनाओं दोनों का ज्ञान था, जिसने समीक्षा और वास्तु निर्णयों को अपनाने को अधिक कुशल बनाया।
• सामान्य कोड को परिष्कृत करने की आवश्यकता ने सुविधाओं के विकास को अवरुद्ध नहीं किया।

इस बिंदु पर, हमारे पास न्यूनतम दस्तावेज थे: कुछ JSDoc और यूनिट परीक्षण। UI घटकों के लिए, पर्याप्त विज़ुअल विंडो डिस्प्ले नहीं था, और हमने एक सस्ता और तेज़ समाधान - डेमो यूआई देखा। वास्तव में, यह एक कोणीय अनुप्रयोग था, जिसके पृष्ठों पर घटक स्वयं और संबंधित मार्कअप सम्मिलित थे।



2019 में, आप ऐसा करने की संभावना नहीं है। लेकिन यहाँ इस कहानी से क्या सीखा जा सकता है:

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

जैसे-जैसे समय बीतता गया, टिंकॉफ बिजनेस इकोसिस्टम और विकास टीम बढ़ती गई। जब एक दर्जन से अधिक परियोजनाएं थीं, तो इस दृष्टिकोण ने काम करना बंद कर दिया।

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

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

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

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

यूआई किट और कार्य संगठन के लिए एक नया दृष्टिकोण

जब यह नया स्वरूप और नए UI किट के बारे में 2017 में आया, तो हमने नए घटकों को एक अलग तरीके से विकसित करना शुरू कर दिया। शुरुआत करने के लिए, हमारे पास एक समर्पित टीम है।

टीम

हमने उत्पाद टीमों के तीन लोगों को चुना और कहा: "अब ये लोग अन्य परियोजनाओं के लिए UI घटक बना रहे हैं।"

समर्पित टीम ने क्या दिया?

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

यदि घटकों में विशेषज्ञता एक टीम में केंद्रित है, तो दूसरों को इन घटकों का उपयोग कैसे करना है? इसके लिए हमने उत्कृष्ट प्रलेखन किया है।

प्रलेखन

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

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

और यहाँ हमने क्या किया:

1. संपूर्ण रूप से लाइब्रेरी के बारे में जानकारी जोड़ी गई: यह कैसे जोड़ता है, और समर्थित ब्राउज़रों की सूची का चरण-दर-चरण विवरण।
   
2. हमने प्रत्येक घटक का विस्तृत विवरण तैयार किया: इसकी आवश्यकता क्यों है, यह कैसे जुड़ा हुआ है, यह किन इनपुट-आउटपुट मापदंडों का समर्थन करता है (उन्हें पोक करने की क्षमता के साथ, एक ला स्टोरीबुक), विशिष्ट उपयोग के उदाहरण, समान घटकों की एक सूची।
   
   
   
   
3. उन परियोजनाओं की एक सूची जोड़ी गई जिसमें इस घटक का उपयोग किया जाता है।
   
   
4. उन्होंने विभिन्न परियोजनाओं में व्हेल के उपयोग पर आंकड़े एकत्र करना शुरू किया: कौन सी परियोजनाएं जुड़ी हैं, कौन से संस्करण, कितने घटकों का उपयोग किया जाता है, प्रत्येक परियोजना में कोणीय और व्हेल का कौन सा संस्करण है - इस जानकारी का उपयोग असंगत परिवर्तन की योजना बनाने और फ्रेमवर्क के पुराने संस्करणों का समर्थन करने से इंकार करने के लिए किया जाता है। इन आँकड़ों को एकत्र करने वाले उपकरण का विवरण एक अलग लेख के योग्य है।
   
   
5. जोड़ा संस्करण: यूआई किट के प्रत्येक पहले जारी संस्करण के लिए प्रलेखन देखें।
   
   

बेशक, यह सब तुरंत प्रकट नहीं हुआ, लेकिन विकसित हुआ।

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

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

सामान्य तौर पर, अन्य विभागों के सहकर्मी सकारात्मक थे, लेकिन फिर भी उन्हें कुछ संदेह थे: क्या उन्हें जिन विशेषताओं की आवश्यकता थी, उन्हें जल्दी से विकसित किया जाएगा, चाहे वे उच्च गुणवत्ता के हों ... किसी ने पहले से ही खुद से घटक बनाना शुरू कर दिया था।

इन शंकाओं को हल करने के लिए, हमने यथासंभव पारदर्शी तरीके से काम का आयोजन किया।

पारदर्शिता

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

आपको हर संभव माध्यम से अपने सहयोगियों को बताना चाहिए कि आप क्या कर रहे हैं, क्यों, और इसका उपयोग कैसे करें।

हमने किन उपकरणों का उपयोग किया?

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

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

चंगेलोग । हमने उनमें से एक चैंज की तरह पारंपरिक कमिट्स और जेनरेशन पेश किए, जिसने टीमों के लिए नए संस्करणों में परिवर्तन को सरल बनाया।



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

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

अब व्हेल चैनल में 200 से अधिक उपयोगकर्ता हैं, और कई प्रश्न व्हेल डेवलपर्स की भागीदारी के बिना हल किए जाते हैं: सहकर्मी अपने अनुभव साझा करते हैं और एक दूसरे के सवालों का जवाब देते हैं।

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



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



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

टीम की भूमिका

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

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

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

लेखा परीक्षा। टीम को विकसित करने से बेहतर व्हेल के घटकों को कोई नहीं जानता। और विकास के दो वर्षों में, लोगों ने भी कोणीय में उत्कृष्ट विशेषज्ञता जमा की है। अब हम “व्हेल टीम से ऑडिट” की प्रथा शुरू कर रहे हैं। लोग उत्पाद परियोजनाओं की समीक्षा के साथ-साथ अंतिम उत्पादों और उनके कोड को देखते हैं। उनका लक्ष्य दुरुपयोग का पता लगाना, प्रलेखन को परिष्कृत करना और अच्छे और बुरे व्यवहारों की सूची बनाना है। हम अगली बार क्या होता है इसके बारे में बात करेंगे।

चुनौतियां और समझौता

बड़ी संख्या में हितधारकों के साथ किसी भी प्रक्रिया की तरह, एक आम पुस्तकालय का विकास हमें समझौता करने के लिए मजबूर करता है।

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

हमें एक समझौता मिला: हर पाँचवें सप्ताह में एक बार, यानी हर पाँचवें रिलीज़ के बाद ब्रेकिंग में कोई बदलाव नहीं होता। उदाहरण के लिए, इस तरह के बदलाव 0.50, 0.55, 0.60 रिलीज में कॉल कर सकते हैं। लेकिन 0.50 से 0.51 तक के संक्रमण को किसी भी प्रयास की आवश्यकता नहीं थी। यह स्थिर संस्करण 1.0.0 की रिलीज तक जारी रहा। अब एपीआई स्थिर है, और सभी बड़े पैमाने पर परिवर्तन अनिश्चित भविष्य में 2.0.0 पर स्थगित हो जाते हैं।

कई बार, एक नए संस्करण में स्विच करने के लिए बहुत सारे रूटीन काम करने की आवश्यकता होती है: उपसर्गों का नाम बदलना, आइकन आयात बदलना, और पसंद करना। ऐसे मामलों के लिए, हमने माइग्रेशन स्क्रिप्ट लागू की हैं।

निष्कर्ष

यह लेख साझा कोड पुस्तकालयों के साथ काम करने के हमारे चार वर्षों के अनुभव का वर्णन करता है। हमने क्या निष्कर्ष निकाले?

1. यहां तक ​​कि एक छोटी सी टीम को कोड दोहराव के साथ नहीं रखा जाना चाहिए। लाइब्रेरी में कोड हटाना सभी के लिए सुलभ समाधान है।
2. सामान्य कोड का संयुक्त स्वामित्व छोटी टीमों के लिए अच्छी तरह से काम करता है, 10 परियोजनाएं पुस्तकालय के उपयोगकर्ता हैं।
3. इसमें शामिल परियोजनाओं या डेवलपर्स की बढ़ती संख्या के साथ, यह सामान्य कोड पर ध्यान देने वाली टीम से एकल करने के लिए अधिक सुविधाजनक है।
4. एक समर्पित टीम के काम का एक महत्वपूर्ण हिस्सा उपयोगकर्ताओं के साथ संचार है: डेमो, प्रशिक्षण, सहायता, प्रलेखन।
5. व्यापक सोचने और उपकरणों में समय लगाने से डरो मत। हमारे मामले में, यह प्रलेखन और घटकों का उपयोग करने के लिए एक विश्लेषक के साथ एक सुविधाजनक शोकेस है।