डीएपी डेवलपमेंट: उपयोगकर्ता के पहले ऑन-चेन कार्यों के आसपास

आपके पहले रिलीज़ के लिए कौन सा dApp बिल्ड पथ उपयुक्त है?

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

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

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

एक्शन मैप से कार्यशील इंटरफ़ेस तक 3 बिल्ड पास

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

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

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

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

कार्यान्वयन से पहले हमें 5 इनपुट चाहिए

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

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

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

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

समीक्षा विंडो dApp बिल्ड में कैसे फिट होती हैं?

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

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

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

लॉन्च से पहले: साफ़ करने के लिए 3 निर्भरताएँ

3 निर्भरताएँ अंतिम जांच की हकदार हैं: कॉन्ट्रैक्ट व्यवहार, वॉलेट हैंडलिंग और प्रत्येक प्रदर्शित डेटा दृश्य के पीछे का स्रोत। हम उन्हें स्वीकृति जांच के बगल में रिकॉर्ड करते हैं। आपकी टीम तब देख सकती है कि हैंडऑफ़ के बाद dApp किस पर निर्भर करता है।

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

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

अंतिम समीक्षा के लिए, हम हैंडऑफ़ नोट्स में जाँचे गए फ्लो, डेटा दृश्यों और शेष निर्भरताओं को लॉग करते हैं।

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

यह कैसे काम करता है

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